GPT-5.5 tool calls fail with "unsupported call: exec_commandexec_command" — model sends self-referential namespace on built-in tool calls

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #31609
• #31656
• #31617
• #31611

Powered by Codex Action

Thanks for the duplicate flags — confirming and adding what I've found since filing, in case it's useful for triage.

Cross-referencing: #31609 is the same bug with the same error text. #31656 is valuable extra evidence — it shows this isn't exec_command-specific: on Codex App Remote SSH the same self-namespacing hits list_mcp_resources and list_mcp_resource_templates too (unsupported call: list_mcp_resourceslist_mcp_resources, etc.), which matches the client-side mechanism below (any built-in tool call is vulnerable, not just the shell tool). #31617 and #31611 independently report that downgrading Codex CLI fixes it, which I want to correct/refine below since I initially assumed a downgrade wouldn't help.

Root cause (client-side mechanism, confirmed via source + my own rollout logs):

Comparing a failing GPT-5.5 session against a working GPT-5.4 session in my local ~/.codex/sessions/**/rollout-*.jsonl, the raw function_call items differ like this:

• GPT-5.5: "type":"function_call","name":"exec_command","namespace":"exec_command",...
• GPT-5.4: "type":"function_call","name":"exec_command",... (no namespace field)

GPT-5.5 is attaching a self-referential namespace (equal to the tool name) to built-in tool calls; GPT-5.4 never does. Tracing what Codex does with that:

1. codex-rs/core/src/tools/router.rs (build_tool_call) builds ToolName::new(namespace, name) straight from the model's ResponseItem::FunctionCall, with no validation against what's actually registered.
2. codex-rs/core/src/tools/registry.rs (self.tool(&tool_name)) does an exact {name, namespace} match. Built-in tools are registered as ToolName::plain(name) (namespace: None), so the incoming {name:"exec_command", namespace:Some("exec_command")} matches nothing → falls into the "unsupported call" branch.
3. codex-rs/protocol/src/tool_name.rs's Display impl for ToolName does write!(f, "{namespace}{}", self.name) — no separator — which is why the error text is the tool name glued to itself.

Correction on the regression window: I originally diffed rust-v0.142.0...rust-v0.143.0 and found registry.rs/tool_name.rs/router.rs unchanged, and concluded downgrading wouldn't help. That was wrong — I was diffing against the wrong baseline. #31617 downgraded to codex-cli 0.142.5 and #31611 downgraded to @openai/codex@0.140.0, both npm/version numbers that predate rust-v0.143.0. Diffing rust-v0.142.5...rust-v0.143.0 instead, codex-rs/core/src/tools/router.rs did change in that window (a TurnContext → StepContext refactor, plus CustomToolCall gaining namespace handling it didn't have before), alongside the "MCP tools now use tool search by default" feature landing in 0.143.0. I can't fully pin from client-side diffs alone whether it's that router refactor, the tool-search-default flip changing what's presented to the Responses API, or a GPT-5.5-side rollout coinciding with the same date — but empirically:

I downgraded my own Homebrew install (macOS arm64) straight to the rust-v0.142.5 release binary (swapped /opt/homebrew/bin/codex to point at the rust-v0.142.5 codex-aarch64-apple-darwin asset, bypassing the cask) and re-ran the exact repro:

codex exec -m gpt-5.5 --sandbox read-only "You must use the shell tool to run: pwd"

This now succeeds — GPT-5.5 runs the shell tool correctly, no unsupported call error. So the downgrade reports in #31617/#31611 check out and are the best current workaround, better than pinning -m gpt-5.4 if you want GPT-5.5's quality with tool use.

Suggested fix directions, independent of pinning down the exact server-side trigger:

• Client: registry lookup should fall back to a plain (unnamespaced) match when the exact {name, namespace} lookup misses and the name matches a registered built-in tool — turns a guaranteed failure into a successful dispatch, and is safe since it only ever fires on a call that would otherwise hard-fail anyway.
• Client: ToolName's Display should insert a separator between namespace and name regardless, so future instances of this class of error are legible instead of concatenated.
• Worth checking whether the tool_search-default-on rollout in 0.143.0 (#29486) is what's nudging GPT-5.5 into emitting namespaced calls for tools that were never registered under a namespace.

Happy to help verify a fix against 0.143.0 + gpt-5.5 once one's up — my original detailed writeup with more session-log samples is above.

Same: Title: Agent shell calls fail with "unsupported call: exec_commandexec_command"

Product: Codex
Severity: Blocker — agent cannot execute any shell command

Observed behavior:
Every agent-initiated shell call, including pwd, fails before execution with:

unsupported call: exec_commandexec_command

Expected behavior:
The shell tool should execute pwd and return the working directory.

Important distinction:
Running pwd through <user_shell_command> succeeds:
Exit code: 0
Output: /home/examiner/projects/get-lost-in-portland

Troubleshooting completed:

• Restarted Codex several times
• Opened a new terminal window
• Uninstalled and reinstalled Codex
• Reproduces in fresh sessions

This suggests tool registration or backend dispatch is combining the
namespace/function name incorrectly.

Environment:

• Codex version: [paste version]
• Codex surface: [CLI / desktop / VS Code]
• OS and version: [paste]
• Shell: bash
• Model: [paste model]
• Approximate occurrence time and timezone: [paste]
• Account email: provide only through private OpenAI Support

I can independently reproduce this issue on Ubuntu under WSL.

Environment

• Codex CLI failing version: 0.143.0
• Codex CLI working version after downgrade: 0.140.0
• Install method: global npm package (@openai/codex)
• Model: gpt-5.5
• Reasoning effort: medium
• Node.js: v22.22.1
• npm: 10.9.4
• Client: interactive Codex TUI
• Working directory: /home/user/project

Failure on 0.143.0

In a fresh Codex session, I asked Codex to run only basic read-only commands:

pwd
git status --short --branch
git rev-parse HEAD
git rev-list --left-right --count origin/main...HEAD
true

The first captured rejected tool call was:

• requested tool: exec_command
• requested command:

git status --short --branch && git rev-parse HEAD && git rev-list --left-right --count origin/main...HEAD

• working directory: /home/user/project

The raw rejection was:

unsupported call: exec_commandexec_command

The rejected call was also reported as:

exec_command.exec_command

Subsequent attempts with trivial commands such as:

pwd
git status --short --branch
ls
true

were all rejected before the shell command actually ran.

Fresh-session confirmation

I then opened a completely new Codex session on 0.143.0 and repeated a minimal execution-tool smoke test.

The new session also failed to execute the basic commands.

So this was not limited to one corrupted conversation/thread.

A/B downgrade test

I downgraded only the Codex CLI package:

npm install -g @openai/codex@0.140.0

Then I opened another fresh Codex session in the same environment and repeated:

pwd
git status --short --branch
git rev-parse HEAD
git rev-list --left-right --count origin/main...HEAD
true

All commands executed successfully.

Observed successful behavior included:

pwd
/home/user/project

git status --short --branch
## main...origin/main

git rev-list --left-right --count origin/main...HEAD
0    0

and:

true
exit code 0

Local A/B result

Codex CLI 0.143.0 + GPT-5.5
→ tool execution fails
→ raw error: unsupported call: exec_commandexec_command

Codex CLI 0.140.0 + GPT-5.5
→ same environment
→ fresh session
→ basic command execution works

This looks like a regression affecting tool-call routing or tool-name construction rather than a shell, Git, repository, or command-specific failure.

I have not attached auth files, local state databases, conversation history, or private repository contents. I can provide additional sanitized diagnostics if useful.

Also observed on my setup. Without tools, Codex would be just ChatGPT in terminal. This is a serious bug that should be fixed immediately.

downgrade to 0.140.0 worked for me.

I'm encountering the same issue in a local Codex CLI session.

The command does not appear to reach the shell at all. Even simple commands such as pwd and ls fail before execution.

Codex shows the tool call as:

exec_command.exec_command

With arguments similar to:

{
  "cmd": "pwd",
  "workdir": "<project-directory>"
}

But the returned error is:

unsupported call: exec_commandexec_command

I also reproduced the same failure with commands such as:

ls
pwd && rg --files -g 'AGENTS.md' ...

All of them fail with the same unsupported call: exec_commandexec_command error before the command is actually executed.

This looks like a tool routing or tool-name serialization issue, where exec_command.exec_command is being collapsed or duplicated into exec_commandexec_command. It does not appear to be related to the shell command itself, project path, permissions, or proxy configuration, since no command reaches the terminal.

Environment:

Codex CLI: 0.143.0
OS: Linux on WSL
Model: GPT-5.5

I can confirm the same issue on my machine.

Environment:

• OS: Ubuntu 20.04 x86_64
• Codex CLI: 0.143.0
• Install method: npm global install
• Auth mode: ChatGPT

Minimal repro:

codex -a never -s read-only exec --json --skip-git-repo-check -m gpt-5.5 -c 'model_reasoning_effort="high"' "You must use the shell tool to run: pwd"

Observed:

- router logs unsupported call: exec_commandexec_command
- failing session records name="exec_command" and namespace="exec_command" on the built-in tool call
- local failing sessions correlate with model=gpt-5.5, multi_agent_version=v2, comp_hash=3000
- local working sessions with gpt-5.4 use name-only tool calls and work normally
- --disable multi_agent did not change the outcome locally; reproduced sessions still recorded multi_agent_version=v2 and the same malformed tool call shape

This does not look project-specific on my side. I reproduced it across multiple working directories.

Confirmed on macOS 26.5 arm64 with Codex CLI 0.143.0 installed globally
through npm/NVM (Node 24.18.0, npm 11.18.0).

Two fresh sessions failed before process creation. One rendered:

unsupported call: exec_commandexec_command

and the next rendered:

unsupported call: exec_command

Both pwd and a read-only sed command failed with no exit code. Restarting
while remaining on 0.143.0 did not help. Downgrading only the CLI to 0.142.5
immediately restored built-in command execution.

Originally reported as #31740; closing that report as a duplicate.

Confirming and adding two data points not yet in this thread:

1. Still broken on the latest alpha. Reproduced identically on 0.144.0-alpha.4 (not just 0.143.0), so whatever's in that alpha didn't touch this path.

2. Not scoped to unified_exec. Ran with --disable unified_exec on gpt-5.5 — the malformed call just renames itself: unsupported call: shell_commandshell_command instead of exec_commandexec_command. Same self-referential-namespace shape, different built-in tool. So this isn't something users can dodge via feature flags; the router has no fallback for any built-in tool once namespace == name.

3. Confirms the false-negative risk worth flagging loudly: I tested with a canary file (cat a file containing a random string only the shell could read). Under gpt-5.5 it failed 3x and correctly reported it couldn't verify the contents. But a plain pwd request under the same broken model returned the correct answer without ever executing anything — it inferred cwd from context already visible in the session banner. So affected users may not notice command execution is fully broken unless they test with something the model can't guess. Given @rymalia and @yuanchangsai77's reports above that downgrading the CLI (not just the model) to 0.142.5/0.140.0 restores execution while staying on gpt-5.5 — that seems like the most promising lead for a workaround that doesn't require giving up gpt-5.5, worth digging into what capability the newer CLI is advertising that the older one isn't (possibly the model only emits the malformed namespace when the client signals support for namespaced/nested tool calls).

Env: Codex CLI 0.143.0 and 0.144.0-alpha.4, npm global install, Ubuntu 24.04 x86_64, sandbox_mode = "danger-full-access".

Reproduced this on macOS (Darwin, arm64) with Codex CLI 0.143.0 installed via npm (@openai/codex). 

Same symptom: gpt-5.5 tool call gets rejected as unsupported call: exec_commandexec_command, list_mcp_resourceslist_mcp_resources 

Also:

With model_provider = "openai" (the default), gpt-5.5 hits the namespace-duplication bug above. Calls fail, retry, and often eventually get through after several rounds, burning a lot of tokens along the way.

With model_provider = "openai_https" (a custom provider block, wire_api = "responses", no lite flag set), gpt-5.5 gets rejected outright by the API itself instead:

``
{"error":{"message":"This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.","type":"invalid_request_error","param":"model","code":"unsupported_value"}}
``

gpt-5.4 was clean.

For those still hitting tool-calling issues (namespace doubling, broken HTML rendering): before rolling back to 0.142.5, check whether your install is actually complete.

My symptoms matched what's being reported here, but the root cause turned out to be a missing platform binary — @openai/codex-linux-x64 — not a version regression. The global npm install -g had silently skipped the optional dependency, leaving an incomplete install regardless of version.

Fix (Linux x64):

npm install -g @openai/codex@0.143.0
cd ~/.nvm/versions/node/$(node -v)/lib/node_modules/@openai/codex
npm install --include=optional

That installs codex-linux-x64 into the correct nested location. Currently running 0.143.0 without issue — tool calls passing, HTML rendering correctly.

Independent confirmation via Codex internal logs (logs_2.sqlite)

Adding router-side trace evidence from a separate repro on macOS arm64, standalone install (not Homebrew/npm), in case it helps triangulate the client-side fix.

Environment

• macOS, Apple Silicon
• Codex CLI: 0.143.0 standalone (~/.codex/packages/standalone/releases/0.143.0-aarch64-apple-darwin)
• Model: gpt-5.5, model_reasoning_effort = "medium", approvals_reviewer = "auto_review"
• 108 failures between 11:11 and 16:58 today, all on exec_command, zero on apply_patch

What the local trace shows

From ~/.codex/logs_2.sqlite, the failure path in codex_core::tools::router:

handle_responses{tool_name="exec_command"}                      ← model emits correct name
  → handle_output_item_done
    → handle_tool_call
      → handle_tool_call_with_source
        → dispatch_tool_call_with_code_mode_result{
            otel.name=exec_commandexec_command                   ← name DOUBLES at this span
            tool_name=exec_commandexec_command
            call_id=call_keRm838aDG4ruuG7ZkWyH5jK
          }
          → dispatch_tool_call_with_terminal_outcome
            → error=unsupported call: exec_commandexec_command

dispatch_duration_ms=0, handler_duration_ms=12 — the router rejects the name in-dispatcher, before any process spawn. Matches the reporter's ToolName::Display concatenation finding: Some(namespace) + name with no separator → exec_commandexec_command.

Cross-check

• apply_patch tool calls in the same failing turns route correctly (no apply_patchapply_patch in logs) → consistent with the reporter's finding that only the namespaced built-in (exec_command) trips the lookup, since apply_patch was not emitted with a namespace field by GPT-5.5 in these turns.
• I also confirmed via strings that dispatch_tool_call_with_code_mode_result exists in both 0.142.5 and 0.143.0 binaries — supporting the reporter's diff result that the regression is not in router.rs/registry.rs/tool_name.rs between those tags. The trigger is the server-side namespace field on GPT-5.5 built-in tool calls; 0.142.5 only appears "fixed" because users on it generally were not yet driving GPT-5.5 against that codepath.

Workaround that worked here

Rolling the current symlink back to 0.142.5 and pinning ~/.codex/version.json (dismissed_version: "0.143.0") restored working state, but as noted above this only sticks because the auto-update check is suppressed — the underlying client-side namespace-handling gap remains for any future GPT-5.x that emits namespace on built-in tools. Switching to gpt-5.4 per the reporter's workaround also resolves it without a downgrade.

Happy to provide the raw logs_2.sqlite query output or the exact SQL if useful for the fix.

Can also confirm this on macos

Confirming on Linux x86_64 (Ubuntu 26.04, @openai/codex 0.143.0 via npm, node 22, ChatGPT auth over the websocket responses API), and adding a data point I haven't seen in this thread: the trigger correlates with the login shell advertised to the model ($SHELL).

With SHELL pointing at zsh, every built-in call arrives self-namespaced and fails as described (RUST_LOG=codex_api=trace shows name: "exec_command", namespace: Some("exec_command"); the first call's arguments also carry "shell":"zsh"). With SHELL=/bin/bash and the exact same prompt, the calls arrive with no namespace field and execute normally on unmodified 0.143.0:

# fails: "unsupported call: exec_commandexec_command" (model may then fabricate the output!)
SHELL=/usr/bin/zsh codex exec --skip-git-repo-check -s read-only \
  'Run the shell command: echo codex-exec-test. Report its exact output.'

# works, zero router errors
SHELL=/bin/bash codex exec --skip-git-repo-check -s read-only \
  'Run the shell command: echo codex-exec-test. Report its exact output.'

Notes:

• Not the user's zsh config: reproduced with ZDOTDIR pointing at an empty directory.
• Feature flags don't help: --enable unified_exec_zsh_fork, --enable shell_zsh_fork, --enable non_prefixed_mcp_tool_names all still fail; --disable unified_exec just moves the failure to shell_commandshell_command.
• This supports the theory that the server-side trigger is in what the client advertises about the shell environment, since flipping $SHELL alone toggles whether GPT-5.5 emits the self-referential namespace.
• Severity note for triage: after a few failed exec_command attempts, the model sometimes fabricates the command output in its final answer as if the command had run. In exec mode with no visible error, this silently produces made-up results.

So besides downgrading, SHELL=/bin/bash (e.g. in a small wrapper around codex) is a workaround that keeps 0.143.0 + gpt-5.5 usable, at the cost of the model driving bash instead of zsh.

Reproducable and also present with the latest release on Arch Linux; occuring even with complete purge of files when installing vithe AUR, npm, and the curl'd bash script.

I ran the public issue description through Rootlyze as a quick test.

Likely pattern: model-version tool-call schema drift — GPT-5.5 emits a self-referential namespace on built-in tool calls, and the local router treats it as part of the tool name.

Evidence from the issue: GPT-5.5 sends name="exec_command" plus namespace="exec_command", while GPT-5.4 sends the same tool call without namespace. The router then resolves it as exec_commandexec_command, rejects it, and the model retries the same failing call.

Next check: verify whether built-in tools should ignore namespace when it equals the tool name, or fall back to a name-only lookup when namespace lookup fails.

Prevention: add a compatibility guard that strips self-referential namespaces for built-in tools and logs unknown namespace fields instead of producing a doubled tool name.

Limitation: based only on the public issue text, not the full trace/log.

If you have a sanitized trace, I can run the full version through Rootlyze. Please remove secrets, API keys, tokens, customer data, credentials, and private URLs first.

The 0.142.5 → 0.143.0 trigger, pinned from source: gpt-5.5's model-catalog entry newly sets include_skills_usage_instructions: true, and the instructions it injects teach dotted-namespace tool addressing

Building on @growthringsadvisory's trace (which pinned the dispatch mechanism and the regression window but left the trigger open between the router refactor, the tool-search flip, and a server-side rollout) — I diffed the window file-by-file and believe the trigger can be pinned to one model-catalog field.

**1. The dispatch path is byte-identical across the window — so the regression is in what the client sends, not how it dispatches.**

• core/src/tools/registry.rs and protocol/src/tool_name.rs: identical between rust-v0.142.5 and rust-v0.143.0 (diff -q clean).
• core/src/tools/router.rs: the ResponseItem::FunctionCall arm is identical in both versions (ToolName::new(namespace, name), no validation). The only namespace-related router change in the window is CustomToolCall newly preserving namespaces (#30302) — a different item type than the failing function_calls.

2. The only bundled model-catalog change for gpt-5.5 in this window is a single field. Diffing models-manager/models.json between the tags, the gpt-5.5 entry changes in exactly one way: include_skills_usage_instructions: (absent) → true. Cross-checks: gpt-5.4 has it false/absent (works); on current main, all three gpt-5.6-* models have it false — and none of the 5.6 reports show this particular failure — while gpt-5.5 still has it true.

3. The field is brand-new in 0.143.0 — a 0.142.5 client cannot even parse it. include_skills_usage_instructions appears nowhere in the rust-v0.142.5 tree (not in models.json, not in protocol/src/openai_models.rs). So even if model info is refreshed from a remote catalog, downgraded clients are structurally immune. That makes every "downgrade fixes it" report (here, #31617, #31611, #31639) consistent with a client-shipped trigger, with no need to assume a coincident server-side model change.

4. What the flag injects is instruction text that demonstrates dotted-namespace tool calls. When the flag is true, core/src/context/available_skills_instructions.rs appends SKILLS_HOW_TO_USE_WITH_ABSOLUTE_PATHS / ..._WITH_ALIASES to a developer-role context fragment. That text repeatedly addresses tools in namespace.name form: "must be accessed through skills.list and skills.read", "call skills.list with {"authority":{"kind":"orchestrator"}}", "pass its main_resource to skills.read". This is a new source of dotted tool addressing in the default context for gpt-5.5 sessions, introduced in exactly the failing window, gated to exactly the failing model.

Putting it together: gpt-5.5 sessions on ≥0.143.0 receive instructions demonstrating namespace.name addressing; the model generalizes the convention to plain built-in tools and emits a self-referential namespace — visible as "namespace":"exec_command" in the rollout logs above, and literally rendered dotted as exec_command.exec_command in @pzy19-prog's report. The unchanged exact-match registry lookup then rejects the call, and the separator-less Display prints the glued exec_commandexec_command. #31656's list_mcp_resourceslist_mcp_resources is the same mechanism hitting another plain tool.

Falsifiable predictions, checkable by anyone affected:

• Failing gpt-5.5 sessions' rollout JSONLs should contain the skills-instructions block (the fragment with the skills.list / skills.read text); gpt-5.4 sessions on the same client should not.
• The failure should not reproduce with gpt-5.6-sol/terra/luna on the same client (flag is false for those) — consistent with reports so far.

Fix directions this supports (each independently sufficient):

• Catalog: set include_skills_usage_instructions: false for gpt-5.5, or reword SKILLS_HOW_TO_USE_* so it stops demonstrating dotted addressing to models that over-generalize it. (The 5.6 models shipping with false suggests the per-model targeting is deliberate and cheap to revise.)
• Client hardening, as proposed above: a plain-name fallback in the ToolRegistry lookup when the exact {name, namespace} lookup misses (only fires on calls that would otherwise hard-fail), plus a separator in ToolName's Display so future instances of this class stay legible. As of current main, the lookup is still exact-match-only and Display still concatenates without a separator.

Caveat: this is static analysis over the tagged sources plus the logs already in this thread — I haven't run a live gpt-5.5 session. Happy to be corrected by anyone who can flip the flag locally and observe the behavior change.