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

[SergiiShapoval]

Environment

• 1Code version: v0.0.84
• macOS: Intel x64 (darwin/x86_64)
• Arch (uname -m): x86_64

Description

After installing 1Code v0.0.84 on macOS x64 and attempting to use the Codex agent, the app immediately fails with two consecutive errors.

Error 1 — Missing bundled CLI

[codex] Bundled Codex CLI not found at /Applications/1Code.app/Contents/Resources/bin/codex.
Binary is missing from bundled resources.

The directory /Applications/1Code.app/Contents/Resources/bin/ does not exist at all in the installed bundle.

Error 2 — Missing ACP native module

After attempting a workaround (manual symlink), the next error appears:
Cannot find module '@zed-industries/codex-acp-darwin-x64/bin/codex-acp'
Require stack:

• /Applications/1Code.app/Contents/Resources/app.asar/out/main/index.js

This indicates that the native ACP package @zed-industries/codex-acp-darwin-x64 is not bundled inside app.asar.

Steps to Reproduce

1. Download and install 1Code-0.0.84.dmg (macOS x64 build).
2. Open 1Code and attempt to activate/use the Codex agent.
3. Observe the errors above in the app logs / console.

Expected Behavior

The Codex agent should start successfully. The bundled binary at
/Applications/1Code.app/Contents/Resources/bin/codex
and the native module @zed-industries/codex-acp-darwin-x64 should be present in the release package for macOS x64.

Actual Behavior

• Contents/Resources/bin/ directory is missing entirely.
• @zed-industries/codex-acp-darwin-x64 is not bundled inside app.asar.
• Workaround via sudo ln -s $(which codex) ... is blocked by macOS SIP (Operation not permitted), so there is no viable manual fix.

Possible Root Cause

It appears the macOS x64 build was packaged without the platform-specific native ACP binaries for Codex. The darwin-arm64 build may not be affected.

Suggested Fix

• Ensure @zed-industries/codex-acp-darwin-x64 is included in the app.asar bundled node_modules for the x64 macOS release.
• Alternatively, provide a configuration option in the UI to point to an externally installed codex binary path, so users can work around bundling issues without needing to bypass SIP.

[1code-async]

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

[1code-async]

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

[1code-async]

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

[1code-async]

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

[1code-async]

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.