[Bug] Codex agent fails to start on macOS x64 (v0.0.84) — missing bundled ACP binary #205

Activity

1. 21st-connector commented on Apr 27, 2026

   

   21st-connectorBot

   on Apr 27, 2026 – with 21st - Connector

   Last edited by 21st-connector

   Contributor

   More actions

   Task completed.

   I'll analyze this issue by exploring the codebase to understand how the Codex agent is bundled and identify the root cause and potential fixes.

   ---

   View full conversation

   Powered by 1Code
2. 21st-connector commented on Apr 27, 2026

   

   21st-connectorBot

   on Apr 27, 2026 – with 21st - Connector

   Last edited by 21st-connector

   Contributor

   More actions

   Task completed.

   I'll analyze this issue by exploring the codebase to understand the Codex agent bundling and packaging setup, then provide a helpful comment.

   ---

   View full conversation

   Powered by 1Code
3. 21st-connector commented on Apr 27, 2026

   

   21st-connectorBot

   on Apr 27, 2026 – with 21st - Connector

   Contributor

   More actions

   Codebase Analysis

   This is a legitimate packaging bug affecting the macOS x64 build. Here's what the codebase reveals:

   Error 1 — Missing bundled Codex CLI binary

   Resolution path: src/main/lib/trpc/routers/codex.ts:237-260

   The resolveBundledCodexCliPath() function (line 237) looks for the binary at process.resourcesPath/bin/codex in packaged apps. This binary gets placed there via the extraResources config in package.json:166-172:

   {
     "from": "resources/bin/${platform}-${arch}",
     "to": "bin"
   }

   The binary is downloaded during the release process by scripts/download-codex-binary.mjs, which has explicit darwin-x64 support (line 32-36) — it downloads codex-x86_64-apple-darwin.tar.gz into resources/bin/darwin-x64/codex.

   Likely cause: The release script (package.json:27) runs bun run codex:download before bun run package:mac. The codex:download command (line 25) only downloads for the current platform by default. If the release was built on an arm64 Mac, only resources/bin/darwin-arm64/ would be populated, and the x64 build would get an empty bin/ directory (or none at all). The --all flag exists (codex:download:all, line 26) but is not used in the release script.

   Error 2 — Missing @zed-industries/codex-acp-darwin-x64 native module

   Resolution path: src/main/lib/trpc/routers/codex.ts:223-235

   The resolveCodexAcpBinaryPath() function (line 223) resolves the platform-specific ACP package via require.resolve(). The platform package is determined by getCodexPackageName() (line 188) which correctly maps darwin/x64 to @zed-industries/codex-acp-darwin-x64.

   The main @zed-industries/codex-acp package (line 76 in package.json, version 0.9.3) declares these as optional dependencies. The asarUnpack config (package.json:183-184) correctly includes both the wrapper and platform packages:

   "node_modules/@zed-industries/codex-acp/**/*",
   "node_modules/@zed-industries/codex-acp-*/**/*"

   Likely cause: bun install (or the package manager used during CI) only installs optional native dependencies for the host architecture. When building on an arm64 Mac, @zed-industries/codex-acp-darwin-arm64 gets installed but @zed-industries/codex-acp-darwin-x64 does not. electron-builder then packages only what's in node_modules/, so the x64 build ships without the x64 ACP binary.

   Root Cause Summary

   Both errors trace back to the same underlying issue: the release is likely built on an arm64 Mac, and cross-architecture dependencies are not installed. The release script in package.json:27 is:

   rm -rf release && bun i && bun run claude:download && bun run codex:download && bun run build && bun run package:mac && ...
   

   This runs bun i (installs native deps for host arch only) and codex:download (downloads CLI binary for host platform only), then package:mac builds for both arm64 and x64 targets (package.json:191-193).

   Suggested Fix Approach

   1. Codex CLI binary: Change the release script to use codex:download:all (and claude:download:all) instead of the single-platform variants, so resources/bin/darwin-x64/ is populated even when building on arm64.

   2. ACP native module: This is trickier. Options include:

      • Run npm install --cpu=x64 --os=darwin @zed-industries/codex-acp (or equivalent bun flag) as a pre-build step to force-install cross-arch optional deps.
      • Use electron-builder's beforeBuild hook or npmRebuild option to ensure platform-specific optional deps are installed for each target arch.
      • Bundle the ACP binary as an extraResource (similar to the CLI binary) instead of relying on npm optional deps.

   3. Fallback path (addresses the user's suggestion): Adding a UI setting to point to an externally installed codex binary would be a useful workaround for edge cases, but should not replace fixing the bundling.

   Related Issues

   • [Bug] Codex agent gets stuck on permission prompts — requests never surface in UI #178 — Codex agent gets stuck on permission prompts (another open Codex agent bug, different root cause)
   • Downloading Claude Binary fails 404, missing extension for Windows #36 — Previous binary bundling issue (Claude binary download 404 on Windows, now closed/fixed)

   Key Files for the Fix

   File	What to change
   package.json:27	Release script — switch to codex:download:all and claude:download:all
   package.json:27	Release script — add cross-arch bun install step for optional native deps
   scripts/download-codex-binary.mjs:26-36	Already supports darwin-x64 — no changes needed
   src/main/lib/trpc/routers/codex.ts:223-260	Binary resolution logic — already correct, just needs deps to be present
   electron.vite.config.ts:22-27	May need @zed-industries/codex-acp added to external list if not already handled by externalizeDepsPlugin
4. 21st-connector commented on Apr 27, 2026

   

   21st-connectorBot

   on Apr 27, 2026 – with 21st - Connector

   Contributor

   More actions

   Issue Analysis

   Thanks for the detailed bug report. After analyzing the codebase, here's a breakdown of the root cause and a suggested fix plan.

   ---

   Root Cause

   There are two separate bundling failures for macOS x64, both stemming from the same build pipeline issue:

   Error 1: Missing Codex CLI binary (Resources/bin/codex)

   The release script (package.json:27) runs:

   bun run codex:download && ... && bun run package:mac

   codex:download (without --all) calls download-codex-binary.mjs which only downloads the binary for the current platform (scripts/download-codex-binary.mjs:371):

   const currentPlatform = `${process.platform}-${process.arch}`
   platformsToDownload = [currentPlatform]

   If the release is built on an arm64 Mac (which is likely), only resources/bin/darwin-arm64/codex gets downloaded. The electron-builder config then uses ${platform}-${arch} substitution to copy per-arch binaries:

   // package.json:167
   { "from": "resources/bin/${platform}-${arch}", "to": "bin" }

   When building the x64 target, electron-builder looks for resources/bin/darwin-x64/ — which doesn't exist because the download script only fetched darwin-arm64. The extraResources copy silently does nothing (no error on missing source), resulting in the Contents/Resources/bin/ directory being entirely absent from the x64 build.

   Relevant files:

   • scripts/download-codex-binary.mjs:370-377 — platform detection logic
   • package.json:25 — codex:download uses --version=0.98.0 but no --all
   • package.json:161-176 — extraResources config with ${platform}-${arch} substitution

   Error 2: Missing @zed-industries/codex-acp-darwin-x64 native module

   The @zed-industries/codex-acp wrapper package (v0.9.3) declares all platform variants as optional dependencies (bun.lock:821). When bun install runs on an arm64 Mac, bun correctly skips codex-acp-darwin-x64 because its cpu field doesn't match the host.

   electron-builder's asarUnpack config (package.json:184) correctly includes the glob node_modules/@zed-industries/codex-acp-*/**/*, but since the x64 package was never installed to node_modules/, there's nothing to unpack.

   At runtime, resolveCodexAcpBinaryPath() (src/main/lib/trpc/routers/codex.ts:223-235) calls require.resolve("@zed-industries/codex-acp-darwin-x64/bin/codex-acp") which fails because the package doesn't exist in the asar.

   Relevant files:

   • src/main/lib/trpc/routers/codex.ts:188-208 — getCodexPackageName() selects platform package
   • src/main/lib/trpc/routers/codex.ts:223-235 — resolveCodexAcpBinaryPath() resolution
   • package.json:76 — @zed-industries/codex-acp dependency

   ---

   Suggested Fix Plan

   Fix 1: Download all platform binaries during release

   Change the release script in package.json:27 to use codex:download:all instead of codex:download:

   -"release": "... bun run claude:download && bun run codex:download && ..."
   +"release": "... bun run claude:download:all && bun run codex:download:all && ..."

   This ensures resources/bin/darwin-x64/codex exists when electron-builder builds the x64 target. The same issue likely applies to claude:download — check if download-claude-binary.mjs has the same single-platform default behavior.

   The release:dev script (package.json:28) should get the same treatment.

   Fix 2: Force-install all platform-specific codex-acp packages

   For the native ACP module, the build needs all platform variants installed in node_modules/ before packaging. Options:

   Option A — Add explicit optional dependencies to the project's package.json:

   "optionalDependencies": {
     "@zed-industries/codex-acp-darwin-arm64": "0.9.3",
     "@zed-industries/codex-acp-darwin-x64": "0.9.3",
     "@zed-industries/codex-acp-linux-arm64": "0.9.3",
     "@zed-industries/codex-acp-linux-x64": "0.9.3",
     "@zed-industries/codex-acp-win32-arm64": "0.9.3",
     "@zed-industries/codex-acp-win32-x64": "0.9.3"
   }

   However, bun will still skip packages whose os/cpu don't match the host. So this alone may not suffice.

   Option B (Recommended) — Use a pre-package script to explicitly install cross-platform deps:

   Add a step in the release script that force-installs the needed platform packages. For example:

   bun add --optional @zed-industries/codex-acp-darwin-x64@0.9.3 --force

   Or use npm/yarn for this specific install since they may handle cross-platform optional deps differently.

   Option C — Use electron-builder's beforePack hook to ensure the target platform's native module is present before each arch build. This is the most robust approach for cross-compilation scenarios.

   Fix 3 (Nice-to-have): Add a fallback for external codex binary

   As the reporter suggested, add a setting to allow users to specify an external codex binary path. In resolveBundledCodexCliPath() (src/main/lib/trpc/routers/codex.ts:237-260), check for a user-configured path before falling back to the bundled location. This would serve as a workaround for any future bundling issues.

   ---

   Files to Modify

   File	Change
   package.json:27-28	Use codex:download:all and claude:download:all in release scripts
   package.json (new section)	Add optionalDependencies for all codex-acp platform variants, or add beforePack hook
   src/main/lib/trpc/routers/codex.ts:237-260	(Optional) Add user-configurable binary path fallback
   electron-builder.yml or package.json build section	(Optional) Add beforePack script for cross-platform native module installation

   Verification

   After fixing, verify by building on an arm64 Mac and checking the x64 output:

   # After building
   ls -la "release/mac-x64/1Code.app/Contents/Resources/bin/codex"
   # Should exist and be the x86_64 binary
   
   # Check the unpacked asar for codex-acp
   ls -la "release/mac-x64/1Code.app/Contents/Resources/app.asar.unpacked/node_modules/@zed-industries/codex-acp-darwin-x64/bin/codex-acp"
   # Should exist and be the x86_64 native binary
5. 21st-connector commented on Apr 27, 2026

   

   21st-connectorBot

   on Apr 27, 2026 – with 21st - Connector

   Contributor

   More actions

   Issue Analysis

   Relevant Code Paths

   Error 1 — Missing Codex CLI binary is thrown by resolveBundledCodexCliPath() in src/main/lib/trpc/routers/codex.ts:237-260. In packaged apps, it expects the binary at {process.resourcesPath}/bin/codex (line 240). This path is populated by electron-builder's extraResources config in package.json:166-172:

   {
     "from": "resources/bin/${platform}-${arch}",
     "to": "bin",
     "filter": ["**/*"]
   }

   This copies from resources/bin/darwin-x64/ at build time. The binary is downloaded by scripts/download-codex-binary.mjs which fetches from the openai/codex GitHub releases.

   Error 2 — Missing ACP native module is thrown when resolveCodexAcpBinaryPath() (codex.ts:223-235) calls require.resolve() for @zed-industries/codex-acp-darwin-x64. The platform-specific package is selected by getCodexPackageName() (codex.ts:188-208).

   Root Cause Analysis

   There are two separate bundling issues:

   1. Codex CLI binary not downloaded for x64 during release build

   The release script in package.json:27 runs:

   bun run codex:download
   

   This downloads the binary only for the current platform/arch (the machine running the build). If the release build runs on an arm64 Mac (Apple Silicon), only resources/bin/darwin-arm64/codex is downloaded. The x64 variant is never fetched, so electron-builder's extraResources finds nothing to copy into the x64 build.

   The fix should use bun run codex:download:all (line 26) instead, which downloads binaries for all platforms. The same issue applies to bun run claude:download — it should also be bun run claude:download:all.

   2. @zed-industries/codex-acp-darwin-x64 not included in ASAR

   The @zed-industries/codex-acp wrapper package declares all platform variants as optionalDependencies. When bun install runs on an arm64 machine, bun typically only installs the matching platform optional dependency (codex-acp-darwin-arm64) and skips codex-acp-darwin-x64. Since electron-builder packages node_modules from the build machine, the x64 native binary is absent from the ASAR.

   The asarUnpack config at package.json:183-184 correctly declares both patterns:

   "node_modules/@zed-industries/codex-acp/**/*",
   "node_modules/@zed-industries/codex-acp-*/**/*"

   But this only works if the packages are actually installed in node_modules/ in the first place.

   Suggested Fix

   1. For the Codex CLI binary: Change the release script to use codex:download:all (and claude:download:all) so all platform binaries are present before electron-builder --mac builds both arm64 and x64 targets.

   2. For the ACP native module: Ensure all platform-specific @zed-industries/codex-acp-* packages are installed at build time. Options include:

      • Add all platform variants as explicit optionalDependencies in the root package.json (electron-builder will then include them)
      • Use bun's supportedArchitectures configuration (or the equivalent --arch flag) during bun install to force installation of all platform variants
      • Run separate bun install steps per target architecture before packaging

   3. The workaround suggestion in the issue (external binary path config) would be addressed separately in codex.ts:237-260 by checking a user-configurable path before falling back to the bundled location.

   Related Issues

   • [Bug] Codex agent gets stuck on permission prompts — requests never surface in UI #178 — Codex agent gets stuck on permission prompts (related Codex/ACP functionality)
   • Downloading Claude Binary fails 404, missing extension for Windows #36 (closed) — Previous missing binary issue (Claude binary 404 on Windows), similar class of packaging bug

   Not a Duplicate

   This is a distinct issue. No existing open issues cover the x64 macOS bundling problem for Codex.