codex: retry without --profile when the first attempt fails fast

[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) 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

Dead simple, inline in launch(): run codex with --profile first; if that attempt exits nonzero AND does so fast (< 3s), relaunch without --profile. No stderr capture, no temp file, no subcommand allow-list to maintain.

The signal is timing, not the error text. codex's --profile rejection is a CLI parse-time error — it happens before codex touches auth, the gateway, or the network — so it exits in ~0.15s (measured, stable across 0.137/0.141/0.144). A codex command that actually starts a session can only fail after a network round-trip, i.e. seconds. There is no overlap, and the exit code alone can't distinguish them (the rejection and an ordinary failure both exit 1), so elapsed time is what we key on.

Why the fast-failure gate matters — this is what makes it strictly better than the status quo rather than a lateral move:

• Without the gate, a genuinely-failing codex exec "prompt" (transient gateway error, bad model) would be silently re-run without --profile. Since ucode writes a named-profile file (ucode.config.toml, not the default config.toml), no --profile means no ucode routing — codex falls back to provider: openai, i.e. the user's own OpenAI login. The gate ensures only the fast parse-time rejection is retried; a real session failure (seconds) is propagated untouched.
• stdio is inherited (no capture), so Ctrl-C reaches codex directly; quitting an interactive session raises KeyboardInterrupt that propagates past the retry check, so a normal quit is never mistaken for a rejection.

Self-adapting across codex versions: a future runtime subcommand keeps --profile (accepted, no fast failure); a future server subcommand falls back (fast reject). No ucode change needed either way.

Touches only codex.py + test_agent_codex.py; launcher.py is untouched.

Verification

• Full unit suite green (852 passed, 8 skipped); ruff + ty clean. launch() tests (fake subprocess.run + monkeypatched time.monotonic) cover: runs with --profile + sets OAUTH_TOKEN; success → no retry; fast nonzero (app-server/mcp-server) → relaunch without --profile; slow nonzero → NO retry (exit propagated); fast zero-exit → no retry.
• Timing measured empirically on codex 0.137 / 0.141 / 0.144: --profile rejection exits in ~0.13s (bounded by node cold-start); a real exec against a bad gateway fails in ~25s. ~180× separation.
• E2E driving the real codex.launch():
  • app-server --listen: --profile rejected fast → relaunch → socket bound, server alive.
  • exec against a bogus gateway: fails slowly (25s), exit 1, and does NOT retry onto provider: openai — the misroute the gate prevents.

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])