[BUG]

I would separate this into a permission-request delivery invariant rather than treating every retry as the same MCP tool failure.

For a gated MCP tool call, the runtime needs to distinguish at least five states:

1. approval request was never created;
2. request was created but not delivered to the active client;
3. request was delivered, but the response stream closed before a decision was recorded;
4. user explicitly denied the request;
5. retry superseded or replayed a still-pending request.

Those should not all collapse into "requires approval" or "denied by user." They have different recovery behavior.

The acceptance test I would want is small:

• emit a pending permission request with request id, tool name, server identity, and run/session id;
• keep the run in waiting state until that exact request resolves, expires, or is superseded;
• reject resume with a mismatched request id;
• on retry, either reuse the pending request or create a new superseding request, but record which happened;
• never execute the gated tool unless the matching approval decision is bound to the pending request.

That gives the client a debuggable contract: if the prompt never renders, the trace can show whether the failure was request creation, client delivery, response transport, explicit denial, or retry state.

Thanks for the detailed report — a few findings.

On 2.1.233 (Linux, terminal) I checked the permission-gated MCP tool path directly: a gated tool call is held for approval, is blocked with a clear message when no approval is given, and runs normally once approved. So MCP permission gating itself isn't broken generally.

Your report is about the web/cloud session surface, where the approval prompt has to be relayed to a browser or mobile client. That path can't be driven from a terminal, so we could not reproduce your exact scenario here.

That said, what you describe is a bug: a prompt that never appears, and a call reported as "Denied by user" when you were never shown anything, are both wrong. There is a fix in a release after the 2.1.201 you were on for pending permission prompts not appearing to clients (changelog) — it may or may not cover your case, so we're keeping this open.

To help us pin it down, could you confirm: which client you were on (claude.ai in a browser, or the mobile app), roughly when the session ran, and whether it still happens in a current session?

🤖 Generated with Claude Code

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.