Connector per-tool permissions still reset — root cause is server identity rotation, not just app upgrades (re-raising #56954)
Re-raising #56954, which was closed as "not planned" but is still reproducing on Claude Code CLI 2.1.220.
What's wrong
Per-tool "Always Allow" permissions for connector-based MCP servers (e.g. a Linear connector added via claude.ai Connectors) silently reset to "Ask"/blocked, forcing re-approval of every tool.
New evidence on root cause
#56954 attributed this to Electron IndexedDB not surviving app upgrades. That's one trigger, but I found a second, independent one: the connector's internal server identifier itself is not stable, and changes on its own (not tied to an app version bump).
Concretely: a permissions allow-list checked into a project's .claude/settings.json months ago recorded a Linear connector's tools under the prefix mcp__claude_ai_Linear__*. Today, the same connector (same account, same Linear integration, no reinstall) exposes its tools under mcp__<opaque-uuid>__*. Since per-tool permission state is keyed to that identity, the rotation alone invalidates every previously granted permission — independent of whether an upgrade ever happened in between.
This means the fix needs to cover more than upgrade-time migration: either the server identity needs to stay stable across reconnects, or per-tool permission state needs to be keyed to something stable (e.g. the server's declared name/URL) rather than a regenerated id.
Impact
Same as #56954 — painful for anyone with multiple connectors/tools, since it forces full manual re-approval with no warning and no visible trigger (it isn't always tied to a Desktop update).
Environment
- Claude Code CLI: 2.1.220
Related
- #56954 (closed, not planned)
3 Comments
Can we please get this fixed? This is insanely annoying. As soon as you have e.g. one documentation mcp thats supposed to be used throughout all sessions are basically handicapped to being babysitted
After an update of Claude Code, multiple MCPs have regressed certain permissions for tools within the MCP to "ask". This is not just custom connectors or Linear, this is touching MCPs across multiple vendors. Individual tool permissions within the MCP have regressed to default; others have not. MCP-by-MCP search is required once this is identified, as the behavior is inconsistent across MCPs but universal to Claude Code CLI upgrades (on macOS and potentially other platforms). This is different than the "all mcp/all tools" #56954 reported in May, 2026.
Updates should preserve user-set tool permissions across MCPs. They should not revert to an earlier configuration or reset without notifying the user.
There is no global “always allow” or “always ask” setting for all tools across all MCPs. Worse, there is no quick way to audit or update permissions because individual tool settings are hidden inside each connector and require clicking through and repairing each MCP.
After this happens,
/mcpcan behave inconsistently, sometimes showing every MCP as disconnected when they are connected. An /exit and relaunch of Claude clears the “all MCP” error, but it does not fix individual tool permissions. A manual review of every MCP toolset is required to find changed permissions.If a known list of major MCPs intentionally exhibit this behavior after an upgrade, the interface should indicate permission errors on startup, and running /mcp and then selecting a "restore all tool permissions" option should be expected.
Seeing what looks like the same root cause on claude.ai (web and desktop), triggered by organization plugin updates rather than app upgrades.
Setup: our org provisions one plugin to every member. It bundles 18 remote MCP connectors in its
.mcp.json(type: http, name and URL only) plus a set of skills.What happens: members set per-tool permissions on those connectors (Always allow / Needs approval). When an owner uploads a new version of the plugin, most of those tools switch to Blocked for members, and everyone has to set every tool again.
What we ruled out:
.mcp.jsonwere identical between versions.plugin.jsonis name, version and description only).So the Blocked state appears to come from members' per-tool state being dropped on each upload. That fits the identity-rotation explanation in this issue: if republishing a plugin re-provisions its connectors under new internal ids, every member's per-tool permissions are orphaned with every plugin update. Keying per-tool permission state to something stable (the connector's name or URL within the plugin) would fix both this case and the one described above.
We are also reporting this through support.