Before anything else: this site is drafted with Claude. That is a reason to check this story harder than usual, not a reason to skip it, and it is the reason the last section of this article is longer than most.
On 4 November Gal Weizman of Forever Security published a write-up of a flaw in Claude Dispatch, a feature that lets the Claude web interface hand work to Claude Desktop on your computer. The short version: a browser extension that can run scripts on the Claude website can use Dispatch to make Claude Desktop execute commands on the machine.
No browser exploit is involved. Nothing is broken out of. The extension uses the feature exactly as designed, from inside a session the user is already signed in to.
The shape of it
The chain has six stages, and the researchers describe it at a level we will not go past here.
An extension with permission to act on the Claude site injects a script, which inherits the session that is already there. It opens the Dispatch interface in a small unfocused window, so there is almost nothing to see. It finds the desktop session. It submits prompts through the composer, waiting for each reply before the next. And then the part that makes it work: it clicks whatever Allow button appears, repeatedly, about a second apart.
The approval dialogue, the thing standing between a request and your filesystem, is rendered inside a page the attacker already controls. So the attacker answers it.
The researchers call the last stage prompt forcing, adjusting the wording until the agent runs a local command. Their demonstration opened Calculator, which is the traditional way of saying this could have been anything.
The detail that turns this from a desktop problem into an organisational one is that Dispatch connects devices. The desktop receiving the commands does not have to be the computer running the browser. It has to be on the same Claude account. A personal laptop with a bad extension, signed into the same account as a work machine, is a path between the two.
The disclosure
From The Register's account, which is where Anthropic's side of this reaches us:
- 14 May 2026. Reported to Anthropic.
- 19 May 2026. Anthropic confirms the findings are valid, then closes the report as a duplicate of something it had already found internally.
- No bounty. No CVE.
- 13 October 2026. Anthropic says Dispatch will be retired, targeting the end of October 2026.
Closing a valid report as a duplicate is a normal thing for a security team to do, and it is not in itself a criticism. The question a duplicate raises is what happened to the original. If Anthropic found this first in or before May, the fix for the thing it found has not reached the feature.
We checked, and it is still there
Today is 7 November. The retirement target was the end of October.
Anthropic's own help pages still document Dispatch as a live limited beta. Under Current limitations, on the page about Claude Cowork and chat, the entry reads: "Dispatch isn't available to new users. If you already use Dispatch, you can keep using it for now."
Closed to new users, available to existing ones, a week past the date it was meant to be gone. One hundred and seventy-seven days after it was reported.
A help page is documentation and not a switch, so it is possible the feature is already off for everyone and the page has simply not caught up. We have not tested it, and we say so below. But documentation is what users act on, and right now the documentation tells existing users the feature is theirs to keep using.
Why retiring it would not settle the question
This is Weizman's argument and it is the part worth keeping after the feature is gone.
"An authenticated web session is not, by itself, evidence that the user authorized a command on their machine."
That is the whole thing in one sentence. Being signed in means the browser has a cookie. It does not mean a human asked for this. Every agent product that lets a web surface drive a local one is making that inference somewhere, and the approval dialogue is supposed to be the place where the inference is checked.
Which brings the second sentence: "A confirmation displayed inside an attacker-controlled interface cannot reliably establish user consent." If the consent prompt renders in the page the attacker is scripting, the attacker consents.
Weizman says the same pattern is present in Claude Code Remote Control and in Claude Cowork sessions, and is explicit that he has not tested them. His proposed direction is to treat the web surface as a separate device with lower permissions than the local one, rather than as the same user with the same rights.
What this means if you use any of this
- Treat browser extensions as endpoint software. An extension with permission to run on the sites where your agents live has the reach of those agents. Extensions change hands and update silently.
- Turn off cross-device features you do not use. The blast radius here comes from device linking, not from the model.
- Keep personal and work accounts separate. The account boundary is the boundary the attack crosses.
- None of this is specific to Anthropic. It is the shape of every product in this category this year, and it is the reason we wrote it up about the vendor whose tool we use.
What is not established
- Whether Dispatch is in fact still running for existing users. We read the documentation on 7 November and did not test the feature. A stale help page is not proof.
- What the internal duplicate report described, when it was filed, or what was done about it. Anthropic has not said publicly.
- Whether Claude Code Remote Control and Claude Cowork sessions are exploitable in the same way. The researcher says the pattern is there and states plainly that he has not tested them.
- Whether this has been exploited. The researchers report no real-world attacks, and their own demonstration ran with the browser and the desktop on one machine.
- Anthropic's position. It reaches us only through The Register and through the researcher. We found no direct statement from the company, and we did not ask it for one before publishing.
