[BUG] computer-use request_access approval renders only in the session TUI — never surfaces in Remote Control clients (macOS/iOS app, claude.ai/code)

Preflight Checklist

• [x] I have searched existing issues — closest matches are #67702 (auto-closed as duplicate), #58562 (stale-bot closed with "open a new issue if still relevant" — it is), and #60385 (closed as completed, but this variant still reproduces on 2.1.218; see below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.218)

What's Wrong?

The computer-use MCP request_access approval renders only in the session's own terminal TUI. It never surfaces in any Remote Control client — macOS Claude app, iOS app, or claude.ai/code — even though ordinary tool-permission prompts from the same session render in those clients correctly (i.e. the general fix from #60385 works; this specific approval UI is the exception).

From the Remote Control side the session just looks busy/waiting forever. The only way to discover what it's waiting for — and to answer it — is tmux attach on the host and respond to the approval dialog in the TUI.

Reproduced twice on 2026-07-24 on the same host (two separate sessions), and consistent with the symptom in #58562 (request_access appears to hang / time out with no visible dialog).

Steps to Reproduce

1. On an always-on Mac, start Claude Code in a detached tmux session:

tmux new-session -d -s test -c <project> 'claude --remote-control --name "Test"'

1. Connect to the session from the Claude macOS app or iOS app (Remote Control).
2. Send /mcp enable computer-use (works fine over Remote Control).
3. Ask the session to do something that triggers request_access (e.g. requesting access to UTM and Finder).
4. Observe the Remote Control client: no approval UI ever appears; the session sits waiting.
5. tmux attach -t test on the host: the approval dialog is right there in the TUI and answering it unblocks the session.

What Should Happen?

The request_access approval should surface in the connected Remote Control client the same way ordinary tool-permission prompts do.

Impact

This is the single blocker to fully phone-managed computer use. A headless/always-on machine driven via Remote Control can never complete the app-approval step without the user keeping terminal access around solely for this one dialog. Session-lifetime approvals make it survivable for long-lived sessions (approve once at spawn, at a terminal), but any newly spawned or restarted session hits the wall again.

Environment Info

• Platform: darwin (macOS, Darwin 25.5.0, Apple Silicon Mac mini)
• Claude Code: 2.1.218
• Session host: detached tmux, claude --remote-control --chrome --name "<name>"
• Remote Control clients tested: Claude macOS app, Claude iOS app
• Related: #67702, #58562, #60385 (general prompt routing fixed; this approval UI still not routed), #74160 (desktop app's approval side panel failing — possibly the same UI component on a different surface)

🤖 Generated with Claude Code