Plugin never answers MCP tool-call approval requests, so every MCP call in a `task` run is denied

Summary

/codex:rescue (and any codex-companion.mjs task run) never answers MCP tool-call approval requests from the app-server, so every MCP tool call in a plugin-driven run is denied with user rejected MCP tool call. The job log shows only Tool <server>/<tool> failed.

The effect is that Codex silently loses access to all MCP servers when driven from Claude Code, while the same servers work fine in an interactive codex session. The agent then proceeds without that context and reports the servers as "unavailable", which sends you looking for a networking or MCP-config problem that does not exist.

Environment

• codex-plugin-cc 1.0.6
• codex-cli 0.147.0
• Claude Code 2.1.222, macOS 15 (arm64), Node v24.4.0
• MCP server: a local stdio server, verified healthy independently (see below)

Reproduction

1. Configure any stdio MCP server in ~/.codex/config.toml and confirm it works in an interactive codex session.
2. From Claude Code, run /codex:rescue with a prompt that requires calling that MCP server.
3. The job log shows:

[...] Calling my-server/my.tool.
[...] Tool my-server/my.tool failed.

4. The real cause is only visible in the rollout under ~/.codex/sessions/<date>/rollout-*.jsonl:

{"type": "mcp_tool_call_end",
 "invocation": {"server": "my-server", "tool": "my.tool", "arguments": {...}},
 "duration": {"secs": 0, "nanos": 0},
 "result": {"Err": "user rejected MCP tool call"}}

duration is 0 — the call never leaves the client.

Root cause

buildThreadParams / buildResumeParams in scripts/lib/codex.mjs already set:

approvalPolicy: options.approvalPolicy ?? "never",

so this is not a matter of the user's approval_policy setting — I verified that setting approval_policy = "never" in ~/.codex/config.toml changes nothing, and reverted it.

MCP tool calls evidently travel a separate approval channel from exec/patch approvals (mcp_tool_call_approval appears in the codex binary). The plugin has no handler for it. The only mcpToolCall cases in scripts/lib/codex.mjs are progress rendering:

// line ~252
case "mcpToolCall":
  return { message: `Calling ${item.server}/${item.tool}.`, phase: "investigating" };

// line ~283
case "mcpToolCall":
  return { message: `Tool ${item.server}/${item.tool} ${item.status}.`, phase: "investigating" };

There is no code path that sends a decision back for a server-initiated approval request, so the request goes unanswered and the app-server denies it.

The MCP server is not at fault

For the server in my case I verified end to end, outside the plugin:

• initialize round-trip: 1.06 s
• tools/list: returns all 20 tools
• tools/call: real data, isError: false, well-formed structuredContent
• CLI fallback against the same backend: exit 0

Transport, startup time, schemas and reachability are all fine.

Impact

Any workflow that depends on MCP from a plugin-driven Codex run is silently degraded. In my case that is a memory server the agent is instructed to consult before non-trivial work — it proceeded without project context and reported the memory as unreachable.

I did not find a workaround. codex-companion.mjs passes only sandbox and approvalPolicy to runAppServerTurn, and neither affects this.

Suggested fix

1. Handle MCP tool-call approval requests from the app-server and auto-approve them when approvalPolicy is never (which the plugin already sets), or when the workspace is trusted.
2. Optionally expose a per-run switch on task / review for stricter setups.
3. Independently of the fix: surface the real error text. Tool <server>/<tool> failed. gave no hint that approval was involved; diagnosing this required reading raw rollout JSONL. Propagating user rejected MCP tool call into the job log and /codex:status would turn a multi-step investigation into an obvious one-liner.

Start in scripts/lib/codex.mjs, reviewing buildThreadParams, buildResumeParams, and the existing mcpToolCall progress cases. Trace how runAppServerTurn and codex-companion.mjs handle app-server requests, including the mcp_tool_call_approval channel. Done means MCP calls are handled under approvalPolicy "never" and the real rejection error is surfaced in the job log or status output; verify with a stdio MCP server and the rollout JSONL.