Codex CLI in gstack skills 400s on ChatGPT-account auth — model entitlement issue, needs `-m gpt-5.2` injection

[TJ-NomoAI]

Problem

codex CLI v0.121.0 defaults to gpt-5.2-codex. ChatGPT-account (Plus) auth no longer serves any *-codex model variant since ~March 2026 (OpenAI server-side entitlement regression, not a billing cap — caps are 429/402, this is 400 invalid_request_error). Rejected slugs: gpt-5.2-codex, gpt-5-codex, gpt-5.1-codex, all *-codex-mini, codex-mini-latest, AND plain gpt-5. Working slug on ChatGPT auth: gpt-5.2 (general model, same generation, no -codex tuning).

Refs: openai/codex#19654, openai/codex#14735, openai/codex#14412.

Impact on gstack

Every gstack skill that shells codex constructs the command without -m, so every codex invocation 400s on ChatGPT-account users. Affected skills (non-exhaustive):

• /plan-eng-review — Outside Voice step (codex exec)
• /codex — review / challenge / consult modes (codex review, codex exec)
• /ship — adversarial review step
• /autoplan — pipeline of the above
• /plan-ceo-review — Outside Voice step
• /plan-design-review — Outside Voice step

API-key users (OPENAI_API_KEY set, no ChatGPT auth) are unaffected. Blocked for every ChatGPT-account codex invocation until users manually add -m per command or globally configure their ~/.codex/config.toml.

Failure shape

ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.2-codex' model is not supported when using Codex with a ChatGPT account."}}

(swap the model slug per CLI version default)

User-side workaround (per-command)

Inject -m gpt-5.2 into every codex invocation. Cost-isolation preserved: -m only changes the slug; auth still resolves from ~/.codex/auth.json (ChatGPT/Plus flat-rate). Does NOT switch to API-key auth.

# codex exec
codex exec "<prompt>" -C "$REPO_ROOT" -s read-only -m gpt-5.2 -c 'model_reasoning_effort="high"' < /dev/null

# codex review (NOTE: no -m/--model flag on this subcommand in v0.121.0 — model goes via -c)
codex review --base origin/main -c model="gpt-5.2" -c model_reasoning_effort="high"

User-side workaround (durable / config)

# ~/.codex/config.toml
model = "gpt-5.2"
model_reasoning_effort = "high"

This fixes ALL sessions globally. Per-user opt-in if global config doesn't match their setup.

Probe trap

Do NOT verify model selection with a trivial "reply with exactly: OK" probe — codex silently falls back to a working default and echoes the string regardless of -m, so the probe false-positives. Verify with a real task and grep stderr for not supported when using Codex to distinguish entitlement-rejection from success.

Proposed direction

Inject -m gpt-5.2 into the codex invocations in shipped skill files (the mechanical fix unblocks ChatGPT-account users immediately). Longer-term, detecting auth type at skill-time and only injecting when ChatGPT-auth is detected would avoid locking the model slug for API-key users who can still use *-codex — but that's a maintainer-shape call.

Repro

codex exec "what's 2+2" -s read-only < /dev/null
# 400 invalid_request_error on ChatGPT-account
codex exec "what's 2+2" -s read-only -m gpt-5.2 < /dev/null
# works

References

• gpt-5.5 shown in Codex, but rejected for ChatGPT Plus account with 400 unsupported-model error openai/codex#19654, #14735, #14412 (model-entitlement reports)
• Community thread: "gpt-5-2-codex model is not supported"
• Surfaced in a downstream gstack-using workflow when /plan-eng-review Outside Voice 400'd against ChatGPT-Plus auth (2026-05-20)