computer-use MCP returns "permission(s) not yet granted" on macOS 26.5 despite comprehensive TCC grants — orphaned per-version helper at ~/Library/Application Support/Claude/claude-code/<ver>/

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48311
2. https://github.com/anthropics/claude-code/issues/49282
3. https://github.com/anthropics/claude-code/issues/41606

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is a good diagnosis. The evidence points away from raw macOS TCC state and toward Claude Code's own per-version helper provisioning as the actual gate.

The strongest clues are:

• every plausible TCC principal is already granted in both panes
• the failure persists across CLI restarts
• the break appears after multiple auto-updates
• the suspected state lives under ~/Library/Application Support/Claude/claude-code/<VERSION>/

That pattern fits a versioned helper/sentinel model much better than a genuine permission denial. macOS thinks the app is allowed, but Claude Code is checking for a per-version helper bundle or .verified marker that was never re-created after update.

In other words, the user-facing error says "permission(s) not yet granted," but the real failure is likely "internal version-specific helper state missing or stale."

That is important because it sends users to the wrong place to debug. They keep toggling TCC permissions when the actual fix is probably re-provisioning the helper for the current version.

The robustness rule here should be: auto-update must either

1. migrate the helper/sentinel state forward, or
2. lazily re-provision it on first computer-use invocation for the new version

Never require manual permission surgery when the OS permissions are already correct.

This also matches a broader theme this week: version-specific hidden state (helpers, locks, model IDs, plugin manifests) drifting out of sync with the visible runtime state. The misleading permission error is a symptom of that same control-plane consistency problem.

hit this exact pattern shipping our macOS agent. the tell is that TCC state is correct but an app-side sentinel is stale, which is why toggling Accessibility and Screen Recording in System Settings does nothing. anything that caches a .verified marker under ~/Library/Application Support/<app>/<version>/ breaks on auto-update unless the updater explicitly migrates or lazily re-provisions.

the other trap is designated requirement drift. if the CLI is identifier-based (not cdhash) TCC will persist across versions, so the OS side looks fine, but internal gates that verify bundle layout fail because the extracted claude.app/ under 2.1.111/ doesn't match 2.1.114 strings. blowing away the whole claude-code/ dir and letting /mcp enable re-extract has been the only reliable fix for us. the real bug is that request_access short-circuits on missing helper rather than actually calling AXIsProcessTrustedWithOptions and reporting the true TCC state.

Confirming this bug — additional data point from CLI v2.1.118, macOS 15.x (Sequoia).

Same root pattern as reported. Support dir frozen at an old version:

$ ls -la ~/Library/Application\ Support/Claude/claude-code/
drwx------ 4 marcellin staff 128 Apr 16 15:18 2.1.101

$ ls -la ~/Library/Application\ Support/Claude/claude-code/2.1.101/
-rw------- 1 marcellin staff   0 Apr 16 15:18 .verified
drwxr-xr-x 3 marcellin staff  96 Apr 16 15:18 claude.app

$ claude --version
2.1.118 (Claude Code)

Installed 2.1.101 on 2026-04-16, auto-updated through multiple versions to 2.1.118 over the following week. No 2.1.118/ directory was ever provisioned. Only the original install version has the .verified sentinel + claude.app/ helper bundle.

Additional symptom variant

Slightly different surface from the OP: in my setup, computer-use works right after each cold CLI launch, then breaks mid-session — sometimes after macOS sleep/wake, sometimes without an obvious trigger. Full /exit + claude recovers temporarily until the next mid-session failure. Host terminal (Ghostty 1.3.1, com.mitchellh.ghostty) remains granted in both Accessibility and Screen Recording panes throughout.

That points to at least two failure modes under the same root cause:

1. Cold gate — new CLI version + missing helper → request_access short-circuits from first invocation (OP's case)
2. Warm gate degradation — initial gate passes via some fallback path, but re-evaluation later in the session fails because the version-matched .verified was never written

Both converge on the per-version support-dir provisioning that auto-update doesn't re-run.

Environment

• macOS: 15.x (Sequoia), Darwin 25.1.0, ARM64
• Claude Code CLI: v2.1.118 (global npm install at ~/.npm-global/lib/node_modules/@anthropic-ai/claude-code/)
• Terminal: Ghostty 1.3.1 (com.mitchellh.ghostty, TeamID 24VZTF6M5V)
• Plan: Max 20x, authenticated via claude.ai
• Native binary: 198MB Mach-O arm64 at node_modules/@anthropic-ai/claude-code-darwin-arm64/claude
• In-process MCP server version: computer-use v0.1.3 (from MCP connection log: {"name":"computer-use","version":"0.1.3"})

Error surface

From mcp__computer-use__list_granted_applications and request_access:

macOS Accessibility and Screen Recording permission(s) not yet granted.
The permission panel has been shown. Once the user grants the missing
permission(s), call request_access again.

CLI dialog:

Computer Use needs macOS permissions
Accessibility: ✗ not granted
Screen Recording: ✗ not granted

Grant the missing permissions in System Settings, then select "Try again".
macOS may require you to restart Claude Code after granting Screen Recording.

Try again does not recover. request_access followup after apparent system settings toggles does not recover. Only full CLI restart does — and only until the next mid-session failure.

+1 on OP's asks

Especially:

• Auto-update path must re-provision the per-version support dir (or migrate in place)
• Error message distinguishing "internal helper missing" from actual macOS TCC deny — current message sent me on an hour-long TCC diagnosis before I found this thread and saw the orphaned directory

Happy to test any supported recovery sequence (/mcp disable computer-use, stale-version-dir removal, targeted reinstall) and report back results on this CLI version.

Same - also experienced this bug despite having checked both are granted. Killed Claude, rebooted laptop, nothing works.
I'm on MacOS Sonoma 14 and CLI 2.1.104

Accessibility: ✘ not granted
Screen Recording: ✔ granted

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Hit the same error string with a different root cause — worth noting for people landing here:

The built-in computer-use MCP runs inside the CLI process, so TCC needs the CLI binary itself, not the terminal app:

1. readlink -f $(which claude) — resolves to …/@anthropic-ai/claude-code/bin/claude.exe (yes, it is really named .exe on macOS — build artifact, it works; don't double-click it, macOS hands .exe to The Unarchiver)
2. open -R "$(readlink -f $(which claude))" — Spotlight doesn't index /opt/homebrew, so the permission dialog's search field will never find it
3. Drag claude.exe from Finder into both Accessibility and Screen & System Audio Recording, enable the toggles
4. Restart the CLI — grants are only read at launch; claude --resume keeps your session context

Terminal/Claude.app grants are not enough — the cruel part is that shell screencapture can work through the terminal's grant while the MCP stays blocked, so quick sanity checks look fine.

If all of that is correct and it still loops, check the orphaned per-version helper described in this thread (~/Library/Application Support/Claude/claude-code/<VERSION>/) — same error string, distinct cause. For what it's worth: on my machine a helper dir three versions behind the CLI works fine once the TCC side is fixed, so a version mismatch alone isn't proof.

Same symptom on macOS 26 / CLI 2.1.263 (native install), with what I believe is the actual root cause after tracing it.

Symptom: computer-use MCP request_access returns "macOS Screen Recording permission(s) are still not granted" although Screen Recording and Accessibility are granted to Claude.app, iTerm and the browser, and the Claude desktop app's own Computer use (Settings → Computer use) shows both as "Granted" and works.

Root cause: the per-version helper store ~/Library/Application Support/Claude/claude-code/<version>/ (.verified + claude.app, bundle id com.anthropic.claude-code) is written by the desktop app, not by the CLI. The provisioning code lives in the desktop app's app.asar (findInstalledBinaryPath(storageDir, version, ".verified"), a hashing writer for .verified, a "[CCD] Binary preflight: .verified marker missing but binary exists …" log line), and the app bundles a fixed runtime version — Claude.app 1.46388.4 carries claude-code/0.3.260, i.e. CLI 2.1.260. The native CLI auto-updates independently (2.1.260 → 2.1.261 → 2.1.263 within 48 h on this machine), and the CLI's computer-use gate looks for a helper matching the running CLI version. So every CLI auto-update that outruns the app's bundled runtime breaks computer-use for terminal-launched sessions until the next desktop release catches up — and then it reopens on the next CLI release. On this machine the store contains only 2.1.260/ (created 2026-09-04 07:00, hours after the CLI installed 2.1.260 — i.e. when the app provisioned it), nothing for 2.1.261 or 2.1.263.

Things that do NOT provision a helper for the running CLI version (all tried): /mcp disable computer-use + /mcp enable computer-use (with and without the stale dir present), claude install, a fresh interactive claude start, a claude -p … run, toggling "Enable computer use" off/on in the desktop app, relaunching the desktop app. Copying the 2.1.260 claude.app + .verified into a 2.1.263/ directory is rejected by the gate (the .verified hash is version-specific), so it can't be worked around locally. claude doctor reports no issues.

Suggested fix: either (a) have the CLI's computer-use gate accept the app-managed helper regardless of the CLI's own version (the helper is the app's runtime and works fine), or (b) have the CLI provision its own helper on update, or (c) at minimum surface "helper bundle missing for <version>" instead of a misleading TCC error.

Workaround for anyone hitting this: run the session on the app-bundled CLI version, e.g. ~/.local/share/claude/versions/2.1.260 --resume <session-id>, or launch the session from the desktop app's Claude Code view (which spawns the bundled runtime).

This issue was incorrectly closed by the github-actions, despite originally having reproduction steps and Claude version. This bot behavior is tracked in https://github.com/anthropics/claude-code/issues/87647. Consider upvoting that issue for visibilty, maybe the bot behavior gets fixed.