Codex CLI 0.143.0 duplicates tool call names, causing unsupported call errors and no shell access

What version of Codex CLI is running?

0.143.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

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

WSL

Codex doctor report

codex doctor --all reports:

17 ok · 1 idle · 0 warn · 0 fail
install: consistent
state DB: integrity ok
auth: configured
websocket: connected
sandbox: restricted fs + restricted network · approval OnRequest

Feature flags tested:

shell_snapshot                       stable             false
shell_tool                           stable             true
unified_exec                         stable             false
unified_exec_zsh_fork                under development  false

Then I also tested:

shell_snapshot                       stable             false
shell_tool                           stable             true
unified_exec                         stable             true
unified_exec_zsh_fork                under development  false

What issue are you seeing?

Codex CLI 0.143.0 on WSL Ubuntu starts normally and codex doctor --all reports no failures, but tool execution is broken inside Codex sessions.

The tool dispatcher appears to duplicate tool call names before execution. As a result, commands never reach the OS and Codex cannot use the terminal, read files, or create files.

Observed errors include:

unsupported call: shell_commandshell_command
unsupported call: exec_commandexec_command
unsupported call: get_goalget_goal

Earlier in the same environment I also saw:

{
"type": "error",
"error": {
"type": "invalid_request_error",
"message": "[ObjectParam] [input[89].namespace] [unknown_parameter] Unknown parameter: 'input[89].namespace'."
},
"status": 400
}
Environment
Codex Doctor v0.143.0 · linux-x86_64
Codex version: codex-cli 0.143.0
Install method: npm
Executable: /home/<username>/.nvm/versions/node/v20.20.2/bin/codex
Node: v20.20.2
OS: Ubuntu 24.04 noble under WSL
Terminal: Windows Terminal
Auth mode: ChatGPT
Model: gpt-5.5
Reasoning effort: high
Sandbox: workspace-write
Approval policy: on-request

codex doctor --all reports:

17 ok · 1 idle · 0 warn · 0 fail
install: consistent
state DB: integrity ok
auth: configured
websocket: connected
sandbox: restricted fs + restricted network · approval OnRequest

Feature flags tested:

shell_snapshot stable false
shell_tool stable true
unified_exec stable false
unified_exec_zsh_fork under development false

Then I also tested:

shell_snapshot stable false
shell_tool stable true
unified_exec stable true
unified_exec_zsh_fork under development false

The issue still reproduces.

Reproduction steps

From WSL Ubuntu:

mkdir -p ~/Temp/Export
cd ~/Temp/Export
pwd
which codex
codex --version
codex --sandbox workspace-write --ask-for-approval on-request

Output outside Codex:

/home/<username>/Temp/Export
/home/<username>/.nvm/versions/node/v20.20.2/bin/codex
codex-cli 0.143.0

Inside Codex, ask it to run:

Please test the terminal tool. Run:
pwd
ls -la
python3 - <<'PY'
from pathlib import Path
p = Path("codex_executor_test.txt")
p.write_text("ok", encoding="utf-8")
print(p.read_text(encoding="utf-8"))
PY
Expected behavior

Codex should execute the commands through the local terminal tool, list the current directory, create codex_executor_test.txt, and print ok.

Actual behavior

Codex does not execute any command. The local tool call fails before reaching the OS.

Examples of actual errors:

unsupported call: shell_commandshell_command
unsupported call: exec_commandexec_command
unsupported call: get_goalget_goal

Codex reports that the terminal tool is unavailable due to an internal tool interface error. No files are created.

Notes

This does not look like a WSL filesystem or permissions issue:

WSL itself can access the working directory.
cd, pwd, which codex, and codex --version work normally outside Codex.
codex doctor --all reports no failures.
The issue affects multiple tool names, not only shell execution.
The duplicated names suggest a tool dispatcher or tool call serialization issue.
Config

Relevant ~/.codex/config.toml:

mcp_servers = {}
model = "gpt-5.5"
model_reasoning_effort = "high"
personality = "pragmatic"

sandbox_mode = "workspace-write"
approval_policy = "on-request"
check_for_update_on_startup = false

[sandbox_workspace_write]
writable_roots = [
"/home/<username>",
"/mnt/c/Users/<username>"
]
network_access = false

[projects."/home/<username>"]
trust_level = "trusted"

[projects."/mnt/c/Users/<username>"]
trust_level = "trusted"

[tui]
session_picker_view = "dense"
pet = "disabled"
status_line = ["model-with-reasoning", "current-dir", "context-remaining", "context-window-size", "five-hour-limit"]
status_line_use_colors = true

[features]
apps = false
hooks = false
terminal_resize_reflow = true
shell_tool = true
unified_exec = true
shell_snapshot = false
Workaround attempted

I tried:

codex features disable shell_snapshot
codex features disable unified_exec
codex features enable unified_exec
rm -rf ~/.codex/tmp ~/.codex/app-server-daemon ~/.codex/app-server-control
pkill -f codex || true

I also restarted WSL with:

wsl --shutdown

The issue still reproduces in a new session.

What steps can reproduce the bug?

1. Install and run Codex CLI 0.143.0 via npm under WSL Ubuntu.

1. Confirm the environment:

codex doctor --all
codex --version
codex features list | grep -E "unified_exec|shell_snapshot|shell_tool"

### What is the expected behavior?

```markdown id="4e929f"
Codex should successfully invoke the local terminal/tool executor.

For the reproduction above, it should:

1. Execute `pwd`.
2. Execute `ls -la`.
3. Run the Python snippet.
4. Create `codex_executor_test.txt` in the current directory.
5. Print `ok`.

The tool call should be routed as a valid tool invocation, such as `shell_command` or `exec_command`, instead of being duplicated into invalid names like `shell_commandshell_command` or `exec_commandexec_command`.

### Additional information

This does not appear to be a WSL path, permissions, or filesystem issue.

Outside Codex, WSL works correctly:

```bash
cd ~/Temp/Export
pwd
which codex
codex --version