claude.ai connectors should be opt-in per project in Claude Code, not enabled everywhere by default
Summary
Any MCP connector enabled on a claude.ai account is automatically injected into every Claude Code
session, in every project directory, with no way to opt out for the CLI as a whole. Enabling a
connector for claude.ai / the desktop app should not imply consent to load it in Claude Code —
these are different surfaces with different use cases.
The defaults are inverted relative to how connectors are actually used in a CLI. Account
connectors should be off by default in Claude Code and enabled per project where they are
relevant, rather than on everywhere and suppressed per project where they are not.
This is not specific to any particular connector. It follows from how account-level connectors
are delivered to the CLI, so it applies to every current and future entry in the connector
catalog. The Google connectors below are just the ones I happen to have enabled.
Current behavior
Connectors enabled on the account are loaded by every Claude Code session. In my case:
$ claude mcp list
claude.ai Gmail: https://gmailmcp.googleapis.com/mcp/v1 - ✔ Connected
claude.ai Google Drive: https://drivemcp.googleapis.com/mcp/v1 - ✔ Connected
claude.ai Google Calendar: https://calendarmcp.googleapis.com/mcp/v1 - ✔ Connected
The available opt-out paths all fall short:
claude mcp remove "<connector name>"— no effect. Account connectors are not in any local
mcpServers config; they are pushed from the account, so there is nothing local to remove.
/mcp→ disable — works, but writes a per-project key:
``jsonc``
// ~/.claude.json
"projects": {
"/home/user/some-project": {
"disabledMcpServers": ["claude.ai Gmail", "claude.ai Google Calendar", "claude.ai Google Drive"]
}
}
This must be repeated for every project directory, and every newly opened directory starts
with the connectors enabled again.
~/.claude/settings.json— there is no user-scopedisabledMcpServers. The existing
disabledMcpjsonServers / enabledMcpjsonServers settings apply to project .mcp.json
servers, not to account-level claude.ai connectors.
- Disconnecting at claude.ai → Settings → Connectors — the only global fix, but it removes the
connector from claude.ai and the desktop app too. There is no way to keep a connector for the
web/desktop surface while excluding it from Claude Code.
The net effect is that the only maintainable state is all-on or account-wide-off. The
per-project control that exists points the wrong way: it is a denylist that must be maintained
once per connector per directory, and it silently fails open for any new directory or any
connector added to the account later.
Expected behavior
Invert the default for account-pushed connectors in Claude Code:
- Off by default in Claude Code. Connecting an account connector should provision it for the
CLI without activating it there. Nothing is silently added to a coding session.
- Enabled per project, explicitly.
/mcpgrows an enable action that writes a per-project
allowlist — the mirror of today's disabledMcpServers — so a project where Drive or Calendar
genuinely helps can turn it on, and that choice stays scoped to that project.
- A user-level default for people who want the current behavior. A setting in
~/.claude/settings.json to enable account connectors globally preserves today's experience as
an opt-in for users who want it, rather than removing the capability.
This matches the direction of the existing project-scoped .mcp.json model, where servers are
declared where they are used, and of claude plugin disable, which is already user-scoped rather
than per-project. It also mirrors how tool permissions are handled generally in Claude Code:
grant where needed, not everywhere by default.
If inverting the default is too large a change, a user-scope opt-out that applies to account
connectors as a class would at least make the current behavior escapable — but it leaves the
defaults pointed the wrong way, and every newly enabled connector still arrives switched on.
Why this matters
Claude Code sessions are usually scoped to a code repository, and much of the connector catalog
is oriented toward personal productivity and general knowledge work rather than coding. Those
tools are rarely relevant in a repo, and their definitions consume context on every session while
adding unrelated tools to the model's surface area.
There is also a scope-of-access argument for defaulting off. Connecting Gmail or Drive to the
web app is a decision about that surface; having it silently become reachable from every coding
session in every directory is a broader grant than the user made. Default-off with explicit
per-project enablement is the least-surprising behavior and the one that ages well as users add
more connectors over time.
Environment
- Claude Code version: 2.1.220
- Platform: Linux
- Connectors enabled on the account (incidental to the report): Gmail, Google Drive,
Google Calendar