MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call'

[calvintkm]

Auto-mirrored from upstream for the consensus-loop backlog. Do not edit below by hand.

Upstream: openai#16685
Area / crate: codex-exec (+ codex-mcp)

Acceptance criteria

• MCP tool calls invoked under codex exec must complete (not be auto-cancelled with 'user cancelled MCP tool call'). Identify the regression that cancels them in exec mode and restore correct behavior; add a test exercising an MCP tool call in exec mode.

---

Original upstream report (openai#16685)

Bug Description

All MCP tool calls are immediately cancelled when using `codex exec` mode. This affects every MCP server, not just specific ones.

Reproduction

1. Any MCP server in `~/.codex/config.toml`:
```toml
[mcp_servers.minimal]
command = "node"
args = ["/path/to/any-mcp-server.js"]
```

2. Run exec mode:
```bash
codex exec --json --full-auto "Call the MCP tool"
```

3. Observed JSONL output:
```json
{"type":"item.started","item":{"type":"mcp_tool_call","server":"minimal","tool":"count","status":"in_progress"}}
{"type":"item.completed","item":{"type":"mcp_tool_call","server":"minimal","tool":"count","status":"failed","error":{"message":"user cancelled MCP tool call"}}}
```

Key Evidence

• Reproduces with the trivial MCP SDK example server (the `count` tool from `@modelcontextprotocol/sdk/examples/server/progressExample.js`) — not specific to any particular MCP server
• Direct stdio MCP client calls to the same servers succeed — the servers themselves are healthy
• Removing all hooks and AGENTS instructions doesn't change the behavior — hooks are not involved
• Codex log outputs: `request_user_input is not supported in exec mode`
• `codex features list` shows `codex_hooks = false`

Diagnosis

Codex exec mode appears to hit an MCP elicitation/user-input path during tool invocation. Since exec mode doesn't support interactive input, this triggers cancellation of the MCP tool call.

The cancellation happens very quickly after the tool call starts — it's not a timeout, it's an early abort.

Environment

• codex-cli 0.118.0
• macOS (Apple Silicon)
• Node.js v22.22.0
• Multiple MCP servers tested (context-mode, minimal SDK example)

Full Session Report

Detailed investigation with exact commands, outputs, and chronology:
https://gist.github.com/murataslan1/e0290cb0862f57fff4a0e2936b6a77d8

[ctkm-aelf]

🤖 Structural solver proposal for exec MCP cancellation

TL;DR

• What this is: structural design proposal for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5, focused on why codex exec cancels MCP tool calls.
• Current state or conclusion: the cancellation belongs to codex-exec server-request handling, not to MCP transport; codex exec currently resolves every mcpServer/elicitation/request as Cancel.
• What the maintainer should do OR what the controller does next: the controller should compare this against the other solvers and prefer a bounded exec-side policy plus an exec integration test.

---

Structural recommendation

I traced the issue to the headless app-server bridge inside codex-exec. The app-server and MCP layers already support MCP elicitation round trips: codex-rs/app-server/tests/suite/v2/mcp_server_elicitation.rs exercises accepting an MCP elicitation, while codex-rs/codex-mcp/src/elicitation.rs already has policy-driven auto-accept/decline behavior for safe permission-confirm prompts.

The regression shape is in codex-rs/exec/src/lib.rs: the ServerRequest::McpServerElicitationRequest arm always resolves the request with McpServerElicitationAction::Cancel. That turns a normal MCP permission confirmation into a tool failure that surfaces as user cancelled MCP tool call.

Recommended plan: add a private ExecServerRequestPolicy in codex-rs/exec/src/server_request_policy.rs. This policy is the headless decision table for app-server ServerRequests. It should keep rejecting truly interactive requests such as request_user_input, command approvals, and dynamic tool calls, but should auto-resolve the same safe MCP permission-confirm elicitation class that the MCP manager already auto-accepts under full-auto. This removes the hard-coded cancellation from the exec event loop and makes the non-interactive boundary explicit.

Estimated change: about +180 / -35 LOC across 4 files. The required behavior test should live in codex-rs/exec/tests/suite/mcp_tool_call.rs and run codex exec --experimental-json --full-auto --skip-git-repo-check with the existing test_stdio_server, asserting that the JSONL stream has an MCP tool call completed event and does not contain user cancelled MCP tool call.

No protocol or governance changes are needed. The v2 mcpServer/elicitation/request method already exists, and the existing AGENTS rule already asks changes to keep MCP tool-call mutation localized and covered by integration tests.

---

📎 Full raw codex output (archival)

---
solver: structural
issue: 5
cluster: issue-5
verdict: propose
---

## PROJECT_RULES clause violated (quoted verbatim)
> When working with MCP tool calls, prefer using `codex-rs/codex-mcp/src/mcp_connection_manager.rs` to handle mutation of tools and tool calls. Aim to minimize the footprint of changes and leverage existing abstractions rather than plumbing code through multiple levels of function calls.

> For agent changes prefer integration tests over unit tests. Integration tests are under `core/suite` and use `test_codex` to set up a test instance of codex.

> Features that change the agent logic MUST add an integration test:

## Recommended framing
把问题定界为 `codex exec` 的非交互式 server-request policy 错位，而不是 MCP transport 或模型工具执行层失效。当前 `codex-rs/exec/src/lib.rs:1618` 对所有 `mcpServer/elicitation/request` 固定返回 `Cancel`，而 `codex-rs/codex-mcp/src/elicitation.rs:142` 已经能按 approval policy 自动接受无 schema 的确认类 elicitation，`codex-rs/app-server/tests/suite/v2/mcp_server_elicitation.rs:75` 也证明 app-server round trip 本身可用。结构性修复是在 `codex-exec` 内引入一个小的 `ExecServerRequestPolicy`，把“headless 不能弹交互 UI”和“MCP permission-confirm elicitation 可由 policy 自动解析”分开；exec 主循环只把 server request 交给 policy，不再在 match arm 里硬编码 MCP cancel。

## Concrete plan
- New abstractions (if any): `ExecServerRequestPolicy` in Layer: CLI/headless adapter, Project: `codex-exec`, File: `codex-rs/exec/src/server_request_policy.rs`. Interface: `async fn handle(&self, client: &InProcessAppServerClient, request: ServerRequest) -> Result<ServerRequestDisposition, String>`, where `ServerRequestDisposition` is an enum with `Resolved`, `Rejected`, and `UnhandledFatal`. This is justified by 9 concrete `ServerRequest` variants already handled in one function and by the explicit headless exec extension point.
- Files:
  - `codex-rs/exec/src/lib.rs`: replace `canceled_mcp_server_elicitation_response` and the large `handle_server_request` match with a call into `ExecServerRequestPolicy`; pass the resolved `Config` or the turn approval policy into the policy so MCP elicitation decisions are explicit.
  - `codex-rs/exec/src/server_request_policy.rs`: new private module owning the headless server-request decision table; keep rejection messages for command/file/dynamic/auth/attestation/apply-patch/exec-command/permissions approvals unchanged.
  - `codex-rs/exec/tests/suite/mcp_tool_call.rs`: new exec integration test module exercising a real MCP tool call under `codex exec --experimental-json --full-auto`.
  - `codex-rs/exec/tests/suite/mod.rs`: add `mod mcp_tool_call;`.
  - Optional only if the test needs a fixture helper: `codex-rs/core/tests/common/lib.rs` already exposes `stdio_server_bin()` at lines 405-407, so do not add a helper unless the exec crate cannot import it cleanly.
- LOC delta: ~+180 / -35. Estimated +95 LOC for `server_request_policy.rs`, +60 LOC for one exec integration test, +10 LOC module wiring/imports, -35 LOC from deleting the inline cancel helper and part of the match in `lib.rs`.
- Tests to add:
  - `codex-rs/exec/tests/suite/mcp_tool_call.rs::exec_mode_mcp_tool_call_completes`: configure `[mcp_servers.rmcp]` with `command = <test_stdio_server>` from `core_test_support::stdio_server_bin()`, mount a two-response SSE sequence where the first response calls `mcp__rmcp__echo`, run `codex exec --experimental-json --full-auto --skip-git-repo-check "call the rmcp echo tool"`, and assert JSONL contains an `item.started` MCP tool call followed by `item.completed` with `status:"completed"` and no `"user cancelled MCP tool call"`.
  - Unit tests for `ExecServerRequestPolicy` only if the implementation chooses data-only pure mapping helpers; otherwise skip unit tests and rely on the exec integration test plus existing app-server MCP elicitation coverage.
- Schema/protocol changes (if any): none. Existing v2 server request `mcpServer/elicitation/request` is already defined in `codex-rs/app-server-protocol/src/protocol/common.rs:1416` and response conversion exists in `codex-rs/app-server-protocol/src/protocol/v2/mcp.rs:679`.
- Governance/ruleset changes (if any): none. The current rules already require minimal MCP footprint and integration coverage; the plan follows them.
- Runtime cost: one extra Rust function call per app-server `ServerRequest`; no additional async channel hop. Allocations stay the same for rejects; MCP auto-accept adds one small `serde_json::Value` object for `{}` only when resolving an auto-accepted permission-confirm elicitation. Latency change is below 1 ms on the in-process path.
- If the structural answer is issue decomposition, use the controller-private `IssueDecompositionPlan` boundary and child body artifacts; forbid solver/judge/worker GitHub lifecycle, public issue factories, and any `wakeup_plan.py` decompose action/projection.

## Risks
- The structural split adds a file for logic that could be patched in place. Keep it bounded by moving only the server-request decision table, not the whole exec event loop.
- Auto-accepting the wrong MCP elicitation shape would be worse than cancellation. Reuse the existing `codex-mcp` semantics: accept only the same empty-schema permission-confirm class that `ElicitationRequestManager` already auto-accepts under full-auto; continue rejecting or declining arbitrary form fields and URL elicitations in headless exec.
- If `codex exec --full-auto` resolves to `AskForApproval::Never`, the policy must derive the effective “full-auto MCP permission confirmations are allowed” state from exec’s permission profile or config, not from a stale default. Verify with the test command shape from the issue.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — for meta-judge)
- Why this structure beats a documented exception: documenting that exec cancels MCP elicitation would preserve the user-visible regression. A policy object makes the headless boundary explicit and testable while letting MCP/app-server keep their existing responsibilities.
- Why I picked this abstraction over alternatives: changing `codex-mcp` globally would affect TUI and app-server clients that already handle elicitation correctly. Adding a protocol capability is unnecessary because app-server already emits `mcpServer/elicitation/request`; the defect is exec's response policy. A new `ExecServerRequestPolicy` has more than two concrete cases because every server request variant currently flows through the same match.
- What I cannot decide alone: whether non-empty form elicitations in exec should be declined, rejected as unsupported, or later exposed through a non-interactive CLI flag. That is outside issue #5 because the reported failure is immediate cancellation of ordinary MCP tool calls under `--full-auto`.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:structural:propose:factor codex-exec server request handling into a headless policy and auto-resolve safe MCP permission elicitations so exec MCP tool calls complete

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Delete-solver verdict: abstain on deleting MCP paths

TL;DR

• What this is: delete-solver pass for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5, focused on whether the failing codex exec MCP path should be removed or collapsed.
• Current state or conclusion: I found no safe deletion target; MCP tool execution and MCP elicitation/approval paths are live code, and the issue needs a headless exec policy fix plus coverage.
• What the maintainer should do OR what the controller does next: route this to the minimal/structural fix path rather than deleting MCP support or the app-server elicitation protocol.

---

Evidence and delete decision

I abstain from proposing deletion. codex exec is non-interactive, but MCP tool calls are still a required user-facing capability in this mode. The relevant failure shape appears to be that an MCP tool approval or elicitation request reaches a path that needs a user response, while exec mode deliberately rejects request_user_input and auto-cancels MCP server elicitation.

Important file references:

• codex-rs/codex-mcp/src/connection_manager.rs:672 matters because it is the actual MCP client call into the server via call_tool; deleting that would remove the capability the issue asks to restore.
• codex-rs/core/src/mcp_tool_call.rs:1281 matters because MCP tool approval can be routed through request_mcp_server_elicitation, the same class of request that exec currently auto-cancels.
• codex-rs/core/src/mcp_tool_call.rs:1302 matters because the fallback approval route calls request_user_input, which exec mode rejects as unsupported.
• codex-rs/core/src/mcp_tool_call.rs:2075 matters because missing or ambiguous MCP annotations default to approval-required, so ordinary MCP servers can hit this approval path.
• codex-rs/exec/src/lib.rs:1618 matters because exec mode auto-resolves MCP server elicitation with Cancel rather than surfacing a prompt.
• codex-rs/exec/src/lib.rs:1659 matters because exec mode rejects request_user_input, matching the report log line.

The delete-safe boundary is therefore: do not delete MCP execution, app-server MCP elicitation, or TUI/app-server interactive approval support. The likely implementation should make codex exec decide MCP tool approvals without interactive user input under the configured headless approval/sandbox policy, then add an exec-mode MCP tool-call test.

📎 Full raw codex output (archival)

---
solver: delete
issue: 5
cluster: issue-5
verdict: abstain
---

## Classification
e) Genuinely needed and right-sized enough that deletion/collapse is not justified for this issue.

## Recommended action
本轮 delete solver 应 abstain：MCP tool execution 本身是用户可见能力，`codex-rs/codex-mcp/src/connection_manager.rs:672` 直接调用 MCP client 的 `call_tool`，而 `codex exec` 下的取消现象来自 headless 模式遇到交互式审批/elicitation 路径时没有可用 UI，并不是存在一段无调用者或可整体删除的 MCP 代码。建议让 minimal/structural 方案修正 exec 下的非交互式 MCP approval 决策，并补一个 exec 模式 MCP tool call 集成测试；不要删除 MCP tool support、app-server elicitation protocol，或 TUI/app-server 的交互审批能力。

## Concrete plan (if propose)
- Files to delete: none
- Caller migrations: none
- Tests to delete: none
- LOC delta: 0
- Philosophy/CLAUDE.md/SPEC/Tier changes (if any): none

## Reverse-evidence (why this is safe to delete)
- No deletion is proposed. The relevant paths are not dead code:
  - `codex-rs/core/src/mcp_tool_call.rs:213` invokes `maybe_request_mcp_tool_approval` before dispatching an MCP call.
  - `codex-rs/core/src/mcp_tool_call.rs:1281` can route MCP tool approval through `request_mcp_server_elicitation`.
  - `codex-rs/core/src/mcp_tool_call.rs:1302` falls back to `request_user_input` when the MCP-elicitation feature is unavailable.
  - `codex-rs/core/src/mcp_tool_call.rs:2075` treats absent/ambiguous MCP annotations as approval-required by default, so ordinary MCP tools can reach the interactive approval path.
  - `codex-rs/exec/src/lib.rs:1618` auto-cancels MCP server elicitation in exec mode, and `codex-rs/exec/src/lib.rs:1659` rejects `request_user_input` in exec mode.
  - `codex-rs/codex-mcp/src/connection_manager.rs:672` is the load-bearing MCP client call into the server.
- Public API removal would be unsafe. `rg` found app-server protocol, TUI, app-server tests, core session tests, and MCP tool tests all using `McpServerElicitationRequest` / `McpServerElicitationRequestResponse`.
- The regression evidence points at a missing headless decision boundary, not at removable functionality. The issue acceptance criteria require MCP tool calls under `codex exec` to complete, which means deleting MCP execution would violate scope.
- The exec app-server bridge that rejects/cancels unsupported interactive requests was introduced by commit `da3689f0e` ("Add in-process app server and wire up exec to use it (#14005)") to support non-interactive exec through the app-server path.
- The MCP tool approval via MCP-style elicitation path was introduced by commit `98dca99db` ("[elicitations] Switch to use MCP style elicitation payload for mcp tool approvals. (#13621)") for interactive clients, not as dead code.

## Risks
- If the intended product decision is that `codex exec --full-auto` should bypass all MCP approval prompts, a small code deletion inside the approval routing branch may be possible, but that is a behavioral fix rather than a safe delete-solver conclusion.
- If some MCP server needs real server-side elicitation during `codex exec`, auto-cancel may still be the only safe headless response; deleting the cancel response risks hanging the process.
- If approval policy semantics have changed outside the inspected files, the exact minimal fix may belong in policy evaluation rather than in `codex-rs/exec/src/lib.rs`.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — for meta-judge)
- Why I claim this can be deleted: I do not claim deletion is justified. The feature is live and required by the issue acceptance criteria.
- What I checked to verify safety: searched the repo for `request_user_input`, MCP tool call dispatch, `McpServerElicitationRequest`, exec server-request handling, and `SessionSource::Exec`; read the exec request handler, MCP elicitation manager, MCP connection manager `call_tool`, and MCP approval routing; checked `git log -p -S` for the exec unsupported-input path and the `ToolCallMcpElicitation` path.
- What I cannot decide alone: the precise headless policy choice for MCP tool approvals in exec mode. That belongs to the minimal/structural fix, with a test that invokes an MCP tool under `codex exec`.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:delete:abstain:mcp-tool-execution-and-elicitation-approval-paths-are-load-bearing

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Minimal solver proposes a small exec/MCP approval fix

TL;DR

• What this is: Minimal-change design output for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5.
• Current state or conclusion: The failure is real in this checkout; codex exec cancels MCP tool approval prompts before the tool can run.
• What the maintainer should do OR what the controller does next: Prefer a core-side fast path for SessionSource::Exec + AskForApproval::Never, then add one exec regression test.

---

Minimal framing

The smallest viable fix is not in MCP transport startup. The local code shows codex exec resolves every McpServerElicitationRequest with Cancel and rejects ToolRequestUserInput with the exact reported request_user_input is not supported in exec mode path. Those requests are reached from Codex's own MCP tool approval prompt, not from the MCP server failing to initialize.

Recommended change: in codex-rs/core/src/mcp_tool_call.rs, before routing MCP tool approval to MCP elicitation or legacy request_user_input, treat SessionSource::Exec with AskForApproval::Never as no prompt required and continue the MCP tool call. This preserves exec's non-interactive behavior for arbitrary server-initiated forms while stopping Codex's own tool approval prompt from cancelling every MCP call.

Option	Files	Trade-off
Core fast path for exec/headless MCP tool approval	2-3 files, about +135 LOC with tests	Fixes both new elicitation and legacy user-input failure signatures without making exec synthesize arbitrary form answers.
Make exec auto-accept all MCP elicitations	1 file, smaller code diff	Too broad: answers server-requested forms without user input.
Change MCP transport/call manager	1-2 files	Misses the evidence: the cancellation happens after app-server permission requests reach exec.

📎 Full raw codex output (archival)

---

solver: minimal
issue: 5
cluster: issue-5
verdict: propose

Recommended framing

最小可行修复是在 MCP 工具调用的“是否需要 Codex 自己弹出工具审批”判断处处理 codex exec 的无交互语义，而不是改 MCP stdio/HTTP 传输或让 exec 自动回答任意 MCP server elicitation。当前证据显示，codex exec 已把 headless 默认 approval policy 设为 AskForApproval::Never，但 MCP 工具审批仍可能经由 McpServerElicitationRequest 或旧的 request_user_input 路径发到 exec；exec 随后分别返回 Cancel 或拒绝，导致工具调用快速失败。最小边界是在 codex-rs/core/src/mcp_tool_call.rs 中让 SessionSource::Exec + AskForApproval::Never 对 Codex 内部 MCP tool approval prompt 视为已批准，保留真正的 server-initiated elicitation 在 exec 中不可交互的取消/拒绝行为。

Concrete plan

• Files:
  • codex-rs/core/src/mcp_tool_call.rs: 在 maybe_request_mcp_tool_approval 开头、现有 mcp_permission_prompt_is_auto_approved(...) 判断附近增加 SessionSource::Exec && approval_policy == AskForApproval::Never 的 fast path，直接返回 None，表示不需要提示并继续调用 MCP 工具。不要改 McpConnectionManager::call_tool，不要改 MCP transport。
  • codex-rs/core/src/mcp_tool_call_tests.rs: 增加/调整一个窄单元测试，覆盖 exec source + AskForApproval::Never + 默认 AppToolApproval::Auto 时不会发出 RequestUserInput/ElicitationRequest 并允许调用继续；同时保留 AppToolApproval::Prompt 或 non-exec interactive surface 仍走现有提示路径的覆盖。
  • codex-rs/exec/tests/suite/mcp_tool_call.rs or existing codex-rs/exec/tests/suite/mcp_required_exit.rs: 新增 exec 回归集成测试，配置一个本仓库已有 stdio MCP test server，mock Responses API 发起一次 MCP function call，运行 codex exec --experimental-json --skip-git-repo-check ...，断言 JSONL 中 MCP tool call completed/status completed 或模型后续请求包含 successful function_call_output，且不包含 "user cancelled MCP tool call" / "request_user_input is not supported in exec mode"。
  • codex-rs/exec/tests/suite/mod.rs: 如果新增 mcp_tool_call.rs，注册测试模块。
• LOC delta: ~+45 / -0 for core guard and tests if reusing helpers; ~+90 / -0 if the exec integration test needs local helper glue for the stdio MCP test server. Total expected ~+135 / -0.
• Tests to add/modify:
  • codex-rs/core/src/mcp_tool_call_tests.rs: 1 focused unit/regression test for the approval decision boundary.
  • codex-rs/exec/tests/suite/mcp_tool_call.rs: 1 CLI integration test matching the issue’s codex exec behavior.
  • Run just fmt; run just test -p codex-core and just test -p codex-exec. Because codex-core is touched, ask before a full just test.
• Governance/ruleset change (if any): none. This plan follows the MCP guidance by keeping tool-call mutation in existing core/MCP abstractions and avoids adding to codex-core beyond the existing MCP tool-call owner file.
• Migration path: no migration needed; existing config continues to work. Users who explicitly configure approval_mode = "prompt" should still receive a non-interactive failure/cancel in exec unless a future product decision defines a headless prompt answer.

Risks

• This treats headless codex exec + approval_policy = "never" as approval for Codex’s MCP tool-use permission prompt. That matches exec’s existing non-interactive automation contract, but it means destructive MCP tools rely on server annotations/config and the user’s exec sandbox/permission choice rather than an extra prompt.
• If the real regression is only in ToolCallMcpElicitation routing, the fast path also fixes the legacy request_user_input compatibility path; that is intentional because the issue evidence contains both failure signatures.
• If a user explicitly sets MCP approval_mode = "prompt" in exec, the plan leaves that as unsupported/headless rather than inventing an answer. That keeps the change small but may still surprise users with prompt-only MCP config.

Escalation triggers (if any)

• none

Reasoning trace (internal — short, for meta-judge)

• Why this is the minimum: codex-rs/exec/src/lib.rs:1618-1634 resolves every McpServerElicitationRequest with Cancel, and codex-rs/exec/src/lib.rs:1659-1669 rejects ToolRequestUserInput with the exact reported log. codex-rs/core/src/mcp_tool_call.rs:1153-1161 already has an approval auto-approve gate before either prompt path, and codex-rs/core/src/mcp_tool_call.rs:1258-1306 shows the two prompt routes that cause exec cancellation. Adding one exec/headless fast path there avoids plumbing a new response protocol through exec/app-server/MCP.
• What I considered but rejected: making exec synthesize Accept for all MCP server elicitations at codex-rs/exec/src/lib.rs:1618; that would answer arbitrary server-requested forms without user input. Also rejected changing codex-rs/codex-mcp/src/mcp/mod.rs:71-90 globally because non-exec surfaces with AskForApproval::Never may still have different permission-profile semantics already encoded there.
• What I cannot decide alone: whether prompt-only MCP config should be a hard error during exec startup. That is outside the issue’s minimal acceptance criteria.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:minimal:propose:Handle codex exec headless MCP tool approval before it reaches non-interactive elicitation/user-input cancellation.

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Meta-judge requests convergence on exec MCP fix boundary

TL;DR

• What this is: Round 1 meta-judge arbitration for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5.
• Current state or conclusion: No consensus yet because the two implementation solvers chose different owner boundaries for the same regression.
• What the controller does next: Run convergence round 2 with a focused question comparing the codex-core pre-prompt bypass against the codex-exec safe elicitation policy.

---

Arbitration result

The delete solver is compatible-neutral here: MCP tool execution is required by the issue acceptance criteria, and the solver found no safe deletion target.

The implementation solvers agree on the symptom and test need, but not on the implementation boundary:

Option	Owner boundary	Main trade-off
Minimal proposal	codex-rs/core/src/mcp_tool_call.rs	Avoid emitting Codex-owned MCP tool approval prompts for SessionSource::Exec + AskForApproval::Never, but changes shared core behavior.
Structural proposal	codex-rs/exec/src/server_request_policy.rs	Keeps the headless decision in codex-exec, but may auto-answer a subset of app-server MCP elicitation requests.

The next round should answer one specific question: should issue #5 be fixed before app-server request emission in codex-core, or after emission in codex-exec? The solvers should explicitly address whether the failing request is always Codex's own MCP tool approval prompt or can include server-initiated MCP elicitation, and should name the smallest exec integration test that proves the accepted boundary.

📎 Full raw codex output (archival)

---
issue: 5
cluster: issue-5
convergence_round: 1
solver_verdicts:
  minimal: propose
  structural: propose
  delete: abstain
decision: converge
---

## Decision
本轮不能判定 consensus。delete solver 的 `abstain` 在 `manual-issue (prompt-only provenance)` + `gh-issue-5` 的 Path A 场景下可视为兼容中立，因为它确认 MCP tool execution 与 elicitation/approval path 都是 load-bearing，不能删除；但两个 implementation-bearing solver 没有就同一个 concrete plan 达成一致：minimal 方案把边界放在 `codex-rs/core/src/mcp_tool_call.rs` 的 `SessionSource::Exec + AskForApproval::Never` fast path，structural 方案把边界放在 `codex-rs/exec/src/server_request_policy.rs` 的 headless server-request policy，并让 exec auto-resolve safe MCP permission-confirm elicitation。这是不同文件、不同抽象、不同风险面的分歧，按 Step 3 必须进入 convergence round 2。

## If converge
- Convergence question (specific): Should issue #5 be fixed by bypassing Codex-owned MCP tool approval in `codex-core` for `SessionSource::Exec + AskForApproval::Never`, or by changing `codex-exec` server-request handling to auto-resolve only safe MCP permission-confirm elicitations; identify the single owner boundary, exact files, and why the other boundary is rejected.
- What each solver should address explicitly:
  - Whether the failing request is always Codex's own MCP tool approval prompt or can include server-initiated MCP elicitation under the issue reproduction.
  - Whether `codex exec --full-auto` semantics are best represented before app-server request emission in `codex-rs/core/src/mcp_tool_call.rs` or after emission in `codex-rs/exec/src/lib.rs`.
  - The security boundary for arbitrary MCP server elicitations in headless exec: auto-accept none, auto-accept only empty-schema permission-confirm prompts, or avoid emitting those prompts from core.
  - The smallest integration test that proves the accepted boundary: expected crate, file, command, MCP test server fixture, and JSONL/request assertion.
  - Why the rejected plan would either under-fix the issue, over-answer server forms, duplicate policy, or violate locality.
- Round number this fires: 2; marker payload uses source round `1`

## Round audit trail (links to local artifacts)
- solver-minimal: .refactor-loop/logs/phase9-issue5-r1-minimal.log
- solver-structural: .refactor-loop/logs/phase9-issue5-r1-structural.log
- solver-delete: .refactor-loop/logs/phase9-issue5-r1-delete.log
- work-unit-producer: manual-issue (prompt-only provenance)
- work-unit-source-ref: gh-issue-5

⟦AI:AUTO-LOOP⟧
META_JUDGE_DONE:converge:round-1:Choose the single owner boundary for exec MCP approval cancellation: core pre-prompt bypass or exec-side safe elicitation policy.

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Minimal solver proposes a narrow exec MCP approval fix

TL;DR

• What this is: Minimal-change design solver output for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5, where Model Context Protocol (MCP) tool calls fail under codex exec.
• Current state or conclusion: The likely regression is Codex's internal MCP tool approval path reaching exec's non-interactive elicitation or request_user_input handlers, which cancel or reject it before Session::call_tool runs.
• What the maintainer should do OR what the controller does next: Prefer a small core approval fast path plus one codex-exec integration test before considering broader MCP transport changes.

---

Minimal framing

The smallest viable boundary is to keep MCP transport and app-server request handling unchanged, and fix only Codex's internal tool-approval decision before it reaches exec's non-interactive request handlers. codex-rs/exec/src/lib.rs:406 matters because exec deliberately sets approval_policy to AskForApproval::Never for headless runs. codex-rs/core/src/mcp_tool_call.rs:1154 matters because this is the existing approval auto-approve gate before MCP tool prompts are sent. codex-rs/core/src/mcp_tool_call.rs:1258 and codex-rs/core/src/mcp_tool_call.rs:1301 matter because they are the two prompt paths that can become a cancelled MCP tool call in exec. codex-rs/exec/src/lib.rs:1618 and codex-rs/exec/src/lib.rs:1659 matter because exec auto-cancels MCP elicitation and rejects request_user_input, matching the issue's observed failure text.

Option	Trade-off
Add an exec/headless fast path in maybe_request_mcp_tool_approval	Smallest fix; preserves real server-initiated elicitation cancellation in exec.
Make exec auto-accept every MCP elicitation	Broader and riskier; would answer arbitrary server forms without user input.
Rewrite MCP connection or transport handling	Not justified by evidence; the failure occurs before the actual tool call path.

Recommended test coverage is one focused core test around the approval decision and one codex-exec CLI integration test with a local stdio MCP test server. The integration test should assert that an MCP tool call completes and that JSONL output does not contain user cancelled MCP tool call or request_user_input is not supported in exec mode.

---

📎 Full raw codex output (archival)

---
solver: minimal
issue: 5
cluster: issue-5
verdict: propose
---

## Recommended framing
最小可行修复是在 MCP 工具调用的“是否需要 Codex 自己弹出工具审批”判断处处理 `codex exec` 的无交互语义，而不是改 MCP stdio/HTTP 传输或让 exec 自动回答任意 MCP server elicitation。当前证据显示，`codex exec` 已把 headless 默认 approval policy 设为 `AskForApproval::Never`，但 MCP 工具审批仍可能经由 `McpServerElicitationRequest` 或旧的 `request_user_input` 路径发到 exec；exec 随后分别返回 `Cancel` 或拒绝，导致工具调用快速失败。最小边界是在 `codex-rs/core/src/mcp_tool_call.rs` 中让 `SessionSource::Exec + AskForApproval::Never` 对 Codex 内部 MCP tool approval prompt 视为已批准，保留真正的 server-initiated elicitation 在 exec 中不可交互的取消/拒绝行为。

## Concrete plan
- Files:
  - `codex-rs/core/src/mcp_tool_call.rs`: 在 `maybe_request_mcp_tool_approval` 开头、现有 `mcp_permission_prompt_is_auto_approved(...)` 判断附近增加 `SessionSource::Exec && approval_policy == AskForApproval::Never` 的 fast path，直接返回 `None`，表示不需要提示并继续调用 MCP 工具。不要改 `McpConnectionManager::call_tool`，不要改 MCP transport。
  - `codex-rs/core/src/mcp_tool_call_tests.rs`: 增加/调整一个窄单元测试，覆盖 exec source + `AskForApproval::Never` + 默认 `AppToolApproval::Auto` 时不会发出 `RequestUserInput`/`ElicitationRequest` 并允许调用继续；同时保留 `AppToolApproval::Prompt` 或 non-exec interactive surface 仍走现有提示路径的覆盖。
  - `codex-rs/exec/tests/suite/mcp_tool_call.rs` or existing `codex-rs/exec/tests/suite/mcp_required_exit.rs`: 新增 exec 回归集成测试，配置一个本仓库已有 stdio MCP test server，mock Responses API 发起一次 MCP function call，运行 `codex exec --experimental-json --skip-git-repo-check ...`，断言 JSONL 中 MCP tool call completed/status completed 或模型后续请求包含 successful function_call_output，且不包含 `"user cancelled MCP tool call"` / `"request_user_input is not supported in exec mode"`。
  - `codex-rs/exec/tests/suite/mod.rs`: 如果新增 `mcp_tool_call.rs`，注册测试模块。
- LOC delta: ~+45 / -0 for core guard and tests if reusing helpers; ~+90 / -0 if the exec integration test needs local helper glue for the stdio MCP test server. Total expected ~+135 / -0.
- Tests to add/modify:
  - `codex-rs/core/src/mcp_tool_call_tests.rs`: 1 focused unit/regression test for the approval decision boundary.
  - `codex-rs/exec/tests/suite/mcp_tool_call.rs`: 1 CLI integration test matching the issue’s `codex exec` behavior.
  - Run `just fmt`; run `just test -p codex-core` and `just test -p codex-exec`. Because `codex-core` is touched, ask before a full `just test`.
- Governance/ruleset change (if any): none. This plan follows the MCP guidance by keeping tool-call mutation in existing core/MCP abstractions and avoids adding to `codex-core` beyond the existing MCP tool-call owner file.
- Migration path: no migration needed; existing config continues to work. Users who explicitly configure `approval_mode = "prompt"` should still receive a non-interactive failure/cancel in exec unless a future product decision defines a headless prompt answer.

## Risks
- This treats headless `codex exec` + `approval_policy = "never"` as approval for Codex’s MCP tool-use permission prompt. That matches exec’s existing non-interactive automation contract, but it means destructive MCP tools rely on server annotations/config and the user’s exec sandbox/permission choice rather than an extra prompt.
- If the real regression is only in `ToolCallMcpElicitation` routing, the fast path also fixes the legacy `request_user_input` compatibility path; that is intentional because the issue evidence contains both failure signatures.
- If a user explicitly sets MCP `approval_mode = "prompt"` in exec, the plan leaves that as unsupported/headless rather than inventing an answer. That keeps the change small but may still surprise users with prompt-only MCP config.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — short, for meta-judge)
- Why this is the minimum: `codex-rs/exec/src/lib.rs:1618-1634` resolves every `McpServerElicitationRequest` with `Cancel`, and `codex-rs/exec/src/lib.rs:1659-1669` rejects `ToolRequestUserInput` with the exact reported log. `codex-rs/core/src/mcp_tool_call.rs:1153-1161` already has an approval auto-approve gate before either prompt path, and `codex-rs/core/src/mcp_tool_call.rs:1258-1306` shows the two prompt routes that cause exec cancellation. Adding one exec/headless fast path there avoids plumbing a new response protocol through exec/app-server/MCP.
- What I considered but rejected: making exec synthesize `Accept` for all MCP server elicitations at `codex-rs/exec/src/lib.rs:1618`; that would answer arbitrary server-requested forms without user input. Also rejected changing `codex-rs/codex-mcp/src/mcp/mod.rs:71-90` globally because non-exec surfaces with `AskForApproval::Never` may still have different permission-profile semantics already encoded there.
- What I cannot decide alone: whether prompt-only MCP config should be a hard error during exec startup. That is outside the issue’s minimal acceptance criteria.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:minimal:propose:Handle codex exec headless MCP tool approval before it reaches non-interactive elicitation/user-input cancellation.

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Minimal solver keeps the exec MCP fix before prompt emission

TL;DR

• What this is: Round 2 minimal-change solver output for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5, focused on Model Context Protocol (MCP) tool calls in codex exec.
• Current state or conclusion: The smallest safe boundary is to stop Codex's own MCP tool approval prompt before it reaches exec's non-interactive cancellation path.
• What the controller does next: Compare this against the exec-side policy option and prefer the core pre-prompt bypass if consensus wants the narrowest fix.

---

Minimal recommendation

I verified the current checkout has the reported failure shape. codex-rs/exec/src/lib.rs:406 sets headless exec approval policy to AskForApproval::Never, and codex-rs/exec/src/lib.rs:547 marks the session as SessionSource::Exec; these two facts define the non-interactive execution mode. codex-rs/core/src/mcp_tool_call.rs:1144 is the MCP tool approval decision point before the tool call is dispatched. If that decision emits a prompt, codex-rs/core/src/mcp_tool_call.rs:1281 can route it through mcpServer/elicitation/request, while codex-rs/core/src/mcp_tool_call.rs:1301 can route it through legacy request_user_input.

Exec then handles those requests headlessly: codex-rs/exec/src/lib.rs:1618 resolves every MCP server elicitation as Cancel, and codex-rs/exec/src/lib.rs:1659 rejects request_user_input with the same unsupported-in-exec wording described in the issue. That points to Codex's own MCP approval prompt being cancelled before the MCP server's call_tool path can run.

Option	Owner boundary	Trade-off
Core pre-prompt bypass	codex-rs/core/src/mcp_tool_call.rs	Smallest fix: for SessionSource::Exec + AskForApproval::Never, do not emit Codex-owned MCP tool approval prompts, while preserving exec cancellation for arbitrary server-originated elicitations.
Exec-side safe elicitation policy	codex-rs/exec/src/lib.rs or a new exec policy module	Broader: must distinguish Codex-owned permission confirms from server-originated forms after emission, and risks answering more than the issue requires.
MCP transport/connection change	codex-rs/codex-mcp	Not supported by the evidence because the cancellation happens in approval/request handling before transport failure is implicated.

Recommended implementation: add a narrow guard near the existing mcp_permission_prompt_is_auto_approved(...) check in maybe_request_mcp_tool_approval. When the session source is exec, approval policy is AskForApproval::Never, and the MCP tool was not explicitly configured with approval_mode = "prompt", return None so the call proceeds without a prompt. Keep codex-rs/exec/src/lib.rs:1618 unchanged for true server-initiated MCP elicitations.

Recommended coverage is one focused core test for the approval decision plus one codex-exec integration test using the existing stdio MCP test server. The exec test should run codex exec --experimental-json --full-auto --skip-git-repo-check, have the mocked Responses API request an MCP tool call such as mcp__rmcp.echo, and assert the JSONL/request flow contains a successful MCP result without user cancelled MCP tool call or request_user_input is not supported in exec mode.

📎 Full raw codex output (archival)

---
solver: minimal
issue: 5
cluster: issue-5
verdict: propose
---

## Recommended framing
最小可行边界仍然是 `codex-core` 的 MCP tool approval 预提示判断，而不是 `codex-exec` 的 server-request handler。当前 checkout 可验证：`codex exec` 在配置层把 headless approval policy 设为 `AskForApproval::Never` 并标记 `SessionSource::Exec`；`maybe_request_mcp_tool_approval` 先决定是否要发 Codex 自己的 MCP 工具审批提示，随后才走 `mcpServer/elicitation/request` 或旧 `request_user_input`；exec 对前者固定返回 `Cancel`、对后者固定 reject，正好产生 issue 里的 `user cancelled MCP tool call` 和日志文本。因此最小修复是在 core 里让 `SessionSource::Exec + AskForApproval::Never` 对 Codex 自己的 MCP tool approval prompt 直接视为无需提示并继续调用工具，保留 exec 对真正 server-initiated elicitation 和任意 user-input request 的非交互取消/拒绝语义。

## Concrete plan
- Files:
  - `codex-rs/core/src/mcp_tool_call.rs`: 在 `maybe_request_mcp_tool_approval` 现有 `mcp_permission_prompt_is_auto_approved(...)` gate 附近加入一个窄条件：当 `turn_context.session_source == SessionSource::Exec` 且 `turn_context.approval_policy.value() == AskForApproval::Never`，并且 MCP 工具的 `approval_mode` 不是显式 `AppToolApproval::Prompt` 时，返回 `None`，表示 Codex 自己的 MCP tool approval prompt 不应在 headless exec 中发出。若字段访问名不同，使用现有 `TurnContext`/`Config` accessor，不新增跨层参数。不要改 MCP transport、`McpConnectionManager::call_tool`、或 exec 的 generic server-request cancellation behavior。
  - `codex-rs/core/src/mcp_tool_call_tests.rs`: 增加 1 个 focused test，构造 exec session source + `AskForApproval::Never` + 默认/auto MCP tool approval，断言 `maybe_request_mcp_tool_approval` 返回 `None`，且不会触发 `request_mcp_server_elicitation` 或 `request_user_input`。同文件已有 MCP approval helpers 和 `pretty_assertions::assert_eq`，复用即可；不要为静态常量写测试。
  - `codex-rs/exec/tests/suite/mcp_tool_call.rs`: 增加 1 个 CLI integration regression test，使用 `core_test_support::test_codex_exec::test_codex_exec`、`core_test_support::stdio_server_bin` 和 `responses::ev_function_call_with_namespace` 配置本地 stdio MCP test server。运行 `codex exec --experimental-json --full-auto --skip-git-repo-check "call the rmcp echo tool"`，mock Responses API 先发 `mcp__rmcp.echo` tool call，再发最终 assistant message；断言 stdout JSONL 包含 MCP tool call completed/success or 后续 request body 有 successful `function_call_output`，并断言 stdout/stderr/request bodies 不包含 `user cancelled MCP tool call` 和 `request_user_input is not supported in exec mode`。
  - `codex-rs/exec/tests/suite/mod.rs`: 如果新增 `mcp_tool_call.rs`，注册模块。
- LOC delta: ~+70 / -0 for the core guard and unit coverage; ~+95 / -0 for the exec integration test and module registration; total ~+165 / -0.
- Tests to add/modify:
  - `codex-rs/core/src/mcp_tool_call_tests.rs`: 1 focused approval-boundary test.
  - `codex-rs/exec/tests/suite/mcp_tool_call.rs`: 1 exec CLI integration test covering an actual MCP tool call.
  - Run `just fmt` in `codex-rs`, then `just fix -p codex-core` and `just fix -p codex-exec` before finalizing a large-enough implementation change. Run `just test -p codex-core` and `just test -p codex-exec`. Because this touches `codex-core`, ask before running full `just test`.
- Governance/ruleset change (if any): none.
- Migration path: no migration needed; this only changes the headless approval decision for Codex-owned MCP tool approval prompts in exec mode.

## Risks
- This intentionally does not make `codex exec` answer arbitrary MCP server elicitations; servers that initiate their own forms during a tool call can still be cancelled in exec mode.
- A too-broad guard would ignore explicit per-tool `approval_mode = "prompt"`; keep `Prompt` as the opt-in interactive policy and either fail clearly in exec or document that it is unsupported in headless mode.
- If `codex exec` can run with `AskForApproval::Never` but a permission profile that is not full-auto, the guard must be tied to the same full-auto semantics as existing approval policy resolution, not merely the string value of `--full-auto`.
- The unit test alone is insufficient because the issue is a CLI/app-server bridge regression; the exec integration test is required by the acceptance criteria.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — short, for meta-judge)
- Why this is the minimum: the failing request is produced by Codex's own MCP tool approval path before MCP `call_tool`; preventing that prompt in the already-headless `Exec + Never` case fixes both current failure signatures without adding a new exec policy abstraction.
- What I considered but rejected: exec-side safe elicitation auto-accept is more general but also answers app-server MCP elicitations after emission, including requests that may originate from the MCP server rather than Codex's approval prompt. Transport or connection-manager changes miss the verified cancellation points.
- What I cannot decide alone: whether maintainers want a later broader headless policy for server-initiated MCP elicitations; that is outside the minimal issue #5 fix.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:minimal:propose:Fix exec MCP cancellation by bypassing Codex-owned MCP tool approval prompts in core for headless Exec+Never and add exec MCP regression coverage.

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Structural solver selects the core MCP approval boundary

TL;DR

• What this is: Round 2 structural design output for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5, focused on the codex exec MCP cancellation regression.
• Current state or conclusion: Fix before app-server request emission in codex-core, because the failing request is Codex's own MCP tool approval prompt under headless AskForApproval::Never.
• What the controller does next: Compare this with the minimal solver and prefer a core-side approval-policy predicate plus one codex-exec integration test.

---

Structural recommendation

I pick the core pre-prompt boundary over an exec-side safe elicitation policy.

codex-rs/exec/src/lib.rs:406 matters because exec mode already resolves headless runs to AskForApproval::Never. codex-rs/core/src/mcp_tool_call.rs:1144 matters because maybe_request_mcp_tool_approval is where Codex decides whether its own MCP tool approval prompt is needed before calling the MCP server. codex-rs/core/src/mcp_tool_call.rs:1258 and codex-rs/core/src/mcp_tool_call.rs:1301 matter because those are the two prompt routes that can reach exec as app-server elicitation or legacy user input. codex-rs/exec/src/lib.rs:1618 and codex-rs/exec/src/lib.rs:1659 matter because exec cancels MCP elicitation and rejects request_user_input, matching the reported failure strings.

Option	Owner boundary	Trade-off
Core pre-prompt policy	codex-rs/core/src/mcp_tool_call.rs	Prevents Codex-owned MCP approval prompts from being emitted under full-auto exec; preserves exec cancellation for arbitrary server-initiated forms.
Exec-side safe elicitation policy	codex-rs/exec/src/lib.rs or a new helper	Keeps policy in the headless adapter, but risks auto-answering serialized MCP forms after the system has lost the strongest distinction between Codex-owned approval and server-owned elicitation.

The plan is to add a private approval predicate around the existing mcp_permission_prompt_is_auto_approved call, cover it in codex-rs/core/src/mcp_tool_call_tests.rs, and add codex-rs/exec/tests/suite/mcp_tool_call.rs using the existing test_stdio_server fixture. The integration test should assert an MCP tool call reaches JSONL status completed and does not contain user cancelled MCP tool call or request_user_input is not supported in exec mode.

No app-server protocol changes are needed. No GitHub lifecycle action is proposed.

---

📎 Full raw codex output (archival)

---
solver: structural
issue: 5
cluster: issue-5
verdict: propose
---

## PROJECT_RULES clause violated (quoted verbatim)
> When working with MCP tool calls, prefer using `codex-rs/codex-mcp/src/mcp_connection_manager.rs` to handle mutation of tools and tool calls. Aim to minimize the footprint of changes and leverage existing abstractions rather than plumbing code through multiple levels of function calls.

> Features that change the agent logic MUST add an integration test:

> Resist adding code to codex-core!

## Recommended framing
结构性边界应放在 `codex-core` 的 Codex-owned MCP tool approval 决策点，而不是 `codex-exec` 的 app-server request handler：`codex exec` 已在 `codex-rs/exec/src/lib.rs:406` 把 headless 默认审批策略设为 `AskForApproval::Never`，但 `codex-rs/core/src/mcp_tool_call.rs:1144` 的 `maybe_request_mcp_tool_approval` 仍可能为普通 MCP tool call 生成 Codex 自己的 approval prompt，并经 `request_mcp_server_elicitation` 或 `request_user_input` 到达 exec；exec 在 `codex-rs/exec/src/lib.rs:1618` 取消所有 MCP elicitation，在 `codex-rs/exec/src/lib.rs:1659` 拒绝 user-input，于是出现 `user cancelled MCP tool call`。清洁修复是把“headless never-ask means no Codex-owned MCP approval prompt”写成一个小的 core-side predicate，复用现有 `mcp_permission_prompt_is_auto_approved` policy gate，让 exec 继续拒绝真正的 server-initiated forms，而不是教 exec 自动回答一类表单。

## Concrete plan
- New abstractions (if any): `mcp_tool_approval_is_satisfied_by_policy(...) -> bool`, private helper in Layer: core MCP tool approval policy, Project: `codex-core`, File: `codex-rs/core/src/mcp_tool_call.rs`. It is justified as an explicit named decision point used by production approval flow and unit coverage; do not introduce an exec-side `ServerRequestPolicy` yet because there is only one affected caller and it would answer already-emitted app-server requests rather than preventing the wrong request from being emitted.
- Files:
  - `codex-rs/core/src/mcp_tool_call.rs`: refactor the existing auto-approve check around `maybe_request_mcp_tool_approval` into `mcp_tool_approval_is_satisfied_by_policy`. The helper should return true when `mcp_permission_prompt_is_auto_approved(turn_context.approval_policy.value(), &turn_context.permission_profile(), McpPermissionPromptAutoApproveContext { tool_approval_mode: Some(approval_mode) })` is true. This reuses the existing `codex-mcp` policy contract and covers `SessionSource::Exec + AskForApproval::Never` without special-casing exec if the resolved permission profile is full-auto-compatible. It should still run permission hooks only after policy says a prompt is needed, matching today's ordering.
  - `codex-rs/core/src/mcp_tool_call_tests.rs`: add focused tests for the helper or the surrounding decision: `AskForApproval::Never` plus a permissive/full-auto permission profile skips Codex-owned MCP approval for default/ambiguous annotations; `AskForApproval::OnRequest` or a non-full-auto managed profile still prompts when approval is required. Use whole-object equality where practical.
  - `codex-rs/exec/tests/suite/mcp_tool_call.rs`: add a CLI integration test using `core_test_support::test_codex_exec::test_codex_exec`, `core_test_support::stdio_server_bin`, and the existing `rmcp-client` `test_stdio_server` binary. Configure `[mcp_servers.test] command = "<test_stdio_server>"`, mock the Responses API with `ev_function_call_with_namespace` for a real MCP tool, run `codex exec --experimental-json --full-auto --skip-git-repo-check "call the MCP tool"`, and assert stdout JSONL contains an `mcp_tool_call` completed item while stderr/stdout do not contain `user cancelled MCP tool call` or `request_user_input is not supported in exec mode`.
  - `codex-rs/exec/tests/suite/mod.rs`: register `mod mcp_tool_call;`.
  - Do not change `codex-rs/exec/src/lib.rs` cancellation behavior for `ServerRequest::McpServerElicitationRequest`; that cancellation remains the correct headless boundary for arbitrary server-initiated MCP elicitations.
- LOC delta: ~+95 / -5 total. Core helper and tests ~+45 / -5; exec integration test and module registration ~+50 / -0.
- Tests to add:
  - 2 focused `codex-core` unit tests in `codex-rs/core/src/mcp_tool_call_tests.rs` proving the approval decision boundary.
  - 1 `codex-exec` integration test in `codex-rs/exec/tests/suite/mcp_tool_call.rs` proving an MCP tool call completes under exec JSON/full-auto mode and does not emit the two known cancellation strings.
  - Validation commands after implementation: `just fmt`; `just fix -p codex-core` and `just fix -p codex-exec` if both crates are touched; `just test -p codex-core`; `just test -p codex-exec`; ask before full `just test` because core changed.
- Schema/protocol changes (if any): none. No app-server v2 method or payload changes; `mcpServer/elicitation/request` remains unchanged.
- Governance/ruleset changes (if any): none. The plan adds a small amount of code to `codex-core`, but it is in the existing owner of the MCP tool approval decision and avoids adding a new app-server protocol adapter.
- Runtime cost: steady-state latency decreases by one app-server request/response round trip for exec MCP approval prompts. The new helper adds 0 async hops and 0 heap allocations beyond existing permission-profile access; expected CPU cost is one enum/predicate match already present today. The exec integration test adds no runtime cost outside tests.
- If the structural answer is issue decomposition, use the controller-private `IssueDecompositionPlan` boundary and child body artifacts; forbid solver/judge/worker GitHub lifecycle, public issue factories, and any `wakeup_plan.py` decompose action/projection.

## Risks
- This trades off the broader structural appeal of an exec-owned server-request policy for locality at the actual approval decision. The exec-side policy would be attractive if exec had two or more safe auto-resolution cases, but today it would mostly wrap one `match` arm and risk blessing already-emitted server forms.
- The main risk is under-fixing if the reproduction is caused by a genuine server-initiated MCP elicitation rather than Codex's internal MCP tool approval. The issue evidence points to ordinary tool calls failing immediately and the core approval path explains both observed strings, so the integration test must use a plain MCP tool call with default/ambiguous annotations. If that test still fails after the core predicate, then a second, separate issue should define explicit headless semantics for server-initiated MCP elicitations.
- Avoid over-engineering by not adding a public trait, actor hop, or `ExecServerRequestPolicy` file in this patch. A private helper plus integration coverage is the smallest structural seam that prevents the invalid request by construction.

## Escalation triggers (if any)
- none

## Reasoning trace (internal — for meta-judge)
- Why this structure beats a documented exception: It encodes the headless/full-auto approval policy where MCP tool approval is decided, so exec never receives an approval prompt it cannot satisfy. A comment in exec would preserve the cancellation symptom rather than removing the invalid request path.
- Why I picked this abstraction over alternatives: `mcp_permission_prompt_is_auto_approved` already exists in `codex-mcp` and is used by both core MCP skill dependency logic and MCP elicitation handling. Reusing it avoids a second policy table and respects the AGENTS instruction to leverage existing MCP abstractions. An exec-side `ServerRequestPolicy` has only one concrete auto-resolution caller and would have to distinguish Codex-owned permission prompts from arbitrary server forms after serialization.
- What I cannot decide alone: Whether `codex exec` should ever auto-answer server-initiated MCP form elicitations with empty schemas. That is a separate product/security boundary and should not be silently included in this regression fix.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:structural:propose:fix before app-server request emission in core MCP tool approval policy; keep exec cancelling arbitrary MCP elicitations

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Delete solver abstains on exec MCP cancellation

TL;DR

• What this is: Round 2 delete-solver output for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5, focused on whether any MCP or exec request path should be removed.
• Current state or conclusion: No deletion is safe; MCP tool execution is required, and exec's generic elicitation cancellation is a live non-interactive boundary rather than dead code.
• What the controller does next: Compare implementation proposals on the owner boundary: core pre-prompt approval bypass versus a narrowly scoped exec-side policy.

---

Delete-solver result

I do not recommend deleting MCP execution, the app-server MCP elicitation protocol, or exec's generic rejection/cancel handling. The useful boundary is narrower: codex exec should stop cancelling Codex-owned MCP tool approval prompts before a normal MCP call_tool can run, while arbitrary server-initiated forms should remain non-interactive unless a safe policy is explicitly defined.

Option	Delete-solver stance	Trade-off
Delete MCP tool execution	Reject	Removes the user-facing capability the issue asks to restore.
Delete app-server MCP elicitation handling	Reject	Breaks live interactive surfaces and server-request plumbing.
Delete exec's generic non-interactive cancel/reject behavior	Reject	Risks answering arbitrary MCP/server prompts in headless mode.
Fix Codex-owned MCP approval before or inside exec policy	Compatible	Restores the reported behavior without deleting load-bearing paths.

Relevant evidence: codex-rs/codex-mcp/src/connection_manager.rs:672 is the actual MCP server call_tool invocation, so deleting it would remove the feature. codex-rs/core/src/mcp_tool_call.rs:213 invokes approval before tool execution, and codex-rs/core/src/mcp_tool_call.rs:1281 plus codex-rs/core/src/mcp_tool_call.rs:1302 show the two prompt routes that can reach exec. codex-rs/exec/src/lib.rs:1618 cancels MCP elicitation, and codex-rs/exec/src/lib.rs:1659 rejects request_user_input, matching the reported failure text.

📎 Full raw codex output (archival)

---

solver: delete
issue: 5
cluster: issue-5
verdict: abstain

Classification

e) Genuinely needed and right-sized enough for this issue; no deletion/collapse is justified.

Recommended action

本轮 delete solver 继续 abstain：codex exec 下 MCP tool call 是 issue acceptance criteria 明确要求恢复的能力，不能删除；codex-rs/exec/src/lib.rs 中对任意 mcpServer/elicitation/request 的 headless cancel 也不是可直接删除的废代码，因为它承载了非交互 exec 不回答任意 server form 的安全边界。最小可接受方向应由 implementation solver 处理 Codex 自己的 MCP tool approval prompt，而不是删除 MCP execution、app-server elicitation protocol、或 exec 的所有非交互拒绝逻辑。

Concrete plan (if propose)

• Files to delete: none
• Caller migrations: none
• Tests to delete: none
• LOC delta: 0
• Philosophy/CLAUDE.md/SPEC/Tier changes (if any): none
• If deletion is unsafe because the issue is merely too large, you may propose a bounded IssueDecompositionPlan artifact path instead of deletion; do not propose direct GitHub lifecycle calls, public issue factories, or any wakeup_plan.py decompose action/projection.

Reverse-evidence (why this is safe to delete)

• No deletion is proposed. codex-rs/codex-mcp/src/connection_manager.rs:658 exposes the live MCP call_tool entry point, and codex-rs/codex-mcp/src/connection_manager.rs:672 invokes the server tool. Deleting that path would remove the capability issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5 asks to restore.
• codex-rs/core/src/mcp_tool_call.rs:213 calls maybe_request_mcp_tool_approval before continuing to the approved MCP tool call path. This makes the failing path part of live tool execution, not dead code.
• codex-rs/core/src/mcp_tool_call.rs:1154 already has an auto-approval gate based on AskForApproval::Never and the permission profile. That is an existing simplification point; it argues against creating a deletion plan for MCP transport or app-server protocol.
• codex-rs/core/src/mcp_tool_call.rs:1258 through codex-rs/core/src/mcp_tool_call.rs:1281 can route Codex-owned MCP tool approval through app-server MCP elicitation. codex-rs/core/src/mcp_tool_call.rs:1298 through codex-rs/core/src/mcp_tool_call.rs:1302 can fall back to request_user_input. These are the two live routes that can reach exec's non-interactive handlers.
• codex-rs/core/src/mcp_tool_call.rs:2075 through codex-rs/core/src/mcp_tool_call.rs:2092 treats missing or ambiguous annotations as approval-required, so ordinary MCP servers can enter the approval path. This matches the issue report's broad reproduction across servers.
• codex-rs/exec/src/lib.rs:406 through codex-rs/exec/src/lib.rs:411 defaults exec to AskForApproval::Never, which is a real headless policy signal. Removing exec's request handling would not apply that signal; the fix should align MCP approval with it.
• codex-rs/exec/src/lib.rs:1618 through codex-rs/exec/src/lib.rs:1633 auto-resolves MCP elicitation with Cancel, and codex-rs/exec/src/lib.rs:1659 through codex-rs/exec/src/lib.rs:1666 rejects request_user_input with the exact unsupported-exec-mode message cited by the issue. These lines explain the bug, but they are also the non-interactive boundary for arbitrary server requests.
• codex-rs/exec/src/lib_tests.rs:393 through codex-rs/exec/src/lib_tests.rs:407 currently asserts the cancel response shape. That test is load-bearing for the current headless behavior; it may need adjustment if an exec-side policy is chosen, but it is not evidence that the path can be deleted wholesale.
• git log -p --follow -S 'McpServerElicitationRequest' -- codex-rs/exec/src/lib.rs traces the exec cancel behavior to da3689f0ef7422c3857e1156d4b78d3482cc26d6 ("Add in-process app server and wire up exec to use it"). The intent was bridging exec through app-server while preserving non-interactive behavior, not introducing dead code.

Risks

• If every mcpServer/elicitation/request reaching exec in this issue is proven to be Codex's internal MCP tool approval prompt, a core-side pre-prompt bypass is the smaller fix; delete still abstains because this is a behavior correction, not deletion.
• If MCP servers can initiate their own elicitation during a tool call after Codex's approval prompt is bypassed, those server-initiated forms should still be cancelled or rejected in exec unless a very narrow safe auto-accept policy is specified. Auto-accepting arbitrary forms would be a security regression.
• If the app-server protocol has a distinguishable marker for Codex-owned MCP tool approval versus server-initiated elicitation, an exec-side narrow policy may be viable. That still does not justify deleting the protocol or MCP execution path.

Escalation triggers (if any)

• none

Reasoning trace (internal — for meta-judge)

• Why I claim this can be deleted: I do not claim any code can be safely deleted. The path is live and user-facing.
• What I checked to verify safety: I traced the live MCP execution path from handle_mcp_tool_call through maybe_request_mcp_tool_approval, the app-server elicitation and request_user_input branches, exec's request resolver, the MCP connection manager call_tool, existing tests, and the git log -S history for McpServerElicitationRequest.
• What I cannot decide alone: Whether the final implementation boundary should be a core pre-prompt bypass for SessionSource::Exec + AskForApproval::Never or an exec-side policy that accepts only a recognizable Codex-owned/safe MCP approval elicitation. Delete solver can only say that deleting MCP support or generic exec non-interactive handling is the wrong answer.

⟦AI:AUTO-LOOP⟧
SOLVER_DONE:delete:abstain:MCP exec tool execution and non-interactive request handling are live; no deletion/collapse target is safe for issue #5.

⟦AI:AUTO-LOOP⟧

[ctkm-aelf]

🤖 Meta-judge reaches consensus on exec MCP fix boundary

TL;DR

• What this is: Round 2 meta-judge arbitration for issue MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call' #5, where Model Context Protocol (MCP) tool calls fail under codex exec.
• Current state or conclusion: Consensus is reached on a core-side MCP approval pre-prompt fix plus exec-mode regression coverage.
• What the controller does next: Dispatch implementation from this judge decision and add crnd:triage:resume-requested to issue 5.

---

Consensus decision

The two implementation-bearing solvers now agree on the owner boundary: fix this before app-server request emission in codex-rs/core/src/mcp_tool_call.rs. In practical terms, Codex-owned MCP tool approval should be satisfied by the existing approval/permission policy before it emits an app-server MCP elicitation or legacy request_user_input request. That prevents codex exec --full-auto from cancelling its own MCP approval prompt before the actual MCP server call_tool path runs.

The delete solver abstain is compatible here because this is an issue-driven work unit and its reverse-evidence shows there is no safe deletion target: MCP execution is required by the acceptance criteria, app-server MCP elicitation remains live for interactive surfaces, and exec's generic headless cancel/reject behavior still protects against arbitrary server-initiated forms.

Option	Decision	Trade-off
Core pre-prompt MCP approval policy	Chosen	Prevents Codex-owned MCP approval prompts from reaching exec's non-interactive cancellation path.
Exec-side safe elicitation policy	Rejected for this issue	Would have to distinguish Codex-owned prompts from arbitrary server forms after emission.
MCP transport or deletion changes	Rejected	The failure is explained before transport execution, and deleting MCP paths removes required behavior.

Implementation scope is limited to codex-rs/core/src/mcp_tool_call.rs, focused core tests, and one codex-exec integration test such as codex-rs/exec/tests/suite/mcp_tool_call.rs registered from mod.rs. The test should prove a codex exec --experimental-json --full-auto --skip-git-repo-check MCP tool call completes and does not emit user cancelled MCP tool call or request_user_input is not supported in exec mode.

📎 Full raw codex output (archival)

---
issue: 5
cluster: issue-5
convergence_round: 2
solver_verdicts:
  minimal: propose
  structural: propose
  delete: abstain
decision: consensus
---

## Decision
本轮达成 consensus：minimal 和 structural 在 round 2 都选择把修复边界放在 `codex-rs/core/src/mcp_tool_call.rs` 的 Codex-owned MCP tool approval 预提示决策点，而不是改 MCP transport 或让 `codex-exec` 自动回答已发出的任意 `mcpServer/elicitation/request`；delete solver 的 `abstain` 与该方向兼容，因为 issue #5 是 `manual-issue (prompt-only provenance)` / `gh-issue-5` 的 issue-driven Path A，且 delete reverse-evidence 证明 MCP execution、app-server elicitation protocol、exec 的 generic headless cancel/reject path 都是 live code，没有安全删除目标。采纳 structural framing 的原因是它在相同核心边界上给出了更精确的私有 predicate 形状，并保留 exec 对 arbitrary server-initiated MCP elicitations 的非交互取消语义。

## If consensus
- Chosen framing: structural
- Implement plan (structured fields read by wakeup-plan from this judge artifact only, not from solver artifacts or prompt-body free text):
  - scope_paths:
    codex-rs/core/src/mcp_tool_call.rs
    codex-rs/core/src/mcp_tool_call_tests.rs
    codex-rs/exec/tests/suite/mcp_tool_call.rs
    codex-rs/exec/tests/suite/mod.rs
  - old_pattern: `codex exec --full-auto` resolves headless mode to `AskForApproval::Never`, but Codex-owned MCP tool approval can still emit an app-server MCP elicitation or legacy `request_user_input`; exec then cancels/rejects that request and the MCP tool call fails before `call_tool` runs.
  - new_principle: MCP tool approval should be satisfied by the existing approval/permission policy before app-server prompt emission; for headless full-auto exec, ordinary Codex-owned MCP tool approval prompts must not be emitted, while `codex-exec` must continue cancelling arbitrary server-initiated MCP elicitations unless a separate explicit policy is designed.
  - verification_hints: Run `just fmt` in `codex-rs`; run scoped fixes for touched crates such as `just fix -p codex-core` and `just fix -p codex-exec`; run `just test -p codex-core` and `just test -p codex-exec`; ask before full `just test` because `codex-core` is touched.
- Philosophy/CLAUDE.md/SPEC/Tier changes included: none
- Implementation owner: dispatch implement codex with cluster_id=issue-5, design_decision_path=.refactor-loop/runs/phase9-issue5-r2-judge.md
- Add `crnd:triage:resume-requested` label to issue 5

## If converge
- Convergence question (specific): n/a
- What each solver should address explicitly: n/a
- Round number this fires: n/a

## Round audit trail (links to local artifacts)
- solver-minimal: .refactor-loop/logs/phase9-issue5-r2-minimal.log
- solver-structural: .refactor-loop/logs/phase9-issue5-r2-structural.log
- solver-delete: .refactor-loop/logs/phase9-issue5-r2-delete.log
- work-unit-producer: manual-issue (prompt-only provenance)
- work-unit-source-ref: gh-issue-5

⟦AI:AUTO-LOOP⟧
META_JUDGE_DONE:consensus:structural:core MCP approval pre-prompt fix with exec MCP regression coverage

⟦AI:AUTO-LOOP⟧