codex: try --profile, fall back on codex's rejection error

[Edwinhe03]

What

ucode codex's launch always ran codex --profile ucode <args>. But codex only accepts the global --profile on runtime subcommands. Server-family subcommands (app-server, mcp-server, exec-server, remote-control) and utilities reject it immediately:

Error: --profile only applies to runtime commands and `codex mcp`: `codex`, `codex exec`, ...

So ucode codex app-server (and the other server subcommands) was functionally broken.

Change

No version-dependent lists to maintain — instead of an allow-list, catch codex's own rejection, inline in launch():

• launch() spawns codex with --profile first, with stderr captured to a temp file, read once codex exits. A nonzero exit whose stderr contains codex's rejection message (--profile only applies to runtime commands) relaunches without --profile, swallowing the expected noise. Rejected subcommands are caller-configured anyway (omnigent runs codex app-server with its own CODEX_HOME), so omitting --profile there just stays out of the way.
• Any other outcome replays the captured stderr and propagates the exit code unchanged — an unrelated error (e.g. a broken config) is never silently retried without ucode's routing.

A temp file, unlike a pipe, has no backpressure: codex can never block on a stderr write, so nothing has to read alongside the running process (no pump thread). The trade is that codex's stderr appears at exit rather than live — and at exit is exactly when failures, the case where stderr matters, are read anyway. Ctrl-C is forwarded to codex just as exec_or_spawn does on its Windows path.

This is self-adapting: a future codex version that adds a new runtime subcommand gets --profile correctly on the first attempt, and a new server subcommand falls back — neither requires a ucode change. The rejection is instant and side-effect-free, so the fallback costs ~150ms once. If codex ever rewords the error, the launch fails loudly with codex's own message rather than silently misrouting.

The whole thing is inlined in launch() (no separate helper) and touches only codex.py; launcher.py is untouched.

Verification

• Full unit suite green (852 passed, 8 skipped); ruff + ty clean. launch() tests drive a fake Popen and cover: spawns with --profile + sets OAUTH_TOKEN; success → stderr replayed, no fallback; --profile rejection → relaunch without it, rejection swallowed; unrelated failure → propagated, no fallback; marker on a zero exit → no fallback.
• Rejection mechanics verified empirically on codex 0.137.0 (the pinned image version) and 0.141: exits nonzero in ~150ms, message on stderr with the stable prefix, no side effects; a different fast failure (invalid TOML) does not contain the marker.
• E2E driving codex.launch() against real codex:
  • app-server --listen: first attempt rejected → relaunch → socket bound, server alive, and the rejection line is absent from output (swallowed).
  • exec --help: accepted first try, exit 0, no fallback.
  • broken ucode.config.toml + exec: original error replayed to the caller, exit 1, no fallback (no silent bypass of the Databricks gateway).

Manual verification (real ucode codex CLI)

Configured ucode isolated against a live staging workspace (ucode configure --profiles <p> --agents codex --use-pat), then drove the real CLI:

• ucode codex app-server --listen unix://… (the previously-broken case): first attempt rejected → relaunch → app-server socket bound and process alive, with the rejection line absent from output. Only ucode's normal launch banner is printed.
• ucode codex mcp list (runtime subcommand): accepted with --profile on the first attempt, exit 0, no fallback.
• ucode codex exec --skip-git-repo-check "Reply with exactly: CODEX_OK": full model round-trip through the Databricks AI Gateway on the pinned model (system.ai.gpt-5-2) — replied CODEX_OK in 18s, proving --profile routing is intact end-to-end.

This pull request and its description were written by Isaac.

[lilly-luo]

am i testing this right? it seems to error on start?

i checked out your branch

no app-server:

$ uv run ucode codex
✔ Databricks auth already available for https://dbc-a5d4177a-49dc.cloud.databricks.com
✔ Unity AI Gateway detected      
                                
╭──────────────────╮
│ ucode with Codex │
╰──────────────────╯
  Model: system.ai.gpt-5-5
✔ Starting Codex
╭────────────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.143.0-alpha.14)                    │
│                                                        │
│ model:     system.ai.gpt-5-5 medium   /model to change │
│ directory: ~/ucode                                     │
╰────────────────────────────────────────────────────────╯

  Tip: New Build faster with Codex.

⚠ MCP startup interrupted. The following servers were not initialized: confluence, databricks-v2, devportal, github, glean,
  google, jira, logs-summariser, pagerduty, slack

with app-server

# lilly.luo at ip-10-93-41-23 in ~/ucode (git:edwin-he/ucode-composable-flag-injection) [14:50:55]
$ uv run ucode codex app-server
2026-07-08T14:50:56.919524Z ERROR codex_app_server: Project-local config, hooks, and exec policies are disabled in the following folders until the project is trusted, but skills still load.
    1. /home/lilly.luo/ucode/.codex
       To load project-local config, hooks, and exec policies, add /home/lilly.luo/ucode as a trusted project in /home/lilly.luo/.codex/config.toml.

2026-07-08T14:50:57.317311Z ERROR codex_models_manager::manager: failed to refresh available models: {"error_code":"BAD_REQUEST","message":"Request path '/codex/v1/models?client_version=0.143.0' doesn't match any known API type and is classified as an unmanaged api request. Set the Databricks-Model-Provider-Service header to the name of the model provider service to forward this request to."}

[lilly-luo]

1. could you help me understand why omnigent is even using ucode if it just wants the codex pass thru? why doesn't omnigent just call codex instead of ucode codex app-server
2. instead of making this a separate command, would we make this a flag? something like the below. it could be nice for people to use ucode directlyucode codex --skip-init

[lilly-luo]

follow up:
Edwin: temp bump omnigent timeout
Lilly: introduce new config setting that skips all initialization, doesnt pull fresh models, doesn't test the tools

[lilly-luo]

will we also need to maintain this list ? it also will depend on the cli version of codex that the customer is on

[Edwinhe03]

yes, I can't see how we can get around this. but problem statement is ucode unconditionally adds --profile to all codex commands when codex doesn't support --profile on all subcommands. do you have any ideas?

[lilly-luo]

can you just do a try catch on the specific error?

[lilly-luo]

can you make this less verbose? or just rm this comment

[lilly-luo]

why do we need to wrap in this temp file? it seems diff behavior from before - exec_or_spawn doesnt have the temp file

[Edwinhe03]

exec_or_spawn doesn't capture any output. we could do piping, but then need to consider error output streaming and pipe buffer

[lilly-luo]

instead of a new method, is it possible to do something inline + more simple like:

try: 
    exec_or_spawn
except Exception as e: 
    if e.msg == _PROFILE_REJECTED_MARKER:
         exec_or_spawn([binary, *tool_args])