codex exec >= 0.144.0: no shell tool exposed when config uses a custom model_provider and omits `model`
Summary
Since codex-cli 0.144.0 (0.143.0 is the last good version — bisected across 0.140.0 / 0.142.5 / 0.143.0 ✅ vs 0.144.0 / 0.144.4 / 0.144.6 / 0.145.0 ❌), codex exec exposes no shell/exec tool to the model when config.toml uses a custom model_provider (an OpenAI-compatible proxy, wire_api = "responses") and does not set a top-level model key — i.e. when the CLI resolves its own default model.
The session still works — the model answers — but it cannot run any commands. Asked to run a command, it replies e.g. "I can't run shell commands in this session because no shell execution tool is available". Notably, for predictable commands it sometimes fabricates the output instead (it claimed to have run echo hello-from-shell and printed the expected text; a random-nonce file test proved no tool existed), which makes the failure easy to miss in automation.
Repro
$CODEX_HOME/default.config.toml:
model_provider = "custom"
[model_providers.custom]
name = "Custom OpenAI-compatible proxy"
base_url = "https://<your-openai-compatible-endpoint>/v1"
env_key = "CUSTOM_API_KEY"
wire_api = "responses"
openssl rand -hex 12 > nonce.txt
codex login --with-api-key # key on stdin
codex exec --profile default --dangerously-bypass-approvals-and-sandbox --json --skip-git-repo-check \
'A file named nonce.txt exists in the current directory. Run a shell command to print its contents and paste the exact value.'
Actual (>= 0.144.0): no command_execution item ever appears in the --json stream; the agent reports no execution tool is available (or fabricates plausible output for predictable commands).
Expected (<= 0.143.0 behavior): a command_execution item runs cat nonce.txt and the correct nonce is returned.
Workaround / trigger isolation
Adding an explicit top-level model key fully restores the shell tool — even when it names the exact model the CLI resolves natively anyway (observed gpt-5.6-sol in the session file's turn_context):
model = "openai/gpt-5.6-sol" # same model the CLI picks by default → tools work again
The single deciding variable is the presence/absence of the model key; reasoning-effort/verbosity settings don't matter. Explicit-model configs are unaffected on all versions tested.
Environment
- codex-cli 0.144.0–0.145.0 (npm
@openai/codex), macOS arm64 + Linux x64 (musl) - Custom
model_providersentry,wire_api = "responses", API-key auth - Isolated
CODEX_HOME(clean config; no plugins)
Happy to provide full --json transcripts of the good/bad versions if useful.
3 Comments
My issue might be related to yours. Sometimes codex does this randomly, even if i set the
model = "..."thing. When i force it to run it, it will just return to the user, like this:another note: it looks like this is only happening for gpt-5.6* models, gpt-5.5 works fine for me.
I’m seeing a closely related issue after updating Codex. Existing/resumed sessions can suddenly lose all tools, including filesystem execution/editing and web search. Codex responds with messages like:
A new Codex session works normally and has all tools available.
I’m also using custom endpoints/model provider configuration, so there may be some interaction with model/provider state restored during
resume.I found a quick fix: run
/model, switch to another model, then switch back to the original model. After doing that, the missing tools immediately become available again.This makes it look like the resumed session’s model/tool capability state is not being refreshed correctly after an upgrade, while
/modelforces that state to be reinitialized.