Shared Claude Login, Someone Else’s Computer: The Hidden Cost of Account Sharing in Claude Cowork

Quick Summary: If two people share one Claude account and both have Claude Desktop with Cowork installed, a task started by either person can execute on either machine — not necessarily the one that sent the command. Cowork routes work to the account, not the device. Approve a permission prompt on your screen, and you may actually be authorizing mouse clicks, file downloads, and browser activity on a completely different, unattended computer somewhere else. This is not a rare glitch — it has been independently reproduced and documented by other users and security researchers, and it is a direct consequence of how Cowork’s cross-device architecture is built.

This article breaks down what happened, why it happens, what it has already cost other people who ran into it before us, and exactly what to change so it never happens to you.

 

1. What happened: a simple test prompt, an unexpected result

Two people were using the same Claude account. One of us opened Claude Cowork to run a basic functional test: open Chrome, navigate to Google Drive, create a new Google Doc, and write a short article on a topic.

It’s the kind of throwaway prompt you use to confirm a tool works before trusting it with anything that matters.

Cowork accepted the task and started producing screenshots to show its progress, as it normally does. Except the screenshots weren’t from the device that sent the prompt. Chrome was opening on the other person’s computer. Google Drive was loading on their screen. A document was being typed out, character by character, on a machine neither of us was sitting at, logged in under the same shared credentials elsewhere.

Every “Allow” prompt Cowork raised along the way — the confirmation step that’s supposed to represent a human consciously approving an action — was being clicked from the first device, for actions that were physically happening on the second one.

That single disconnect — approval on one screen, execution on another, physical PC — is the entire story of this article.

2. What Claude Cowork actually is

For readers unfamiliar with it: Claude Cowork is Anthropic’s agentic work assistant, built on top of the Claude Desktop app, aimed at non-developers who want to hand off multi-step tasks — organizing files, filling out spreadsheets, researching a topic and writing it up, managing a browser session — rather than chatting turn by turn.

Two features inside Cowork matter most here:

• Cowork “computer use.” This lets Claude directly operate a real desktop: moving the mouse, clicking buttons, typing text, and navigating a real browser and real applications, without any isolating sandbox between Claude and what’s on the actual screen.
• Dispatch. This is the feature that connects a phone (or a browser tab, or another desktop) to a Cowork session running elsewhere. It’s marketed as convenience — send a task from your phone while walking to lunch, come back to find it finished on your laptop. Under the hood, Dispatch is simply a persistent channel tied to your account that hands instructions to whichever desktop has an active Cowork session open.

Individually, both features are genuinely useful. The problem only appears once you add a second human into the same account.

3. How this actually works under the hood

None of what happened is random. It follows directly from three design choices, each defensible on its own, that combine badly the moment a login is shared.

Sessions are bound to the account, not the device

Cowork’s cross-device continuity — start a task on your phone, watch it finish on your laptop, review the output on the web — depends entirely on treating “you” as your Claude account, full stop. There is no separate check for “which physical machine is this person actually sitting at right now.” The account is the identity. Whichever desktop has an active, signed-in Cowork session becomes a valid execution target for any task assigned under that account, from anywhere.

Computer use has no sandbox on the receiving end

When Cowork drives the desktop directly — as opposed to working purely in an isolated cloud environment — it interacts with the real operating system: real mouse, real keyboard, real browser tabs, real logged-in web sessions. Security researchers evaluating Cowork have pointed out that when it drives a browser, it isn’t using an isolated session of its own — it inherits whatever the human is already authenticated into on that machine, across every site they happen to be logged into. That’s a feature when it’s your own machine and you intended it. It’s a liability when the machine belongs to someone else.

Dispatch doesn’t verify who is holding which device

Dispatch was explicitly built to remove the requirement that you watch the task happen. Coverage of the feature at launch described exactly this: send a task from your phone, walk away, and by the time you’re back at your laptop the work is already done, with no further clicks needed. That’s the intended experience for one person operating their own two devices. Nothing in that chain distinguishes “my phone talking to my laptop” from “your phone talking to my laptop” — because from the system’s point of view, both look identical: one account, two devices, a message sent from one, executed on the other.

Put the three together: account-bound routing + unsandboxed desktop control + a hand-off mechanism that assumes good faith on both ends, and you get exactly what happened in our test — one person’s prompt running, entirely legitimately from the system’s perspective, on someone else’s computer.

4. This isn’t an isolated case — what others have already found

This is the part worth taking seriously: our experience is not a one-off fluke. A close variant has already been documented publicly, and Cowork’s broader “an agent with real hands on a real desktop” architecture has drawn sustained, independent security scrutiny since launch.

A near-identical incident was filed as a public bug report. A user reported that a Cowork session started from a work PC silently carried out browser automation on a separate, unattended home PC on a different network. The only thing connecting the two machines was shared account credentials — no remote desktop software, no shared drives, no VPN. Files were downloaded and a browser session was driven entirely on the home machine, streamed back in real time to the Cowork interface on the work machine, while the home PC’s owner had no idea it was happening. The files the user was looking for on their work machine turned up later inside the Downloads folder of the unattended home computer.

Independent researchers flagged data exfiltration risk via prompt injection. A specialist AI-security firm demonstrated that Cowork could be manipulated, through a prompt injection hidden in content it processed, into sending sensitive local files to an attacker-controlled Anthropic account — without triggering any additional approval step once initial access had been granted. Trade press covering the finding noted the underlying flaw traced back to a similar exfiltration pattern reported months earlier in Claude Code, which had not been fully closed out by the time it resurfaced in Cowork.

A sandbox-escape vulnerability, nicknamed “SharedRoot,” reportedly affected roughly half a million macOS users running local Cowork sessions before it was patched. Researchers showed that connecting a single folder to a fresh Cowork session and issuing one short instruction could let the agent break out of its virtual machine and reach far beyond the folder it was granted — including SSH keys, cloud credentials, and browser data belonging to whoever was logged into that Mac.

Technology journalists testing Dispatch at launch described the experience in terms that double as a warning. One reviewer summarized sending a task from their phone and returning to find it already completed on their laptop, without any further input from them at any point — precisely the “hands-off” convenience that, on a shared account, becomes “hands-off your computer.”

Security teams evaluating Cowork for organizations have separately flagged the account-over-device design as a structural gap. Independent enterprise security guides note there’s currently no way for a company, even on paid tiers, to stop a user from switching to a personal Claude account on a work machine and bypassing organizational controls entirely (short of network-level enterprise restrictions), and that Cowork activity does not appear in audit logs or compliance exports at any plan tier — meaning that even after the fact, there’s frequently no trail showing what happened, on which machine, or who approved it.

Taken together, this is a pattern, not a coincidence: wherever Cowork’s account-bound, cross-device design meets more than one real human, unexpected cross-machine execution keeps showing up — whether from deliberate account sharing, a lost or compromised phone, or a subtler attack chain.

5. What this can actually cost you

It’s worth spelling out the actual damage this kind of gap can cause, beyond the “that’s a bit unsettling” reaction most people have on first seeing it.

• Loss of control over a device you’re not watching. Any task dispatched to an unattended machine runs there in full — opening apps, browsing sites, downloading files — while its owner may be asleep, in a meeting, or simply not looking at the screen.
• Data landing in the wrong place, or leaving the building entirely. In the documented case above, exported files ended up on a machine the user never intended to touch. In the exfiltration research, files could leave a user’s control entirely, sent to an attacker’s own account.
• Actions taken “as you” that you didn’t personally perform. Every action Cowork takes on a machine happens with that machine’s logged-in identity: its browser cookies, its authenticated sessions, its file access. If you approve a task that runs on someone else’s PC, it’s their identity being used to carry it out — not yours — even though you clicked “Allow.”
• No audit trail to reconstruct what happened. Because Cowork activity isn’t captured in the kinds of logs typically used to investigate incidents, figuring out afterward which device did what, and who approved it, can be difficult or impossible — particularly troubling for any shared or business context.
• A wider “shadow AI” exposure for organizations. Employees using personal Cowork-enabled accounts on work laptops — logging into a colleague’s account to “just quickly test something,” or leaving a personal Claude session open on a shared office machine — can create exactly this cross-device execution risk without any company policy having been violated in an obvious way.
• Erosion of trust in the approval step itself. The entire safety model Cowork relies on assumes the person clicking “Allow” understands, and will bear the consequences of, the action being approved. Once approval and execution happen on two different physical machines controlled by two different people, that assumption is simply false, even though the software behaves exactly as designed.

6. Why the permission system doesn’t save you here

It’s tempting to assume Cowork’s built-in safety measures — per-app permission prompts, a confirmation step before deleting files, blocklists for high-risk sites — would catch this kind of thing. They don’t, and it’s important to understand why.

These safeguards are all designed around a single, unstated assumption: the human approving an action is the same human who will experience its consequences, on the machine they’re currently looking at. Every one of them checks “should this action happen at all,” not “is the person approving it physically present at the device where it’s about to happen.”

A permission dialog has no way to know that “Allow” was clicked on a laptop in one location, for an action about to be carried out on a desktop somewhere else entirely. From the system’s point of view, one authenticated account approved an action, and that account is authorized to act — regardless of which physical machine is on the receiving end. The dialog does its job perfectly. It’s the underlying assumption feeding into it — one account, one human, one device — that breaks the moment credentials are shared.

7. How to make sure this never happens to you

The fix here isn’t a setting buried in a menu — it’s a shift in how you think about what a Claude account with Cowork enabled actually represents.

Treat a Cowork-enabled Claude login like remote-desktop software, not a streaming password. Nobody shares TeamViewer or AnyDesk credentials casually, because the framing makes the risk obvious. A Claude login doesn’t carry that same instinctive caution, but once Cowork’s computer-use and Dispatch features are active, the practical risk is comparable. One account per person, full stop, if more than one of you will ever have Claude Desktop open.

Audit and close every active session you don’t recognize. Check your account’s active sessions or connected devices regularly, and sign out anywhere that isn’t actively in use — especially old test machines, shared office computers, or devices that changed hands.

Never leave Claude Desktop signed in and open on a machine you won’t be actively supervising. If a computer is going to sit unattended while logged into a shared or otherwise sensitive account, close Claude Desktop on it, or disable Cowork/Dispatch for that session entirely.

Physically watch the first few tasks you ever run, and watch any task on a machine you don’t fully control. If you’re testing Cowork for the first time, or running it on a device that isn’t solely yours, stay present and watch the screenshots and actions as they happen rather than assuming the task is running locally.

Keep sensitive apps blocked from Cowork’s reach regardless of the sharing issue. Banking, healthcare portals, dating apps, and financial or credential-bearing tools should be off-limits to any Cowork session, shared account or not — this limits the blast radius even if a cross-device mix-up does occur.

In a workplace, assume personal accounts can end up on company machines. If you manage IT or security for a team, don’t assume nobody will log into a personal Claude account on a work laptop just to “try Cowork out.” Without network-level restrictions, there’s currently no reliable way to prevent it, so policy and awareness training matter as much as configuration.

Be skeptical of “it finished before I even opened my laptop” as an unqualified win. That experience is the whole selling point of Dispatch, and it’s genuinely convenient when it’s your own devices. On a shared account, exactly that same experience is the symptom to watch for — work getting done somewhere you didn’t expect, without your active awareness of where.

Don’t assume approving a prompt means the action is happening in front of you. Get in the habit of checking, especially early on, that the “Allow” you’re clicking corresponds to activity you can actually see on your own screen — not activity happening somewhere else that simply hasn’t been made obvious to you yet.

8. Frequently asked questions

Can Claude Cowork really control someone else’s computer? Yes, if that computer is signed into the same Claude account and has Claude Desktop with Cowork active. Cowork routes tasks to whichever device has an active session under the account that sent the instruction — it does not verify that the sender and the device being used are the same physical person.

Is this a bug in Claude Cowork? No — it’s a consequence of how Cowork’s cross-device architecture (account-bound sessions plus the Dispatch hand-off feature) is designed to work. The behavior is consistent, reproducible, and has been documented by multiple independent users and researchers, but it is not a malfunction; it’s the system doing exactly what account-bound, location-independent task routing is built to do.

Does approving a permission prompt protect me if the account is shared? No. Permission prompts confirm that an action should happen for that account — they don’t confirm which physical device or which specific human is on the receiving end. If the account is shared, an approval on one device can authorize execution on a completely different one.

What’s the single most effective way to prevent this? Don’t share a Claude login once Cowork’s computer-use or Dispatch features are involved. Give each person their own account. This removes the shared-identity condition that makes cross-device execution possible in the first place.

Has anyone else reported this happening? Yes. A closely matching case — a task started on a work PC executing silently on an unattended home PC connected only by shared account credentials — was documented publicly as a reproducible bug report. Separately, security researchers have identified related risks in Cowork’s broader architecture, including data exfiltration via prompt injection and a sandbox-escape vulnerability affecting local sessions on macOS, underscoring that Cowork’s blend of account-bound routing and direct desktop control is an active area of security scrutiny industry-wide.

Is it just Claude, or do other AI agent tools have this risk? The specific mechanics described here are particular to how Cowork and Dispatch are built, but the general risk category — an AI agent that can take real actions on a real device, tied to an account identity rather than a verified physical device — applies to any “agentic” AI tool that offers computer-use and remote-dispatch features. As more AI assistants add this kind of capability, account-versus-device identity verification is likely to become a standard question worth asking of any of them, not just Claude.

Bottom line: Cowork was built to make your work follow you across devices, and for a single person operating their own phone, laptop, and desktop, that’s a genuinely useful feature. The moment a second human shares that same login, the system has no way to tell the two of you apart — and every convenience that makes Dispatch feel effortless (working unattended, requiring no extra clicks, following the account rather than the device) becomes exactly the mechanism by which one person can end up quietly directing activity on somebody else’s computer. The fix isn’t a setting. It’s simple discipline: one Claude account per person, sessions closed when unattended, and a healthy suspicion of any task that seems to finish itself a little too conveniently.