Claude Code computer use says permissions are "not yet granted" after you granted them

A long-running Claude Code bug report (#50735) documents that computer use returns a "macOS Accessibility and Screen Recording permission(s) not yet granted" error even when the terminal and Claude.app are already granted, because the built-in computer-use server runs inside the CLI process and macOS checks the `claude` binary itself. Users traced the failure to three causes: the binary not being granted directly (fixable by resolving the real path with `readlink -f` and dragging it into both privacy lists), a running session not picking up a new grant until restart, and a per-version helper store in `~/Library/Application Support/Claude/claude-code/` that the desktop app writes only for the CLI version it bundles, so an auto-updated CLI ahead of the app hits the TCC message. A separate symptom, `request_access` returning denied with no prompt, is tied in #103373 to sessions started remotely from a claude.ai Projects thread.

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 https://github.com/anthropics/claude-code/issues/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 https://code.claude.com/docs/en/computer-use 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 https://github.com/anthropics/claude-code/issues/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 https://auten.ai/mcp?utm source=devto&utm medium=social . Hit this error with a cause not on this list? Describe it in the comments, with your macOS and CLI version.