Four people opened their Claude connector settings in front of me on the same call. All four saw the same thing: a group labelled Read-only tools with a count next to it, and nothing beside it. No write group, no toggle, no message explaining why.

None of them had done anything wrong. None of them could fix it either, and neither could I.

How to tell in ten seconds

Open Claude settings, go to Connectors, find Microsoft 365 and look at Tool permissions. If the only group listed is Read-only tools, that is your answer. A tenant with write enabled shows a second group beside it.

The group I was looking at carried a count of ten. The six visible without scrolling were chat message search, find meeting availability, get me, Outlook calendar search, Outlook email search and Outlook find available time. Every one of them is a retrieval verb. No send, no create, no update, anywhere in the list.

You can also just ask Claude. It will tell you it has no tool available to create a draft, send a message or write a file into OneDrive or SharePoint, and that switching that on is not something it can do for you. That answer is more reliable than it sounds, because the tool list is precisely what the model can see.

Why reconnecting does not fix it

The reflex, when a connector behaves as though it is half configured, is to disconnect and reconnect. We did that live, all the way through the OAuth flow. It came back read only.

Worth doing once, because it rules out a per-user consent problem and tells you the answer sits above your head rather than in your session. Worth doing exactly once, because it will keep coming back read only.

Anthropic shipped write tools for the Microsoft 365 connector on July 7, 2026. Before that the connector was a read path by design, which is why nearly everything written about it before the summer describes it that way and was correct at the time.

The part nobody notices is one sentence in the setup guide: “If your organization was using the connector before write tools launched, they will be blocked by default.”

So if your organization connected Microsoft 365 before that date, you did not lose write. You never had it, and the day it arrived for everybody else it stayed off for you. Nothing in the product tells you. No banner, no notification, no upgrade prompt. The only visible symptom is a group of tools with a name that sounds like a description and is actually a status.

A tenant that connected after that date gets the opposite default, which is why you will find people online insisting the connector sends email while yours plainly cannot. Both are true. You are on different sides of a date.

Two gates in two different consoles

Turning it on takes two actions and they are not in the same place. Doing one without the other changes nothing, which is the part that eats an afternoon.

The first is on the Microsoft side. A Microsoft Entra Global Administrator or Application Administrator approves the wider permission set under Enterprise applications in the Entra admin center, once per tenant. The connector creates two enterprise applications there, M365 MCP Server for Claude and M365 MCP Client for Claude, and those are what you are hunting for.

The second is on the Claude side. An organization Owner turns write actions on in Organization settings, under Connectors. That switch covers everybody by default, and Enterprise plans can narrow it to named people through custom roles, which is in beta.

The scopes deserve reading before you approve them rather than after. Read gives you the shape you would expect: Mail.Read, Calendars.Read, Files.Read.All, Sites.Read.All, Chat.Read, User.Read and their relatives. Write adds Mail.Send, Mail.ReadWrite, Calendars.ReadWrite, Files.ReadWrite.All and MailboxSettings.ReadWrite.

That last one is the quiet one. MailboxSettings.ReadWrite covers automatic replies and mail rules, so the same grant that lets Claude tidy an inbox lets it change what that mailbox does when its owner is away. It is a reasonable scope for what the feature does. It is also the one I would want a security team to have seen on purpose rather than approved in a batch.

That plan detail decides how nervous to be about all of this. On Team, enabling write is all or nothing: every member who has connected gets it. If you are on Team and you want a pilot rather than a rollout, the lever that works on any plan sits on the Microsoft side, where you can assign those two enterprise applications to a named group instead of to everyone.

If you have already done the work of organising SharePoint and OneDrive for AI, this is the week it pays off, because write means a badly arranged library now gets written into as well as read from. If you have not, do that first. The permission debt in a sloppy tenant is uncomfortable enough with read.

What write still will not do

Enabling it does not close the capability question, and the gaps are specific enough to plan around.

• Claude cannot attach files to the drafts it creates. Mail sent with attachments is rejected outright.
• There is no Teams message send. Chat is readable and not writable.
• Email Claude sends carries an attribution header identifying it as agent initiated, so the receiving side can tell. File and calendar writes are not tagged, which is the asymmetry worth knowing: a calendar invite or a changed document arrives looking exactly like a person did it.
• There are per-user limits on writes, sends and recipients, and Anthropic does not publish the numbers.
• It reaches nothing on a local disk. A file on somebody’s own hard drive sits outside the connector, which matters more than it sounds if your team keeps working copies locally.

Where files can be written is the one point Anthropic’s own documentation disagrees with itself on. The security guide says create and update files in OneDrive and SharePoint, and grants Files.ReadWrite.All, which covers both. The connector page’s capability table says files in SharePoint. Assume the broader one when you are assessing risk and the narrower one when you are promising a workflow.

The local disk bullet is the one that catches people out. It is why the Claude add-in in Excel, asked to copy a workbook, returns a connector permissions error that has nothing to do with how the connector is configured.

The thing that will confuse your diagnosis

Here is the observation that will derail whoever tries to sort this out.

With the connector firmly read only, Claude Desktop still populated four draft emails in somebody’s local mail client. It did that by writing a script and running it on the machine, which has nothing to do with the connector and nothing to do with Microsoft Graph.

So “the connector is read only” and “Claude cannot write” are two different statements, and only the first one holds. Somebody in your organization will get an email drafted, will mention it in a channel, and the investigation will stall on the assumption that the connector must be working after all.

Keep the two apart, because the difference is the whole governance question. The connector is the governed path. It acts as the signed-in user, it honours directory permissions, and its scopes sit in Entra where a security team can audit them, which is the same reason connectors are the door worth watching rather than the browser. A script running on a laptop is none of those things.

Which turns the usual conversation around. If people are already getting write behaviour through the second route because the first one is switched off, leaving write disabled has not avoided a risk. It has moved it somewhere nobody can see it. The question to put to an IT director is not whether Claude should be allowed to write. It is which of the two write paths already running in the building they would rather it used.