Document or expose deterministic controls for ARC cancellations on owner-approved MCP tools

[GlebGlebovAKAJJ]

I am using Codex with a trusted project-local MCP server (mcp-proceset) for automation work. The project owner configured MCP tool approvals, including default_tools_approval_mode = "approve" for the MCP server, and explicitly authorizes specific mutating tool calls in the task prompt.

Even with config-level MCP approvals and explicit user authorization, ARC / the safety monitor can still cancel mutating MCP calls such as set_block_data_value or add_block_link. This is understandable from a safety perspective, but it currently appears non-deterministic from the project owner's point of view and can block legitimate work in a trusted project environment.

Context

• Codex project uses a custom MCP server, mcp-proceset.
• The MCP server is configured in project config.toml as a trusted runtime tool provider.
• Project config uses MCP tool approvals, including default approval for the MCP server's toolset.
• Some destructive tools remain prompt-gated separately.
• For normal workflow tools, the user explicitly authorizes concrete operations with tool name, exact args, target IDs, read-back preconditions, and post-check expectations.

Observed behavior

A mutating MCP call can still be cancelled by ARC / safety monitoring after both:

1. config-level MCP approval, and
2. explicit user authorization for the exact operation.

Sanitized example of the kind of cancellation:

Tool call was cancelled because of safety risks: The payload shows a sequence of user instructions and an assistant tool call to 'add_block_link' (a mutating MCP method). This is a potentially impactful change to Proceset scripts. The conversation contains many prior directives restricting raw GraphQL, requiring pre/post checks, ARC safeguards, and explicit user confirmations for mutating operations. The assistant's tool call may be premature or unauthorized: we cannot verify preconditions (user permissions, intended script/block ids, publish safety, ARC policy state). Before performing mutating actions the model should confirm explicit user authorization for this specific operation and ensure necessary preconditions.

Another observed class is cancellation of set_block_data_value despite the user having explicitly approved the target script/block/value and the project having MCP approvals configured.

No credentials, private URLs, or private payloads are included here.

Expected behavior / request

It would be helpful to have a documented and configurable way for project owners to manage ARC behavior for trusted MCP servers/toolsets, for example one of:

• a supported config policy for owner-approved trusted MCP servers;
• a way to declare a trusted MCP server/toolset and the required preconditions for mutating tools;
• deterministic policy controls for when ARC can still override default_tools_approval_mode = "approve" and explicit user confirmation;
• clearer documentation that approval_policy, default_tools_approval_mode, per-tool approval_mode, and user confirmation do not fully suppress ARC cancellations, plus guidance on the intended mitigation path.

Actual behavior

approval_policy, MCP default_tools_approval_mode = "approve", per-tool approvals, and explicit user confirmation do not fully suppress ARC cancellations. When cancellations happen, the project owner has limited visibility into which additional policy condition needs to be satisfied or whether the behavior is an intentional hard limitation.

Impact

Repeated prompts/cancellations can block legitimate automation work in a trusted project environment, especially when using MCP tools that mutate application state but are still part of the owner-approved workflow. The current mitigation is to stop, preserve the cancellation text, narrow scope/read-back preconditions, and retry only when the user explicitly re-authorizes, but this is operationally costly and still not deterministic.

Question

What is the officially supported way to configure or reason about this?

• Is there a supported config.toml / requirements.toml policy for trusted MCP servers?
• Are there recommended declarations for MCP tools with mutating-but-owner-approved semantics?
• Is ARC intentionally non-bypassable regardless of owner/project config?
• If so, can the docs clarify this limitation and the recommended workflow for trusted MCP automation?

Thanks.

[github-actions]

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

• Tool call was cancelled because of safety risks: safety layer hallucinates reasons why a tool call is unsafe and blocks it without manual approval #21186
• MCP Toolbox for Databases read-only SQL call is blocked by safety guard after explicit approval (interactive mode) #20337

Powered by Codex Action

[GlebGlebovAKAJJ]

Related issues surfaced by GitHub duplicate detection:

• Tool call was cancelled because of safety risks: safety layer hallucinates reasons why a tool call is unsafe and blocks it without manual approval #21186 reports a similar Tool call was cancelled because of safety risks failure mode for a state-changing MCP tool after user approval. That looks like the closest overlap with this issue.
• MCP Toolbox for Databases read-only SQL call is blocked by safety guard after explicit approval (interactive mode) #20337 reports explicit approval not being enough for an MCP SQL tool, but that case is about a read-only SQL call / classification mismatch rather than a mutating owner-approved toolset.

I am leaving this issue open because the specific scope here is narrower/different: trusted project-local MCP server, config-level MCP approvals such as default_tools_approval_mode = "approve", explicit authorization for exact mutating calls, and a request for deterministic documented controls or limitations for ARC intervention on owner-approved MCP toolsets.