Configurable codex binary (FABRICA_CODEX_BIN) + doctor detects a missing code-mode helper

[yihanzhu]

Context

The codex-code-mode-host helper (required for substantive reviews) ships ONLY inside the ChatGPT.app bundle — NOT the Homebrew cask or the npm package (verified: both ship only the codex CLI). So a complete, version-matched codex may live at a non-PATH absolute location (e.g. /Applications/ChatGPT.app/Contents/Resources/codex, which has its matched sibling helper). codex resolves the helper relative to the directory of the invoked binary. The gate scripts currently invoke bare codex (PATH lookup) with no override. Operators need to point Fabrica at a specific codex binary WITHOUT hardcoding a personal path into shipped files. Depends on the fail-loud gate-hardening issue (file it first).

Spec

• Add FABRICA_CODEX_BIN to config/models.conf, alongside the existing FABRICA_CODEX_MODEL (codex knobs live together). Default EMPTY ⇒ use codex from PATH (preserves current behavior; no hardcoded personal path in shipped files).
• Both scripts/codex-review.sh and scripts/manager-review.sh resolve codex_bin="${FABRICA_CODEX_BIN:-codex}" and invoke "$codex_bin" exec ... everywhere they currently call codex.
• CONTROL-PLANE / OPERATOR ONLY — never target-overridable. A target repo's committed .fabrica/models.conf must NOT be able to set FABRICA_CODEX_BIN (it selects which binary the operator executes — a target setting it is an arbitrary-code-execution vector, the same class as the Codex gates at explicit high effort + resolved-config echo (#110) #115 P1). Add FABRICA_CODEX_BIN to the set of keys the target-override parser recognizes-but-ignores (exactly like the gate-effort keys FABRICA_REVIEW_EFFORT / FABRICA_DEBATE_EFFORT), emitting the same visible "target override attempted to set … — ignored" warning.
• Doctor (scripts/doctor.sh): (i) verify the resolved codex binary exists and is executable; (ii) NEW check that would have caught the 2026-07-11 incident — resolve the directory codex will search for codex-code-mode-host (the directory of the invoked codex path, mirroring codex's argv0-relative resolution) and WARN if the helper is absent there, with a message like "code-mode reviews may degrade — point FABRICA_CODEX_BIN at a complete codex install (e.g. the ChatGPT desktop-app bundle)." Make it a WARN, not a hard FAIL (the helper name / resolution is codex-internal and may drift across versions).
• Docs: reviewer/codex-review.md, reviewer/manager-review.md, README model policy, and config/models.conf comments — document FABRICA_CODEX_BIN, its control-plane-only nature, and the app-bundle rationale.

Safety / sync

Touches gate scripts + config + doctor (rail-adjacent) — human sign-off. Script changes live on pull; doctor immediately. shellcheck 0.9.0 clean; bash 3.2 compatible.

[yihanzhu]

Status update after #119/#120

The blocking dependency is resolved: #119 merged and #117 is closed. However, the core premise of this issue now needs re-validation before implementation.

In Codex 0.144.4, the production ProcessOwnedCodeModeSessionProvider explicitly falls back to an in-process code-mode session when the host program is not found:
https://github.com/openai/codex/blob/rust-v0.144.4/codex-rs/code-mode/src/remote_session.rs#L73-L103

The same tag has a regression test named missing_process_host_falls_back_to_in_process_session:
https://github.com/openai/codex/blob/rust-v0.144.4/codex-rs/core/src/tools/code_mode/mod.rs#L430-L461

That means the statement that codex-code-mode-host is required for substantive reviews is no longer accurate for the current CLI. A control-plane-only FABRICA_CODEX_BIN override may still be useful for operator choice or version pinning, but that is a different rationale and should be re-scoped before code is resumed. Also, #120 moved the repository lint target from ShellCheck 0.9.0 to 0.11.0.

I removed ready and marked needs-human. The issue remains open; no implementation was merged or discarded.