[BUG] MCP connector 'Always allow' ignored on individual Pro plan

[jason-goodman]

Summary

On my individual Pro plan, the "Always allow" setting for personal MCP connectors (Gmail, Google Workspace) is not persisted — every tool call still triggers an approval prompt. On a separate Team plan account belonging to the same user, with the same connectors and the same Projects-based workflow, "Always allow" works correctly.

This is the opposite of #19731 (which framed the same symptom as Team-Plan-only). Posting per the auto-close message on #19731 ("please file a new issue and reference this one if it's relevant").

Reproduction (individual Pro plan)

1. Install personal MCP connectors (e.g. Gmail, Google Workspace) at Settings → Connectors
2. Set them to "Always allow"
3. Open a chat in a Project
4. Use a connector tool → approval prompt appears
5. Approve with "Always allow"
6. Use the same tool later (new chat in same Project, or same chat after a delay) → tool prompts for approval again

Expected

Per the Settings → Connectors UX, "Always allow" should persist across chats and Projects without re-prompting.

Actual

Approval prompt appears for every tool call. If the user is AFK when the prompt fires, it eventually times out and the tool call fails with No approval received.

Secondary bug: misleading error message

No approval received is indistinguishable from an OAuth/auth failure to the user (and to other Claude assistants helping diagnose — I had one tell me to reconnect the connector at Settings → Connectors, which obviously didn't fix anything). Suggest distinguishing "user did not approve in time" from "connector auth is broken" in the surfaced error string.

Comparison data point (potentially useful for triage)

Same user, same connectors (functionally equivalent), same Projects-only workflow:

• Individual Pro plan account (personal-installed connectors): bug reproduces ❌
• Team plan account (org-managed connectors at org admin level): works correctly ✅

This is the inverse of what #19731 reports. The split suggests the bug is in the per-user / personal-connector permission-persistence path, not the org-managed connector path.

Environment

• claude.ai web interface
• Confirmed 2026-05-06 (recurring for at least the prior 2 days)
• All chats are inside Projects

References

• [BUG] MCP Tool Permissions Not Persisting Between Chats in claude.ai Projects (Team Plan) #19731 — same symptom, framed as Team-Plan-only, closed stale 2026-02-27, auto-locked 2026-03-08
• [BUG] MCP tools prompt for permission even when already authorized in permission settings #28580 — MCP tools prompt for permission even when already authorized
• [BUG] MCP Permission Bypass Regression - Post-Outage Issue Affecting Multiple Accounts #8859 — Post-outage permission regression

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] MCP Tool Permissions Not Persisting Between Chats in claude.ai Projects (Team Plan) #19731
2. [BUG] MCP tools prompt for permission even when already authorized in permission settings #28580
3. [BUG] permissions from user settings.json is NOT applied at project level #5140

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[github-actions]

Closing for now — this doesn't appear to be about Claude Code. Please open a new issue if this is still relevant.

[touchmtwin-sketch]

I'm experiencing the same issue with Routines on the Claude Desktop app (latest version). The error "MCP tool call requires approval" occurs on every run — both scheduled and manual — across all three connectors I've tested: Gmail, Google Calendar, and Notion.

This makes Routines essentially unusable for any workflow that involves MCP connectors. Given that connector integration is a core use case for Routines, I'd like to request that this be prioritized for a fix.

Please let us know if there's a workaround or an expected timeline for resolution.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.