TL;DR

• Claude Code Computer Use drives a real macOS desktop, gated by a per-application approval list the user controls each session. Finder is flagged as able to read or write any file.

• In Claude Code 2.1.218, two checks gave Finder a free pass: a click could land on Finder even when it was never approved, and once Finder was frontmost, every later keyboard and mouse action was allowed without a Finder grant.

• That let an unapproved sequence open Finder's Go to Folder dialog, navigate to an attacker-controlled directory, and open a .command file, which macOS handed to Terminal to run in the user's context.

• In the proof of concept, only one harmless fixture app was ever approved. Finder and Terminal stayed off the grant list the whole time, yet all eleven actions completed.

• Anthropic rated it High (CVSS 7.7), fixed it in 2.1.243, and a retest confirmed the fix. A CVE and advisory are pending.

At a Glance

Turning on Claude Code Computer Use does not hand Claude your whole desktop. Before Claude can click or type in an application, you approve that application for the session, and the more powerful applications come with sharper warnings.

Finder is labelled as able to read or write any file. Terminals and IDEs are labelled as equivalent to shell access.

Our security research team at CodeAnt AI found that in Claude Code 2.1.218, Finder quietly sat outside that approval list.

Two authorization checks treated Finder as a special case, and together they opened a complete path around the gate: a Computer Use sequence could wake up Finder, open a file, and reach Terminal, all without Finder or Terminal ever being approved. Here is the whole thing, kept short.

The Boundary That Was Supposed to Hold

The rule is simple. Every action Claude takes has to land on an application the user approved for this session, at a tier that permits that action. A click can change which application is in front. A keystroke then goes to whatever is now in front.

So both the click target and the new frontmost application have to satisfy the grant, independently, every time. In the tested session, exactly one application was approved: a harmless fixture built for the test.

Finder was not on the list. Terminal was not on the list. The approval list was the only thing standing between Claude and the rest of the machine.

Two Checks, the Same Finder Exemption

Reverse engineering the signed 2.1.218 runtime turned up two authorization functions, and both let Finder through.

The first decides which application sits under a requested click. Ordinary unapproved applications are rejected. Finder was returned as a success before the approval list was even consulted: javascript

let target = await executor.appUnderPoint(x, y);if (target.bundleId === "com.apple.finder") return null;   // allowed before any checkif (!grants.has(target.bundleId)) return appNotGranted(target);

let target = await executor.appUnderPoint(x, y);if (target.bundleId === "com.apple.finder") return null;   // allowed before any checkif (!grants.has(target.bundleId)) return appNotGranted(target);

let target = await executor.appUnderPoint(x, y);if (target.bundleId === "com.apple.finder") return null;   // allowed before any checkif (!grants.has(target.bundleId)) return appNotGranted(target);

The second protects keyboard and mouse actions based on whichever application is currently in front. It also waved Finder through before returning the normal "not approved" error.

So the first exemption moved focus into Finder, and the second kept authorizing every action after Finder was in front.

The revealing detail: the same runtime still classified Finder as a sensitive, filesystem-wide application at approval time, which is why it shows the stronger warning.

Finder was recognised as sensitive when the user was asked, and then exempted when the actions actually ran. Approval and enforcement pointed at different things.

This is not the first time a single-application exemption has slipped past Claude Code's macOS sandbox: our earlier research traced a path-and-glob confusion sandbox escape and a TOCTOU filesystem-identity race in the same trust boundary.

The recurring shape is a check that resolves identity once, early, and never revisits it.

The Chain, End to End

Once focus was inside Finder, the rest was ordinary keyboard driving:

1. Click the Finder desktop.

2. Open Go to Folder with cmd+shift+g.

3. Type the attacker-controlled directory, then Return.

4. Type launch-canary.command.

5. Open it with cmd+o. macOS handed the .command file to Terminal as its registered handler, and Terminal ran it in the user's context. The file did one harmless thing: it wrote an execution marker in the test directory. Eleven actions in total, all allowed.

The Proof

The test was built so only one variable moved: which application received the unapproved action. Same session, same signed binary, same user decision, same grant list, same local fixture.

The ordinary unapproved application was correctly blocked, which proves the allowlist was switched on and doing its job. The equivalent Finder sequence completed.

After execution, the grant list was unchanged: still just the one fixture, no Finder, no Terminal. No Bash tool call, no clipboard permission, no system-shortcut permission, and no second confirmation was involved.

The marker proved host execution, but the real capability shift happened earlier. Before the bypass, model-controlled actions were confined to the one approved fixture.

After it, the same session was driving a filesystem-wide application and reaching a shell-capable file handler.

Impact and a Realistic Trigger

This was not push-button remote code execution. Computer Use had to be enabled, the user had to approve some other application for the session, and something had to steer the GUI sequence.

That steering is the realistic part: content the model reads during an ordinary GUI-assisted task, such as malicious repository instructions, a crafted test page open in an approved app, or on-screen prompt injection, can nudge it toward a sequence that looks like opening a build artifact.

Once the sequence reached Finder, the affected logic allowed operations the user never approved: navigating user directories, opening or moving or deleting files through Finder, launching applications and documents through their handlers, and opening an attacker-controlled .command file through Terminal, as shown.

The failure was precise. The application identity Computer Use acted on was not required to be one the user had approved.

The Fix, and the Retest

Anthropic shipped a fix in Claude Code 2.1.243 and invited a retest with the original reproducer. Same session, same single approved fixture, same unchanged Finder chain.

This time the first desktop click was rejected and a Finder grant was explicitly required. The batch stopped with zero actions completed and ten remaining.

The command file was never selected, Terminal never ran it, the marker never appeared, and the grant list stayed the same.

The fix held at the right place: the action was refused at the gate, before focus or application identity could change.

Remediation Principles

The direct fix is to remove the unconditional Finder success branches from both functions. The broader design lesson generalises to any Computer Use surface:

• Authorize the click recipient. A click must require a grant for whatever application is under the coordinate.

• Reauthorize after focus changes. Every later keystroke or click must revalidate the current frontmost application.

• Keep desktop behaviour narrow. If a bare desktop-background click needs special handling, do not let that exception cover Finder windows, dialogs, icons, or Spotlight, and do not let it authorize future input.

• Bind batches action by action. A batch must stop the moment the receiving application becomes an unapproved one.

• Test the sensitive transitions. Regression coverage should include Finder, Terminal, IDEs, System Settings, Dock, Spotlight, open and save panels, and registered file handlers. In our own code security work across agentic tools, this is the pattern worth flagging in review: an identity check that resolves once, early, and is never revisited after focus moves.

Are You Affected?

The vulnerable behaviour is in Claude Code 2.1.218 on macOS, with Computer Use enabled.

If you use Computer Use, confirm you are on 2.1.243 or later, where a desktop-shell click correctly requires the explicit Finder grant before any later action lands.

Check your version with claude --version; standard auto-update should already have carried the fix. You can track this and other disclosed agentic-tool findings in our vulnerability database.

Disclosure Timeline

The Takeaway

Per-application authorization is an object-identity problem.

The approved thing is not "the desktop" or "the session." It is the specific application that receives each action.

Special cases are where that slips: Finder is also the macOS desktop shell, so a narrowly intended desktop click looks harmless, until the exemption returns general success and quietly inherits Finder's windows, shortcuts, filesystem reach, and file-handler transitions.

Three questions carry past this one bug. Which principal was approved? Which principal receives the action after each focus change, modal, or launch? And can a special-case branch turn one principal's approval into another principal's capability?

For a system that drives a real desktop, those need an answer at every click and every focus change.

References

• Claude Code Computer Use documentation

• HackerOne report #3885687 (private at the editorial cutoff)

• Tested affected build: Claude Code 2.1.218, macOS arm64

• Tested fixed build: Claude Code 2.1.243, macOS arm64

This research is part of an ongoing effort by CodeAnt AI Security Research to audit the trust boundaries in agentic development tools. It was conducted under Anthropic's vulnerability disclosure program; the proof of concept used isolated local fixtures and a harmless execution marker, and no third-party data or production service was accessed.

Building an agentic tool that drives a desktop or an IDE and want its authorization boundary reviewed? Reach us at securityresearch@codeant.ai