Codex CLI 0.143.0: direct tool calls fail as `unsupported call` because tool namespace is duplicated into the tool name

What version of Codex CLI is running?

0.143.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

tmux

Codex doctor report

What issue are you seeing?

In Codex CLI 0.143.0, local/direct tool calls started failing with unsupported call.

Examples from logs_2.sqlite:

52346699  2026-07-09 14:53:02  error=unsupported call: update_planupdate_plan
52346836  2026-07-09 14:53:13  error=unsupported call: exec_commandexec_command
52347550  2026-07-09 14:54:09  error=unsupported call: list_mcp_resourceslist_mcp_resources
52349024  2026-07-09 14:56:42  error=unsupported custom tool call: apply_patchapply_patch

 The session JSONL shows the likely cause. Earlier successful direct calls had namespace: null:

{"name":"exec_command","namespace":null}
{"name":"update_plan","namespace":null}

After the failure began, the same direct tools arrived with namespace equal to name:

{"name":"exec_command","namespace":"exec_command"}
{"name":"update_plan","namespace":"update_plan"}
{"name":"list_mcp_resources","namespace":"list_mcp_resources"}
{"name":"apply_patch","namespace":"apply_patch"}

The router then appears to concatenate namespace + name without a separator or normalization, producing invalid tool names:

exec_command + exec_command -> exec_commandexec_command
update_plan + update_plan -> update_planupdate_plan
apply_patch + apply_patch -> apply_patchapply_patch

Those names do not exist, so dispatch fails with unsupported call.

### What steps can reproduce the bug?

1. Install or run Codex CLI `0.143.0`.
2. Use the normal local Codex home, for example `CODEX_HOME=~/.codex`.
3. Start a fresh Codex session. In my repro this was not a resumed session.
4. Ask Codex to perform any simple local/direct tool action, for example:

   ```text
   run `pwd`
   ```

   or:

   ```text
   run `echo hello`
   ```

5. Observe that the tool call fails with `unsupported call`.
6. Try other built-in/direct tools such as `update_plan`, `write_stdin`, `list_mcp_resources`, `get_goal`, or `apply_patch`.
7. Observe that those calls fail in the same pattern.
8. Downgrade to Codex CLI `0.140.0` using the same `~/.codex` and same working directory.
9. Start a new session and repeat the same simple tool request.
10. Observe that tool execution works normally again.

### What is the expected behavior?

_No response_

### Additional information

This does not look like a corrupt old session, sqlite issue, sandbox issue, or approval-policy issue. A fresh `0.143.0` session reproduced the same failure, while downgrading to `0.140.0` immediately restored normal tool execution under the same local environment.

The key symptom in `~/.codex/logs_2.sqlite` is that direct tool names appear to be duplicated before dispatch:

```text
unsupported call: exec_commandexec_command
unsupported call: update_planupdate_plan
unsupported call: write_stdinwrite_stdin
unsupported call: list_mcp_resourceslist_mcp_resources
unsupported call: get_goalget_goal
unsupported custom tool call: apply_patchapply_patch

For the affected original session, the relevant log rows include:

52346699  2026-07-09 14:53:02  error=unsupported call: update_planupdate_plan
52346836  2026-07-09 14:53:13  error=unsupported call: exec_commandexec_command
52347550  2026-07-09 14:54:09  error=unsupported call: list_mcp_resourceslist_mcp_resources
52349024  2026-07-09 14:56:42  error=unsupported custom tool call: apply_patchapply_patch

The JSONL rollout shows failing direct tools being emitted with namespace equal to name:

{"name":"exec_command","namespace":"exec_command"}
{"name":"update_plan","namespace":"update_plan"}
{"name":"list_mcp_resources","namespace":"list_mcp_resources"}
{"name":"apply_patch","namespace":"apply_patch"}

The router then appears to combine namespace and name without normalization, producing invalid tool names such as:

exec_command + exec_command -> exec_commandexec_command
update_plan + update_plan -> update_planupdate_plan
apply_patch + apply_patch -> apply_patchapply_patch

By contrast, earlier successful direct calls in the rollout used namespace: null, for example:

{"name":"exec_command","namespace":null}
{"name":"update_plan","namespace":null}

state_5.sqlite also shows thread_dynamic_tools count was 0 for the affected session, so this does not appear to be caused by stale dynamic-tool registration.

The most likely regression is in direct/local tool namespace handling in 0.143.0: direct tools should dispatch as name, and namespace == name should not produce name + name.