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>/

Summary

Built-in computer-use MCP returns "macOS Accessibility and Screen Recording permission(s) not yet granted" from request_access and list_granted_applications on macOS 26.5 (Tahoe) with CLI v2.1.114, even when every plausible TCC principal is granted in both panes. The failure persists across CLI restarts. Evidence strongly suggests the gate is not macOS TCC state — it is an internal per-CLI-version helper-bundle / .verified sentinel under ~/Library/Application Support/Claude/claude-code/<VERSION>/, which auto-update did not re-provision.

Likely a variant of / related to #41538, #42404, #31647.

Environment

• macOS: 26.5 (Darwin 25.5.0), ARM64
• Claude Code CLI: v2.1.114 (installed under ~/.local/share/claude/versions/)
• Terminal: Warp 0.2025.x (auto-updates via staged binary under ~/Library/Application Support/dev.warp.Warp-Stable/old)
• Plan: Max 5x, authenticated via claude.ai
• CLI identity: codesign -d -r- on ~/.local/share/claude/versions/2.1.114:
• Identifier=com.anthropic.claude-code
• TeamIdentifier=Q6L2SF6YDW
• Designated requirement is identifier-based (not cdhash)

Reproduction

1. CLI v2.1.111 installed and computer-use enabled on 2026-04-16; helper bundle auto-provisioned at ~/Library/Application Support/Claude/claude-code/2.1.111/.
2. CLI auto-updated 2.1.111 → 2.1.112 → 2.1.113 → 2.1.114 over subsequent days.
3. Invoking mcp__computer-use__request_access or mcp__computer-use__list_granted_applications in v2.1.114 returns the "permission(s) not yet granted" error, even though:

• CLI binary com.anthropic.claude-code ON in both Accessibility and Screen Recording panes.
• Claude Desktop app com.anthropic.claudefordesktop ON in both panes.
• Warp (dev.warp.Warp-Stable) ON in both panes.
• Bash, axorc, tmux, python3.14, uv, AEServer all ON in Accessibility.

Diagnostic observations

• ~/Library/Application Support/Claude/claude-code/ contains only 2.1.111/ — no 2.1.112/.113/.114 directories. Despite v2.1.114 being the running CLI for multiple days.
• The 2.1.111 directory contains a zero-byte .verified sentinel and a full claude.app/ bundle (Contents/{Info.plist,MacOS/claude,_CodeSignature/CodeResources}). Info.plist has CFBundleIdentifier=com.anthropic.claude-code, CFBundleVersion=2.1.111, LSBackgroundOnly=true.
• Strings of the flat CLI binary show libComputerUseSwift.dylib, runComputerUseMcpServer, createComputerUseMcpServerForCli, AppBundleResolver.swift, and build artifacts from packages/desktop/claude-swift/Sources/ComputerUseSwift/ — the Swift extraction pipeline is linked in.
• Literal .verified is NOT a string constant in the flat CLI — path is runtime-constructed.

Hypothesis

The CLI's computer-use gate first-checks for a per-version support directory with .verified + valid claude.app/ bundle. If absent, request_access short-circuits to "not granted" regardless of actual macOS TCC state. Auto-update did not re-run the provisioning code path that originally minted 2.1.111/, leaving the directory orphaned at 2.1.111 while the running CLI is 2.1.114. This is consistent with the "helper missing" pattern in #31647 and the macOS-26-specific failure mode in #41538 / #42404.

What does not fix it

• Granting CLI binary + Desktop app + Warp (both /Applications and staged old) in both panes.
• Two /quit + fresh claude + /resume cycles.
• Waiting 90s for TCC propagation quirk.

What might fix it (not yet tried, to avoid further local mutation)

• /mcp disable computer-use followed by /mcp enable computer-use — to re-trigger the Swift AppBundleResolver extraction code path that originally created 2.1.111/. Risk: if the gate is ".verified exists for ANY version", the 2.1.111/ sentinel short-circuits this into a no-op.
• Moving/deleting 2.1.111/ to force re-extraction on re-enable.
• Fresh CLI reinstall via the canonical installer.

These were designed as a fix ladder but not executed pending upstream guidance — manual re-bundling ran into the identifier com.anthropic.claude-code + Team Q6L2SF6YDW Developer-ID requirement, which is not locally reproducible.

Requests

1. Document the per-CLI-version support-dir mechanism at ~/Library/Application Support/Claude/claude-code/<VERSION>/ — whether .verified is sufficient or the full claude.app is required, how it is provisioned, and what regenerates it.
2. Fix the auto-update path to re-provision the support dir for the new version (or migrate it forward in place).
3. Surface a clearer error than "permission(s) not yet granted" when the internal gate (not macOS TCC) is the blocker. Current message sends users on a long, fruitless TCC diagnosis.
4. Provide a claude doctor-style diagnostic or documented recovery command (e.g., claude computer-use --reinit) so users can force re-provisioning without a full reinstall.

Happy to provide

• Full codesign -dvvv, codesign -d -r-, and Info.plist dumps of both the flat CLI and the 2.1.111 helper.
• ls -la of the support dir tree.
• strings grep output for the relevant symbols.
• Full plan/investigation file if helpful (3 rounds of adversarial-council review led us to this hypothesis).

Related

• #41538 — Built-in computer-use MCP: checkAccessibility undefined on macOS Tahoe
• #42404 — computer-use MCP fails on macOS Tahoe 26
• #31647 — Cowork runtime missing from macOS app bundle