node_repl: tools/list returns js but runtime routes mcp__node_repl__js as unsupported call
Summary
When js_repl = true is set in the Codex features config, the node_repl MCP server correctly:
- Reports itself as enabled via
codex mcp get node_repl - Returns
js,js_add_node_module_dir, andjs_resettools viatools/list - Successfully executes tool calls when made manually through the MCP protocol
However, the Codex agent runtime fails to resolve these tools: requests for mcp__node_repl__js (and variants like mcp__node_repl__.js) return "unsupported call" errors. This means agents cannot use the JavaScript REPL at runtime despite it being properly registered and functional through the manual MCP lifecycle.
---
Environment
| Field | Value |
|-------|-------|
| Codex Version | @openai/codex v0.133.0 |
| Platform | macOS (Apple Silicon / arm64) |
| Provider | ollama |
| Model | qwen3.6:35b-nfp4 |
| MCP Feature Flag | js_repl = true |
| MCP Config | codex mcp get node_repl => enabled: true |
---
Steps to Reproduce
- Enable the
node_replMCP server in Codex configuration:
````
[features]
js_repl = true
- Verify the MCP server is enabled:
````
$ codex mcp get node_repl
enabled: true
- The
tools/listcall from thenode_replMCP server returns:
jsjs_add_node_module_dirjs_reset
- Execute a
tools/callforjsmanually (directly through the MCP protocol) — this works correctly:
``json``
{"method": "tools/call", "params": {"name": "js", "arguments": {"code": "42 + 58"}}}
// Response: 100
- Now attempt to use
mcp__node_repl__jsthrough the Codex agent runtime. This fails with an "unsupported call" error.
---
Expected Behavior
The node_repl MCP tools should be properly injected and callable by the Codex agent runtime using the expected tool name format:
mcp__node_repl__jsshould resolve to thejstool fromnode_repl- The agent should be able to invoke JavaScript REPL commands at runtime
Actual Behavior
The Codex runtime fails to route requests to these tools:
mcp__node_repl__js => unsupported call
mcp__node_repl__.js => unsupported call
mcp__node_repl___js => unsupported call (any variant)
The node_repl namespace/description is visible but the tools within it are not exposed as callable to the agent runtime. The MCP server works end-to-end when invoked manually, confirming the server itself is not at fault.
---
Root Cause Analysis
This appears to be a tool name routing mismatch in the Codex agent's MCP tool router:
- The
node_replserver advertises tools namedjs,js_add_node_module_dir,js_reset. - When
tools/listis called, these tools are correctly returned. - However, the runtime's tool lookup mechanism does not properly map the
tools/listresults to a callable namespace in the formatmcp__{server_name}__{tool_name}.
Possible root causes:
- The
node_replserver name may contain special characters or use a different internal identifier that doesn't match the routing key. - The tool injection logic may skip tools when certain conditions are met (e.g., feature flags, server metadata).
- There could be a bug in how the
mcp__namespace prefix is generated fornode_replspecifically.
---
Evidence
1. MCP Server Status
codex mcp get node_repl => enabled: true
2. Manual tools/list Works
The node_repl MCP server returns tools successfully via the standard MCP protocol.
3. Manual tools/call Works
{"method": "tools/call", "params": {"name": "js", "arguments": {"code": "42 + 58"}}}
// Response: 100
4. Runtime Tool Resolution Fails
When the agent runtime attempts to call mcp__node_repl__js, it returns "unsupported call" — indicating the tool name was not registered or resolved in the runtime's tool registry, despite being listed by tools/list.
---
Additional Notes
- This is specific to the
node_replMCP server; other MCP servers may be unaffected. - The bug is in the runtime routing layer, not the MCP server itself (which works correctly when invoked directly).
- This prevents agents from executing JavaScript at runtime, which could be critical for coding tasks requiring JS execution.
---
Suggested Fix
Investigate the MCP tool injection/routing code that maps tools/list results to the mcp__{namespace}__{tool_name} format. Specifically:
- Check how
node_replserver name is normalized/transformed for routing. - Verify that tools from enabled MCP servers are added to the runtime tool registry.
- Ensure no conditionals or feature flag checks accidentally filter out
node_repltools during injection.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This seems consistent with a Codex-side registration/routing gap rather than a raw MCP server failure. On current
main,ToolInfo::canonical_tool_name()incodex-rs/codex-mcp/src/tools.rsproduces the namespaced callable form fromcallable_namespace+callable_name. Incodex-rs/core/src/session/turn.rs,build_mcp_tool_exposuresplits MCP tools into direct and deferred exposure before passingmcp_toolsanddeferred_mcp_toolstoToolRouter::from_turn_context.codex-rs/core/src/tools/registry.rsformatsunsupported call: {tool_name}when no matching runtime handles that tool name.So the manual
tools/callsuccess is a useful signal: it suggests the server can execute the tool, while Codex may not be registering or routing the exposed name. This may overlap with the broader MCP naming/routing work in #21576, but if not, I would check whethernode_replis being deferred behindtool_search, affected by removed/no-opjs_replconfig compatibility keys, or dropped beforeToolRouterconstruction.Sadly, yes this happens. I only know because I got gpt-5 rate limited.
Also, if we don't keep getting new comments on these "bugs" Open ai may close it due to lack of interest.