Remote Control: Android approval signal silently dropped — server never receives it (Linux/tmux, pure remote session)

Resolved 💬 7 comments Opened Jun 2, 2026 by chateauwaubun Closed Jul 12, 2026

Summary

When approving a tool-use prompt via the Android app in a pure remote-control session (no local terminal), the approval is silently dropped — the server never receives it. The session blocks indefinitely until killed.

Environment

  • Claude Code version: 2.1.158
  • Server OS: Linux (GCP VM, kernel 6.17.0-1018-gcp)
  • Session: Claude running in tmux, launched via remote-control bridge — no local terminal
  • Client: Android app
  • Network: Solid WiFi, phone active and in foreground, no visible lag or reconnect

Steps to reproduce

  1. Start Claude Code in a tmux session on a remote Linux machine
  2. Connect via the Android app remote-control bridge (no local terminal watching)
  3. Trigger a tool-use requiring approval (in this case: Read tool)
  4. Approval prompt appears in Android app
  5. Tap Approve — prompt dismisses in the app UI
  6. Session never proceeds — stays blocked indefinitely

Session log evidence

The .jsonl session log (~/.claude/projects/.../<uuid>.jsonl) confirms the signal was dropped server-side:

15:22:01 UTC  assistant  tool_use: Read   ← waiting for approval
              ... no approval event appears in the log ...
15:23:58 UTC  queue-operation enqueue "follow-up message"
              ← arrived but never dequeued; session still blocked on pending approval

The approval event is completely absent from the log. The Android app updated its UI (dismissed the prompt) but the actual approval message was never received by the Claude Code process. After killing and restarting the session, everything worked normally.

Key distinction from #52084

This is not a local TUI desync issue — there is no local terminal. The approval signal is dropped before reaching the server process at all, confirmed by the session log. Intermittent: other approvals in the same day worked fine.

Related

  • Closes as duplicate of #52084 (now locked), which had the same symptom on Linux but no log-level confirmation of where the signal was lost

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗