[Bug]: Custom Codex executable path is inaccessible when Codex is undetected

[Pape45]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

Open Design supports a custom Codex executable path through agentCliEnv.codex.CODEX_BIN, but the setting is inaccessible precisely when it is needed.

The “Advanced: proxy & custom paths” section filters its fields by the currently selected cfg.agentId. When Codex is not detected, its card appears under “Available to install” as a disabled card and cannot be selected. Therefore the user cannot select Codex, cannot reveal the Codex-specific advanced fields, and cannot enter the absolute path that would make Codex detectable.

This creates a circular recovery flow:

1. Codex must be selected to configure CODEX_BIN.
2. Codex must be detected before it can be selected.
3. CODEX_BIN is needed because Codex cannot be detected on the inherited PATH.

Steps to reproduce

1. Install Codex CLI in a directory not visible to the packaged app's inherited PATH.
2. Launch Open Design.
3. Open Settings → Execution mode → Local CLI.
4. Click Rescan.
5. Observe that Codex appears under “Available to install”.
6. Try to select the unavailable Codex card or find the “Codex executable path” setting.
7. Observe that the card cannot be selected and the custom path field is not rendered.

Expected behavior

Users should be able to configure the absolute Codex executable path while Codex is unavailable, then rescan and select it.

A minimal recovery path could expose the custom executable field/action from the unavailable Codex card or render binary path overrides independently of the currently selected agent.

Open Design version

0.16.1

Platform

macOS (Apple Silicon)

Logs (optional)

Codex CLI (`codex`) was not found on your PATH.

Additional context

The daemon already validates an absolute executable CODEX_BIN override and gives it precedence during agent resolution. The missing piece is UI access to that existing capability when available === false.

[lefarcen]

Hi @Pape45! 👋

Nice write-up — the circular flow in Settings → Execution mode → Local CLI is very clear, and I could confirm the gap in the current implementation.

This does look like a real bug: the unavailable Codex card is rendered as non-selectable in the “Available to install” list, while the advanced CLI env fields are filtered to the currently selected agent, so CODEX_BIN never becomes reachable when Codex is undetected. The daemon side already accepts and validates a Codex override, so this looks confined to the Settings UI rather than the launcher path itself.

Related context: #2541 improved saving a detected Codex path after a successful test, and #2353 added a similar recovery path for OpenCode binary selection, but neither covers the first-time “Codex is unavailable before selection” case you're hitting here.

I’ve added bug + help wanted since this looks like a good community-fix candidate. A reasonable fix would be to expose the Codex binary override even when the Codex card is currently unavailable, or surface the existing setEnv action directly from that unavailable card.

[lefarcen]

If you'd like to pick this up, comment /claim and we can hand it over for a community fix.

[Pape45]

/claim

[lefarcen]

Thanks for picking this up, @Pape45! ✨

Roughly how long do you think it’ll take — a few hours, 1–3 days, around a week, or longer?

[Pape45]

A few hours — I’m working on the regression test and fix now.

[lefarcen]

PR #6124 is now open for this. It keeps the daemon behavior unchanged and fixes the Settings-side gap by exposing CODEX_BIN while Codex is still unavailable, so the recovery path no longer depends on selecting a disabled card first.

Keeping #6122 open until the PR lands.

[lefarcen]

Re-opening this issue for community contribution because linked PR #6125 has had no author activity.

The PR has been left open as draft so @Pape45 can resume later, and others may /claim this issue if they want to take it on.

[Pape45]

The latest inactivity comment appears to reference the wrong PR: #6125 addresses #6121. This issue’s fix is #6124, which remains open, ready for review, approved by @PerishCode, design-approved, and includes the requested screenshot plus manual verification.

Please keep #6122 associated with #6124; no author action was pending on that PR.

[lefarcen]

You're right — that inactivity note pointed at the wrong PR.

#6122 should stay associated with #6124, not #6125. #6124 is still the active fix path for this issue, and based on its current state there isn't author-side follow-up pending there. Thanks for catching the mismatch.