Claude Connector Permissions: What You Approve and What Gets Enforced
The first useful question about a Claude memory connector is not whether it works. It is what the connection is allowed to do without you.
That answer gets fixed at sign-in, when you approve scopes and pick one vault, and it holds in every conversation where the connector is switched on. What follows is the control surface: what each grant means on Claude, which parts the server enforces, and where the guarantees stop.
The permission surface is two decisions
Adding the connector runs a normal OAuth sign-in. You approve scopes and choose one vault, and those two choices set the entire boundary. The connection can reach the vault you selected and nothing else, and it can call only the tools its grants allow. There is no install step, no key pasted into a config file, and nothing that sweeps your old conversations into storage on its own.
The grants are independent. Reads, writes, reflection runs, and deletion are approved separately, so a connection you set up to save notes does not come with the power to erase a vault, and a read-write connection on one project says nothing about any other vault.
The Claude integration page walks the setup once. This post is about what you are approving when you do it.
Where read-only is real, and where it is only a request
Read-only appears in three places, and they are not equally strong.
The skill packages that ship for claude.ai chat and Cowork include a read-only variant. It tells Claude not to write. That is an instruction, and instructions depend on the model following them.
The enforceable version is the grant itself. Connect with only the read scope and a save does not go through, because the server returns an insufficient-scope error. Retrying changes nothing. The read-only plugin pins that scope in its configuration, which is the version worth handing to a team.
On a managed workspace, an organization policy can block the save tool outright, for everyone, with no dependence on how any individual conversation behaves. That is the strongest setting available today.
One check tells you which of these you actually have. On a connection you intend to keep read-only, ask Claude to store a single synthetic fact. A correctly scoped connection fails the save. Do not retry it, the denial is the point. Then ask for memory status: it reports the vault, the counts, and the scopes this connection holds. When the receipt matches the intent, the setup is doing what you think it is.
Saving and deleting are separate powers
Deletion has its own scope and its own tool. The ids come from a search or inspect result, and Claude has to show what it plans to delete and get an explicit confirmation before the call. A confirmation from a save is not a deletion id. Clearing an entire vault takes the delete scope plus an exact phrase, and a vague "forget that" is never treated as consent.
The short version: a connection you approved to save notes cannot erase the vault.
What a workspace can control
Custom connectors and skills exist across Claude plans, while plugins are paid-plan packaging. Free accounts get one custom connector. On Team and Enterprise, an owner adds the connector for the organization and members connect it for themselves after that. Plan capabilities move over time, so check the current Anthropic documentation before relying on a specific row.
For Cowork, the administrator templates include a read-only variant that blocks the save and delete tools at the policy layer. That is the right shape for a group that needs recall without write access.
Isolation follows the vault, not the chat. One connection maps to one vault, and the tools take no vault argument, so nothing a model says can move a request between them. The scope handles that Cowork conversations can carry are compatibility labels for people. If two projects must never mix context, use two vaults and two connections.
What stays manual
A few steps in this setup cannot be scripted, and that is on purpose. The OAuth sign-in and vault choice happen in a real account, by a person. Organization-level distribution and permission enforcement are admin actions in that same account. Accepting a plugin or a marketplace bundle is a human decision.
Those are the points where access is actually granted, and they should stay manual.
When it looks broken
- A connector is greyed out or missing: a plan limit or an admin policy, not a bug. Free plans allow one custom connector, and managed workspaces often provision centrally.
- Memory works in one chat and not another: connectors are enabled per conversation, so check that before debugging anything else.
- Claude ignores memory: model-directed behavior, not a failure. Asking directly works, and the skill and project instructions raise consistency without guaranteeing it.
- A save is rejected: the connection is read-only. Reconnect and approve the write scope, and treat the 403 as final rather than retrying it.
- Counts look wrong: call memory status, or read the stats resource where the client exposes one. Counts come from the server, never from a model's estimate.
The connector documentation keeps the full click path, the current plan table, and the recovery steps for each of these.
Connect the vault the way you intend to run it. Create your MemoryRouter account, grant the scopes on purpose, and prove the boundary with one rejected save before real history goes in.