fix(codex): write a config the client can actually start with

[MartinForReal]

Audited the Codex integration against the config reference and the client's own request builder.

The protocol was already correct

Worth stating first, since it's the part that could have been badly wrong. /v1/responses is a verbatim byte passthrough to Copilot's native endpoint, and sending Codex's exact payload shape (store:false, stream:true, include:["reasoning.encrypted_content"], prompt_cache_key, text, reasoning, tool_choice, parallel_tool_calls) produced the full canonical sequence:

response.created → response.in_progress → response.output_item.added
→ response.content_part.added → response.output_text.delta → .done
→ response.content_part.done → response.output_item.done → response.completed

Tool calling works too — 11× response.function_call_arguments.delta, .done, function_call items, with the type:"custom" apply_patch tool accepted. wire_api = "responses" matches the reference (it's the only supported value), and base_url correctly ends in /v1 because Codex does not append a version.

The defects were all on the config surface.

model_context_window was never written

The parameter was plumbed through configure_codex and unit tested with Some(272000) — but both call sites passed None.

Codex budgets context from its own built-in table, sized for OpenAI's public limits. Copilot serves the same slugs with different windows:

model	Copilot window
gpt-5.5, gpt-5.6-sol	1,050,000
gpt-5.3-codex	400,000
gpt-5-mini	264,000

So the client compacted at the wrong point in both directions. It's now read from the live catalog for whichever model ends up selected — looking it up for the recommended default would hand a 1M window to a config pinned to a 264K model. Verified:

model = "gpt-5-mini"
model_context_window = 264000

The key stays unwritten when the catalog is unreachable, and the headless path uses a token already on disk rather than starting a device flow nobody is watching.

model was overwritten unconditionally

Running setup replaced a deliberate choice with the recommended default. Now only written when absent:

# before: model = "gpt-5.5"
model = "gpt-5.6-sol"          # kept
model_context_window = 1050000
model_provider = "ghc-proxy"   # still moves — that's the point of the flag
approval_policy = "on-request" # untouched

The setup guide also printed the default model name even when it had kept a different one, so configure_codex now returns the model it settled on.

The provider block named no API key

A proxy configured with api_key was unreachable from Codex with no config path to fix it. It now gets env_key = "GHC_PROXY_API_KEY" — the same variable the proxy reads, so one exported value serves both sides — but only when a key is set, because Codex fails a turn when a provider names an environment variable that is missing.

service_tier: no change, and that's the finding

This looked like an unconditional override worth gating. Probing Copilot says otherwise:

value	result
"priority" / "auto" / "default" / "flex"	400 service_tier is not supported
null	200
omitted	200

The existing nulling is load-bearing. Gating it would have been a regression, so it stays — now with a comment recording the probe so the next reader doesn't undo it. Codex's Fast mode silently does nothing as a consequence, which is documented.

Also verified, no action

Copilot returns no reasoning items or encrypted_content despite the request asking for them. That's upstream, not the proxy — passthrough is byte-verbatim. Codex tolerates it; reasoning continuity across turns is simply unavailable.

The WebSocket transport stays unadvertised. The proxy implements ws:/responses, but Codex's WS path is a much larger contract — v2 response.create with OpenAI-Beta: responses_websockets=2026-02-06, previous_response_id, incremental input deltas and x-codex-turn-state sticky routing.

169 tests pass; cargo fmt --all --check and cargo clippy --all-targets -- -D warnings are clean.