codex - 💡(How to fix) Fix Computer Use: SkyComputerUseClient SIGKILL'd (Code Signature Invalid) when codex CLI is launched outside Codex.app process tree (e.g. via ACP adapter) [2 comments, 2 participants]

What version of the Codex App are you using (From "About Codex" dialog)?

26.422.71525 (build 2210)

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.4.0 arm64 arm

macOS 15.x on Apple Silicon. Computer Use plugin: 1.0.758 (~/.codex/plugins/cache/openai-bundled/computer-use/1.0.758/).

What issue are you seeing?

The bundled SkyComputerUseClient helper is SIGKILL'd by the kernel with Code Signature Invalid every time the Codex CLI is launched outside the Codex.app process tree — for example, when Codex is spawned as a subprocess by a third-party ACP adapter (codex-acp, etc.) that hosts Codex's stdio JSON-RPC behind a different parent process.

Crash signature in ~/Library/Logs/DiagnosticReports/SkyComputerUseClient-*.ips:

Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid))
bundleID:       com.openai.sky.CUAService.cli
procName:       SkyComputerUseClient
codeSigningTeamID: 2DC432GLL2
bug_type:       309

Both the Codex.app and the Computer Use plugin pass codesign --verify --deep --strict and spctl --assess — the bundles are correctly signed. The same Codex CLI binary works inside Codex.app. This points to a macOS launch-constraint rather than a signing issue: the helper requires its launching ancestor to be Codex.app; any other parent triggers SIGKILL at exec.

Additional symptoms during a long ACP-driven session:

• 30+ orphaned SkyComputerUseClient mcp processes accumulate (each turn produces a fresh crash)
• Crash reports flood ~/Library/Logs/DiagnosticReports/
• Significant RSS growth in the parent (codex) waiting on the helper handshake

This is distinct from #18549, which captures the generic crash without specifying the external-parent trigger. It is also distinct from #19544 (Apple-event auth failure from Homebrew CLI) — different layer, different error.

What steps can reproduce the bug?

1. Install Codex.app + the bundled Computer Use plugin (1.0.758).
2. Install any ACP-mode adapter that spawns Codex as a subprocess. For example, codex-acp (stdio JSON-RPC bridge).
3. Configure your ACP client (an editor or test harness) to launch Codex via that adapter — i.e., not through Codex.app's window.
4. Send any prompt that does not request Computer Use.
5. Observe Console.app "Crash Reports" filtered to SkyComputerUseClient — a fresh .ips per dispatch turn.
6. ps aux | grep SkyComputerUseClient shows accumulating zombie processes that don't reap.

Notably:

• Disabling the Computer Use plugin in the Codex.app preferences UI does NOT prevent these crashes. The launcher attempts to spawn the helper before the runtime feature-flag check fires.
• Disabling the [plugins.computer-use] block in ~/.codex/config.toml reduces but does not eliminate the spawn attempts.

What is the expected behavior?

When the Codex CLI is launched outside Codex.app and Computer Use is not requested by the model, the launcher should either:

1. Detect the parent-process bundle ID does not match Codex.app and skip the helper launch entirely (cleanest), or
2. Honor the ~/.codex/config.toml plugin-disable flag earlier in the launcher path so the helper is never spawned when the plugin is configured off, or
3. Trap Code Signature Invalid SIGKILLs from the helper as a non-fatal "Computer Use unavailable in this context" condition.

Additional information

Reliable workaround (applied locally, eliminates all crashes):

Two parts, both required:

1. Disable plugin entries in ~/.codex/config.toml (the [plugins.computer-use] block / equivalent).

2. Rename all SkyComputerUseClient binaries under ~/.codex/plugins/cache/openai-bundled/computer-use/<ver>/... so the launcher cannot find them. On a 1.0.758 install the targets are:

   ~/.codex/plugins/cache/openai-bundled/computer-use/1.0.758/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient

   (Add .disabled suffix; the launcher logs an ENOENT and proceeds.)

Either step alone is insufficient — the config flag is checked after the spawn attempt, and renaming alone leaves the config still pointing at the path.

Why this matters: the ACP-adapter pattern is increasingly common for embedding Codex into third-party agent runtimes, IDE plugins, and orchestrators. Without the workaround, every ACP turn produces a crash report and a zombie process, and the helpers' SIGKILL'd state can wedge the parent on long sessions.

Related: #18549 (generic crash report).