[saucam]

Stacked on #373. This shows only #368's change. Once #373 merges, I'll retarget it to main and rebase it, and CI will run then.

What this fixes

When codex wants to use a tool on an MCP server (GitHub, say), it asks for approval naming only the server, not the call. codeoid remembered one pending call per server. So with two calls to the same server in flight, for example a delete_repo and a get_issue on GitHub, the approval could show the other call: approving what looked like get_issue could let delete_repo through.

Now:

• When codex says which call it means (it usually does, in its message and request details), the approval shows exactly that call, and the result is paired back to it.
• When it doesn't and several different calls to that server are waiting, codeoid declines without asking and puts the reason on the card. It never guesses.
• An MCP server's own questions are no longer mistaken for tool approvals. These are a sign-in link or a form from the server itself, and they arrive the same way as codex's approvals. Before, one could be accepted automatically with its link never shown. Now it's shown, with its message and link, and declined; answering those properly is a follow-up.
• Approvals codex can't tie to a started call get unique ids. Before, they all shared one id per turn, so answering one could settle another.

Verification

Ran against a real codex-cli 0.154.0 with codeoid's memory MCP server mounted. A recall call went through codex's approval request and reached codeoid's approval gate (audited as session.auto_approve tool=mcp__codeoid_memory__recall). It ran and returned its real result.

This confirms that real codex marks its tool approvals the way the new check expects, so genuine MCP approvals still work.

Tests (the fake codex follows codex 0.154's message order):

• Two calls to one server: the right one is shown and its result paired.
• Two different calls when codex doesn't say which: declined without asking.
• A server's own sign-in link: shown and declined.
• A tool name containing a quote: read in full.
• Unpaired approvals: distinct ids.
• An unmarked form request: declined.
• All of these fail against the code before this change. Full suite: 3000 pass, 0 fail. Typecheck and lint are clean.

Not run: no end-to-end regression tier; codeoid has none.

Review: two rounds of security review.

• Round 1: one High (the shared fallback id), one Medium (server questions treated as tool approvals) and Lows. All fixed with tests.
• Round 2: clean.

Closes #368

For agents: implementation detail

• src/daemon/providers/codex/index.ts.
  • Pending calls. #pendingMcpCalls is now Map<server, Array<{itemId, tool, input}>>. It is filled from item/started (mcpToolCall) and removed by item id on item/completed. It's cleared in runTurn and teardown.
  • Which elicitations count as tool approvals. Only (mode undefined | "form") && _meta.codex_approval_kind === "mcp_tool_call". Anything else gets a mcp__<server>__elicitation card showing {message, url, mode} and a tool_complete{success:false, declinedByBackend:true}, and is answered with {action:"decline"}. canUseTool is never called for it.
  • #resolveElicitedCall(server, params). The tool name comes from mcpToolFromMessage(message, server) (the anchored codex template, with the server checked) and the arguments from elicitedToolParams (_meta.tool_params; undefined when absent).
    • Both known: show exactly those, and take the first matching started item only for pairing (otherwise mcp-<uuid>).
    • Otherwise: filter the candidates. One candidate, or all identical, is used. Several different ones, or none with nothing to show, are declined as unshowable.
• Fixtures. fake-codex.ts adds mcp-two (named and unnamed), mcp-server-asks, mcp-quoted and mcp-nokind.
• Follow-up, not in this PR. Answer MCP servers' own elicitations (form/url) through codeoid's dialog surface instead of declining them.

🤖 Generated with Claude Code

[highflame-oracle]

🔮 Oracle Review

🎯 Start Here

src/daemon/providers/codex/index.ts (~31 min) — Security changes in index.ts

---

📋 PR Summary

What this PR does: Fixes a security vulnerability where MCP tool approvals could be mismatched to the wrong pending call when multiple calls to the same server were in flight, allowing a benign-looking approval to authorize a different, potentially dangerous operation.

Key changes:

• Approvals are now tied to the specific MCP call they reference (via tool name and params from codex's message), not just the server
• Ambiguous or unresolvable approvals fail closed — declined without prompting — rather than guessing which call they belong to
• Server-originated elicitations (sign-in links, forms) are no longer mistaken for tool approvals; they are shown and declined explicitly
• Unpaired approvals receive unique IDs instead of sharing one per turn, preventing cross-settlement of separate approvals

Areas affected: MCP approval resolution logic in codex provider, Pending call tracking (now per-item arrays instead of single entry per server), Elicitation classification and handling

Testing notes: Verified against real codex-cli 0.154.0 with a memory MCP server. Test suite covers: correct pairing with two calls to one server, decline-on-ambiguity when codex doesn't specify, server sign-in link handling, quoted tool names, distinct IDs for unpaired approvals, and unmarked form request decline. Two rounds of security review completed clean.

---

🔍 Code Review

This is a well-executed security fix that addresses a genuine authorization bypass risk with correct fail-closed semantics. The implementation is disciplined — it never guesses when multiple candidates exist, and it cleanly separates server-originated questions from tool approvals rather than conflating them. The two rounds of security review and comprehensive test coverage give strong confidence in the fix.

What's good:

• ✨ Fail-closed design for ambiguous approvals is the right security posture — declining without guessing prevents silent authorization of dangerous operations
• ✨ Clear separation of concerns between tool approvals (codex-driven) and server elicitations (server-driven) eliminates a subtle class of confusion bugs
• ✨ Thorough adversarial testing: the test cases directly target the failure modes identified in the bug (mismatched pairing, server questions, quoted tool names, shared IDs)

Review Stats:

---

Generated by Oracle - Highflame's AI Code Reviewer