You turn on computer use in Claude Code on a Mac, Claude calls request_access, and it comes back with:
macOS Accessibility and Screen Recording permission(s) not yet granted
You open System Settings. Your terminal is on in both lists. So is Claude.app. You toggle them off and on, restart, reboot. Same error.
It is a long-running computer-use report on the Claude Code tracker (#50735 and several duplicates), with reports from CLI 2.1.104 up to 2.1.263 on Sonoma, Sequoia and Tahoe. The people in that thread found three different causes behind the same message. Check them in this order.
Anthropic's own troubleshooting note says to quit Claude Code completely after granting Screen Recording and to confirm your terminal app is listed. If you already did both, read on.
The built-in computer-use server runs inside the CLI process, so macOS checks the claude binary itself. A grant on Terminal, iTerm, Warp or Claude.app is not enough.
The trap: screencapture from your shell works, because it runs under the terminal's grant. So a quick test looks fine while the MCP stays blocked.
Fix, as reported in the thread:
readlink -f "$(which claude)" # the real binary, not the symlink
open -R "$(readlink -f "$(which claude)")" # reveal it in Finder
Drag that file into both Accessibility and Screen & System Audio Recording in System Settings > Privacy & Security, and turn both toggles on. The search field in the permission dialog often cannot find it (for example under /opt/homebrew), so drag from Finder. On npm installs the file may end in .exe even on macOS. That is a build artifact; do not double-click it.
A running session will not see a grant you just added. Quit Claude Code and start it again. claude --resume brings your session back.
If the binary is granted, you restarted, and it still fails, look here:
claude --version
ls ~/Library/Application\ Support/Claude/claude-code/
Users in #50735 traced the gate to a per-version helper store in that folder (a claude.app plus a .verified marker). One report (matteocirca, Sep 2026) found it is written by the Claude desktop app for the CLI version the app bundles, while the native CLI auto-updates on its own. When the CLI moves ahead of the app, there is no helper folder for the running version and you get the TCC message, even though TCC is fine.
Things that reportedly did not fix it: disabling and re-enabling computer-use in /mcp, claude install, toggling computer use in the desktop app, relaunching the app. Copying an older version's folder under the new version number was rejected too.
What worked for that user:
~/.local/share/claude/versions/<version-that-has-a-helper-folder> --resume <session-id>.
Another user reports a helper folder a few versions behind working fine once Cause 1 was fixed, so a version mismatch on its own is not proof. Fix 1 and 2 first.
A different symptom with a similar feel: request_access returns denied with no prompt anywhere. Recent reports (#103373) tie it to sessions started remotely, from a claude.ai Projects thread, where the same request works from a session started in the desktop app. If you see that, try the same task from a local session before debugging permissions.
readlink -f "$(which claude)" is in both Accessibility and Screen Recording.claude --version has a matching folder in ~/Library/Application Support/Claude/claude-code/; if not, start from the desktop app.
We build Auten, an MCP server that gives Claude Code, Codex, Cursor or any MCP client hands on a real screen: your computer (Mac, Windows, Linux) and your Android phone (beta). On a Mac it needs the same Accessibility and Screen Recording grants as anything else that clicks for you, so we spend a lot of time on exactly this kind of permission problem. Setup is at auten.ai/mcp.
Hit this error with a cause not on this list? Describe it in the comments, with your macOS and CLI version.