Skip to content

fix(desktop): stop requiring a global codex CLI for Codex agents - #31

Open
QuicksilverSlick wants to merge 5 commits into
mainfrom
fix/codex-no-global-cli
Open

QuicksilverSlick wants to merge 5 commits into
mainfrom
fix/codex-no-global-cli

Conversation

@QuicksilverSlick

Copy link
Copy Markdown
Owner

Stacked on #30. Until #30 merges, this diff includes #30's three commits. Review only the last commit, fix(desktop): stop requiring a global codex CLI for Codex agents. I'll rebase onto main once #30 lands.

Problem

The Codex runtime is marked "CLI missing" whenever there's no codex on PATH, even with codex-acp installed. The catalog declares underlying_cli: Some("codex"), so an installed adapter without a global CLI is classified CliMissing. As a result:

  • Readiness parks the agent with "codex CLI is missing".
  • Settings → Agent runtimes hides the Connect button, which only appears for available runtimes. It offers to install the Codex CLI instead.
  • The "Underlying CLI" row in the runtime details shows the global CLI, which is not the engine the agent runs.

None of this is needed. Every supported codex-acp version (floor 1.1.7; checked 1.1.7, 1.3.0, 1.7.0 and 1.13.1 on npm) declares @openai/codex as a dependency and runs that bundled engine unless CODEX_PATH is set. Since #30, the readiness and badge probes use that engine too. Upstream's block#7427 and issue block#7775 describe the same fact: agents run the nested engine, not the global CLI.

Fix

  • catalog.rs: Codex gets underlying_cli: None. An installed adapter is now Available. Discovery no longer resolves a codex (one fewer login-shell lookup), and the installer no longer runs the curl/PowerShell Codex CLI installer; the adapter's npm install is enough. The cli_install_* fields go unused for Codex; they're left in place because several vendor-metadata tests pin them.
  • Logged-out copy: it now leads with the in-app flow: "connect your Codex account in Agent runtimes, or run codex login if the Codex CLI is installed".

Tests

  • New codex_adapter_without_global_cli_is_available runs the production catalog through classify_runtime with no PATH codex and asserts Available. It fails if the CLI requirement comes back.
  • managed_agents + commands::agent_discovery on Windows: 1337 passed, 0 failed. On this machine the freshly built test binary only starts when run directly, not under cargo test (STATUS_ENTRYPOINT_NOT_FOUND: cargo's PATH puts an incompatible DLL first); that's environmental.
  • cargo fmt --check passes. cargo clippy -p buzz-desktop --all-targets adds no warnings (the remaining ones are older Windows-only dead-code warnings). The file-size check passes.

Behaviour notes

🤖 Generated with Claude Code

QuicksilverSlick and others added 5 commits September 27, 2026 10:30
Codex readiness and the cached auth badge ran `codex login status` with
whatever `codex` was first on PATH. codex-acp never uses that binary: it
spawns `CODEX_PATH` when set, else the @openai/codex it bundles. When the
global CLI lags the Codex desktop app's config (e.g. an old CLI rejecting
`model_reasoning_effort = "ultra"`), a working agent parked in setup mode
with a false "config.toml is invalid" card.

Both probes now go through `cli_probe::probe_command`: CODEX_PATH (agent
env over the inherited app env; empty = unset, as in codex-acp), else
`node <codex-acp>/node_modules/@openai/codex/bin/codex.js` resolved the
way Node resolves it from the adapter package (Windows .cmd/sh shim
layout and unix bin symlink), else the PATH `codex`. ConfigInvalid
classification is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: QuicksilverSlick <russelledeming@gmail.com>
codex-acp spawns CODEX_PATH whenever it is set, so a CODEX_PATH that does
not resolve must not fall back to the bundled or PATH engine (which would
report Ready for an agent that then fails to spawn). Readiness now surfaces
it as a missing binary naming `CODEX_PATH=<value>` instead of asking for a
`codex login`; the badge probe skips it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: QuicksilverSlick <russelledeming@gmail.com>
Port of the buzz-acp half of upstream block#7594 (Salman Mohammed).
The desktop readiness engine can emit `Requirement::MissingBinary`, and
this change makes it do so for a CODEX_PATH that does not resolve. The
fork's setup-mode parser did not know the variant, so the setup listener
exited on a malformed BUZZ_ACP_SETUP_PAYLOAD and the agent crash-looped
instead of posting a nudge (upstream issues block#4628, block#7613).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: QuicksilverSlick <russelledeming@gmail.com>
The codex runtime declared `underlying_cli: Some("codex")`, so an
installed codex-acp with no `codex` on PATH classified as CliMissing:
readiness parked the agent ("codex CLI is missing"), Agent runtimes hid
the Connect button (shown only when Available) and offered to install a
CLI the agent never runs. Every supported codex-acp (>= the 1.1.7 floor)
depends on @openai/codex and runs that bundled engine unless CODEX_PATH
is set; the readiness and badge probes already use it.

Drop the CLI requirement so an installed adapter is Available, and lead
the logged-out copy with the in-app Connect flow, since `codex login`
needs the optional CLI.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: QuicksilverSlick <russelledeming@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant