[Bug]: ocx codex-shim install always fails on the standalone ocx binary from the desktop .deb #6276

Client or integration

Codex CLI

Area

Installation or packaging

Summary

ocx codex-shim install is refused every time I run it from the standalone (compiled) ocx binary that ships in the Linux desktop .deb. The refusal message blames the saved Codex launcher ("probe process group could not be terminated cleanly"), but the launcher is fine: the install probe cannot start at all because it re-executes the compiled binary as if it were a Bun interpreter.

Expected: the shim installs from the standalone binary, or the failure names the real cause. Today the Codex autostart shim cannot be enabled on a machine whose only OpenCodex install is the desktop package, and the advice in the message ("reinstall Codex as a concrete executable") is wrong.

I found two defects by reading the code on dev. Only the first one is reproduced; the second is hidden behind it and is not verified end to end.

1. Install probe (src/codex/shim-probe.ts, probeUnixShimInstall) runs spawnSync(process.execPath, ["-e", CODEX_SHIM_INSTALL_PROBE_SCRIPT, ...]). For the npm install process.execPath is bun.exe, so -e runs the probe script. For the standalone binary it is /usr/bin/ocx, which parses -e as a CLI command and exits with Unknown command: -e. The script never writes the group marker file, groupId stays 0, and the probe reports phase=group-id.
2. Shim wrapper target (src/codex/shim.ts, cliEntry()) bakes cli: join(import.meta.dir, "..", "cli", "index.ts") next to durableBunRuntime().path, which is process.execPath with source standalone for a compiled binary (src/lib/bun-runtime.ts). In a compiled binary import.meta.dir is a virtual bundle path, so the generated wrapper would run <ocx> <virtual path>/cli/index.ts ensure. The standalone CLI would treat that as an unknown command, so autostart would print "proxy autostart failed" on every Codex launch. selfLaunchArgv() in src/lib/self-launch-argv.ts already returns bare args for a standalone executable and looks like the right primitive.

This is the same class of problem as #6222 (a compiled bundled CLI re-entering itself with a Bun-style argv or import.meta.dir path), but in a different code path. #6222 and its draft PR touch startup-health-cache.ts and autostart-health.ts; neither touches shim-probe.ts or shim.ts.

Reproduction

1. Install the desktop package, which provides the compiled /usr/bin/ocx and /usr/bin/opencodex-desktop:

   sudo apt install ./OpenCodex-2.73.0-preview.20260930-linux-amd64.deb

2. Use a Codex CLI that is a symlink to the standalone install, with no existing shim:

   ls -l ~/.local/bin/codex
   # ~/.local/bin/codex -> ~/.codex/packages/standalone/current/bin/codex
   /usr/bin/ocx codex-shim status
   # Codex autostart shim is not installed.

3. Try to install the shim. This fails the same way from an interactive terminal and from a non-interactive shell:

   /usr/bin/ocx codex-shim install

4. Confirm the compiled binary does not understand -e, which is how the probe launches its script:

   /usr/bin/ocx -e 'console.log("hello")'
   # Unknown command: -e   (followed by the CLI usage text)
   BUN_BE_BUN=1 /usr/bin/ocx -e 'console.log("BE_BUN", process.execPath)'
   # BE_BUN /usr/bin/ocx   (the same binary runs the script when it is told to behave as Bun)

5. ocx codex-shim status still reports the shim as not installed, and ~/.local/bin/codex is restored to the original symlink, so nothing is left behind.

Cause of the group-id phase: probeUnixShimInstall reads the group file from its temp directory after the child exits (shim-probe.ts, the groupId <= 0 branch). The child was the CLI, not the probe script, so the file does not exist.

Not verified: whether the shim would work once the probe passes (defect 2 above). I could not test it because the probe blocks installation.

Possible direction, for the maintainers to judge:

• In the probe, launch the script in a way the compiled binary understands (for example with BUN_BE_BUN=1, which step 4 shows runs -e), or avoid the -e re-entry for a standalone executable.
• In cliEntry(), for a standalone executable emit a wrapper that calls <ocx> ensure directly.
• When the probe child never writes the group file, say that the probe could not start instead of pointing at the saved launcher.
• A regression test that runs the install against a compiled binary or its seam, since a run under the Bun runtime cannot see this.

Version

2.73.0-preview.20260930 (desktop .deb, compiled /usr/bin/ocx). src/codex/shim-probe.ts is identical on main (2.72.0) and dev; src/codex/shim.ts and src/lib/bun-runtime.ts were read on dev.

Operating system

Ubuntu 26.04.1 LTS, GNOME on Wayland, x86_64

Provider and model

No response

Logs or error output

$ /usr/bin/ocx codex-shim install
⚠️  Refusing Codex autostart shim because the saved launcher's probe process group could not be terminated cleanly [phase=group-id; code=none; status=1; signal=none]. The original launcher was restored; reinstall Codex as a concrete executable before enabling codexAutoStart.
Codex shim installation is unhealthy: Codex autostart shim is not installed.

$ /usr/bin/ocx codex-shim status
Codex autostart shim is not installed.

$ /usr/bin/ocx -e 'console.log("hello")'
Unknown command: -e
opencodex (ocx) — Universal provider proxy for Codex
...

Screenshots and supporting files

No response

Redacted configuration

No response

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.