Constant ask for MCP Tool approvals

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #16233
• #16171
• #15770
• #15437
• #16536

Powered by Codex Action

I have the same issue. This way MCP is unusable with codex

Hello? When is this gonna be fixed?

This is still an issue in v0.124.0

@efrazer-oai Any update? Why did you close the PR for this?

Confirming this is a platform-independent, upstream-side issue. Reports of the same symptom in this thread (and the linked dups below) cover macOS, Windows, and Linux — including via the official Desktop app and via Codex CLI directly. The shared component is the Rust codex-mcp elicitation manager, not anything platform-specific.

(For context on the Linux end of this: I'm running an unofficial repack of the macOS Codex Desktop app.asar + the upstream codex-rs CLI on Debian/Ubuntu — the wire-level pieces that handle elicitation are byte-identical to upstream, which is what made the absent persistence layer easy to spot from the source.)

Following the breadcrumbs through codex-rs to understand why "Always allow" doesn't persist:

In codex-rs/codex-mcp/src/elicitation.rs, the ElicitationRequestManager only:

1. Auto-accepts elicitations whose requested_schema.properties is empty (confirm-only dialogs), or
2. Forwards everything else to the UI via tx_event and resolves once.

There is no persistence layer for accepted-with-_meta.persist=always responses. Each session starts with an empty allow list, and the user's "Always allow" choice from a previous session is lost.

This makes the "Always allow" UI checkbox a no-op for any elicitation with a non-empty schema (= effectively all MCP tool-call confirmations).

The Desktop GUI does persist a narrow subset — browser navigation origins are written to ~/.codex/browser/config.toml [origins].allowed. Everything else (generic MCP tools, js_repl, file edits, custom MCP servers, etc.) is per-session only.

A proper fix needs a persistence layer in ElicitationRequestManager, keyed on (server_name, codex_approval_kind, connector_id, scope) where scope is origin / tool_name / sensitive_data (matches the dimensions the Desktop UI's "Always allow" checkbox already binds to in _meta).

On the closed PR mentioned upthread

Looking through related PRs:

• #17822 ([codex] fix repeated MCP approvals after always allow) by @efrazer-oai — opened 2026-04-14, closed 2026-04-27 by the author with no comment, no reviews. The diff was tiny: +3 / 0 in mcp_tool_call.rs plus +71 of regression tests. From the body, it targeted an in-session ARC ask-user regression — i.e. it would have helped within a single session but does not add cross-session persistence.
• #21231 (Support Always Allow for MCP app messages) by @leoshimo-oai — open since 2026-05-05, but scoped specifically to MCP App follow-up messages (mcp_app_message_approval_mode), not the general elicitation manager.

Neither touches ElicitationRequestManager, so the cross-session persistence gap that this issue describes is still entirely unaddressed.

@efrazer-oai if you have a moment, would you mind sharing why #17822 was closed without comment? Knowing whether the approach was superseded, the scope was felt to be wrong, or it was just deprioritized would help downstream maintainers (and users hitting the duplicates listed below) decide whether to land their own workarounds.

Related (likely all root-caused here): #18133, #18706 (closed-as-dup), #16233, #16171, #15770, #15437, #16536, #17668.

@codengine I am working on this approval-fatigue problem from the policy side.

The model I am testing in Agent_Sudo is scoped delegation instead of repeated prompts or a permanent blanket allow. Example: allow this MCP tool for this actor, under this resource/path/argument scope, for N minutes or N uses; everything else still requires approval or is denied, and each decision is logged.

Would that kind of bounded delegation cover the “constant ask for MCP tool approvals” pain, or would you prefer a simpler static auto-approve list?

The overlap I see in this report is that “Allow always” needs a precise scope. If the remembered approval is too narrow, users get repeated prompts; if it is too broad, it can become a real security problem. The hard part is defining what the approval is bound to: MCP server, tool name, arguments, workspace, session, or some combination.

Limitation: this comment is not about the right Codex UX or whether a particular safeguard is firing correctly. I am only asking about the underlying approval-binding invariant.

Would you want that capability as something Codex depends on, a library, a spec/conformance test-kit, or something implemented directly inside Codex?