Codex Desktop MCP instability across July 2026: tool exposure mismatch, reviewer interception, malformed MCP calls, and node_repl sandboxCwd failure

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.141536

What subscription do you have?

NA

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

Codex MCP behavior has been unstable for me across the last ~2 weeks, especially in Codex Desktop.

This does not look like one single bug. I’m seeing a mix of:

1. Desktop/runtime mismatch:

Codex runtime logs show MCP tools being enumerated, but the agent-facing tool surface in the live thread does not consistently expose those tools as callable.

1. Full-access / no-review expectation mismatch:

Some external MCP calls were still routed through the approval-reviewer path even when I expected full-access / non-blocking behavior. The 404 Model not found itself was expected in my environment because that review-model backend was intentionally not wired, but the surprising behavior was that MCP tool calls still went through reviewer at all.

1. node_repl invocation failure:

``text
tool call error: tool call failed for node_repl/js`

Caused by:
Mcp error: -32602: js: codex/sandbox-state-meta: sandboxCwd must use the file URI scheme
```

1. Malformed MCP resource call generation in Desktop:

``text
failed to parse function arguments: missing field uri
``

Important clarification: built-in MCP resource listing itself does appear to work. In a fresh CLI repro, Codex successfully called the built-in MCP resource listing tool and returned:

{"resources":[]}

So the problem seems to be around external MCP tool exposure/execution and Desktop thread/tool-state consistency, not the bare list_mcp_resources API itself.

One extra detail that may help: in my local Codex state DB, thread_dynamic_tools had no persisted rows for the failing Desktop thread I checked, even though runtime logs for that same thread clearly showed successful MCP enumeration (for example hindsight tool_count=26 and node_repl tool_count=3). That makes it look like runtime MCP discovery and persisted/live thread tool state may be diverging.

Relevant sessions:

• Desktop mismatch / malformed call thread: 019f3b38-733e-7ce3-acce-0e7b78e270da
• Earlier thread I was debugging from: 019f3b2f-6c3e-7671-bc56-19e077162e05
• Full-access/reviewer-path example: 019f3b41-ae91-7243-a5f6-5fec38496b17
• node_repl failure example: 019f3b48-8c4b-7c01-83ec-01f44c946aff
• Fresh CLI resource-listing success: 019f3b59-53cc-7061-8d4d-93def40d4745

What steps can reproduce the bug?

I can reproduce multiple MCP-related failure modes.

Repro A: built-in MCP resource listing in CLI succeeds

Environment:

• Codex CLI 0.139.0
• Windows 11 x64
• Session: 019f3b59-53cc-7061-8d4d-93def40d4745

Command:

codex exec -s danger-full-access --skip-git-repo-check --cd C:\Users\Admin\Documents\Codex\2026-07-07\ope -c approvals_reviewer="user" -c features.guardian_approval=false -o C:\Users\Admin\Documents\Codex\2026-07-07\ope\work\cli_mcp_resources_last.txt "List available MCP resources in this session using the built-in MCP resource listing tool, then report the raw result exactly."

Observed result:

{"resources":[]}

Repro B: Desktop thread enumerates MCP tools, but tool availability is inconsistent

Desktop thread:

• 019f3b38-733e-7ce3-acce-0e7b78e270da

Runtime logs show successful MCP enumeration including:

server_name=node_repl tool_count=3
server_name=hindsight tool_count=26
server_name=headroom tool_count=3

But in the live thread, those tools were not consistently available as callable agent tools.

Repro C: malformed MCP call in Desktop

In the same Desktop thread:

• 019f3b38-733e-7ce3-acce-0e7b78e270da

Observed error:

failed to parse function arguments: missing field `uri`

Repro D: node_repl/js fails

Session:

• 019f3b48-8c4b-7c01-83ec-01f44c946aff

Observed error:

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: sandboxCwd must use the file URI scheme

Repro E: external MCP call still routed through reviewer path

Session:

• 019f3b41-ae91-7243-a5f6-5fec38496b17

Observed error:

This action was rejected due to unacceptable risk.
Reason: Automatic approval review failed: unexpected status 404 Not Found: Model not found

The Model not found result was expected in my local environment because that review-model backend was intentionally unwired. The bug I am reporting here is that the MCP call was still sent through reviewer unexpectedly.

Recent known-good MCP usage also exists, which makes this look regression/flakiness-related rather than a pure setup issue:

• Successful hindsight MCP calls in session 019f2e92-8a8b-74b1-8f14-318099884525

I do not have exact token/context-window numbers for every cited session, but the fresh CLI repro used 3,353 tokens according to the session output.

What is the expected behavior?

Expected behavior:

• If MCP servers are enabled and connected, the agent should consistently see the same MCP tools that runtime logs say were enumerated.
• Codex Desktop and CLI should expose a consistent agent-callable MCP tool surface for a given session.
• Built-in MCP resource listing should either return resources or an empty list without correlating with unrelated MCP tool-surface failures.
• External MCP tools like hindsight should not be unexpectedly routed through reviewer when the effective run mode is supposed to be full-access / non-blocking.
• node_repl/js should succeed for trivial calls and should not fail on sandboxCwd must use the file URI scheme.
• Codex should not emit malformed MCP calls missing required arguments like uri.

Additional information

My current interpretation is that this is a cluster of related MCP regressions, not one bug:

• list_mcp_resources works
• external MCP runtime enumeration works
• Desktop tool-surface/state is inconsistent with runtime enumeration
• full-access / non-blocking runs can still be routed through reviewer unexpectedly
• node_repl/js has a concrete invocation bug
• some Desktop turns generate malformed MCP resource calls

If useful, I can attach sanitized rollout excerpts for:

• CLI resource-listing success
• Desktop MCP enumeration lines
• reviewer rejection
• node_repl URI-format failure
• recent successful hindsight MCP usage

----

Sanitized MCP Evidence

All values below are copied from local rollout/log evidence and manually trimmed to remove local-provider URLs, bearer tokens, and unrelated workspace details.

1. Built-in resource listing succeeds

Session: 019f3b59-53cc-7061-8d4d-93def40d4745

{"resources":[]}

2. Desktop runtime enumerated external MCP tools

Thread: 019f3b38-733e-7ce3-acce-0e7b78e270da

list_all_tools{mcp_server_count=3}: listed MCP server tools while building tool list server_name=node_repl tool_count=3
list_all_tools{mcp_server_count=3}: listed MCP server tools while building tool list server_name=hindsight tool_count=26
list_all_tools{mcp_server_count=3}: listed MCP server tools while building tool list server_name=headroom tool_count=3

Later in the same thread:

list_all_tools{mcp_server_count=2}: listed MCP server tools while building tool list server_name=node_repl tool_count=3
list_all_tools{mcp_server_count=2}: listed MCP server tools while building tool list server_name=hindsight tool_count=26

At the same time, querying thread_dynamic_tools in the local Codex state DB for this thread returned no rows.

That suggests runtime MCP discovery and persisted/live thread tool state may be diverging.

3. MCP call unexpectedly routed through reviewer path

Session: 019f3b41-ae91-7243-a5f6-5fec38496b17

This action was rejected due to unacceptable risk.
Reason: Automatic approval review failed: unexpected status 404 Not Found: Model not found

Note:

• In this environment, the Model not found part was expected because the review-model backend was intentionally unwired.
• The surprising behavior was that the MCP call still went through reviewer at all.

4. node_repl/js failure

Session: 019f3b48-8c4b-7c01-83ec-01f44c946aff

tool call error: tool call failed for `node_repl/js`

Caused by:
    Mcp error: -32602: js: codex/sandbox-state-meta: sandboxCwd must use the file URI scheme

5. Malformed MCP resource call

Thread: 019f3b38-733e-7ce3-acce-0e7b78e270da

failed to parse function arguments: missing field `uri`

6. Recent successful external MCP usage

Session: 019f2e92-8a8b-74b1-8f14-318099884525

Successful hindsight MCP calls observed:

server=hindsight tool=sync_retain result=Ok
server=hindsight tool=create_mental_model result=Ok