Mobile "Code" controller permission approval hangs local CLI TUI with in-progress tool call

Resolved 💬 3 comments Opened Apr 18, 2026 by jasonjgarcia24 Closed Apr 18, 2026

Summary

Approving a permission prompt from the Claude Code mobile app's "Code" controller while a local Claude Code CLI session is running wedges the local TUI: the in-flight Bash tool call renders an indefinite spinner (blinking dot), and the local terminal becomes unresponsive to Esc / Ctrl-C / input. The session itself continues to function via the mobile controller (messages still flow), so this appears to be a local TUI / state-sync bug, not a backend session failure.

Repro

  1. Start a local Claude Code CLI session in a terminal on Linux (Ubuntu).
  2. Connect the mobile app's "Code" controller to that session.
  3. Prompt the assistant to run a Bash tool call that is NOT covered by the allowlist (so it requires approval). Compound commands (e.g. cmd1 | xargs -I {} cmd2 {}, heredocs, multi-pipe chains) seem especially prone to triggering this.
  4. When the permission prompt appears, approve it from the mobile controller rather than the local terminal.

Expected: Tool runs, result is rendered in the local TUI.
Actual: Tool call stays "in progress" (blinking dot) in the local TUI indefinitely. Esc, Ctrl-C, and typing are all no-ops in the local terminal. Assistant-side context receives Tool result missing due to internal error. The mobile controller continues to function — new prompts/responses flow through it — proving the backend session is alive, only the local view is desynced.

Recovery

Only recovery found is killing the local \claude\ process (e.g. from a different terminal) and relaunching with \claude --resume\ to re-attach to the session.

Environment

  • OS: Ubuntu Linux 6.17.0-20-generic
  • Claude Code CLI version: 2.1.114
  • Mobile: Claude Code mobile app, "Code" controller
  • Reproducible: appears to be consistent when the above conditions are met

Suggested investigation

Looks like the permission-approval ACK routed via the mobile controller isn't propagating the "tool resolved" event back to the local TUI's render loop. Permissions are being honored by the backend (tool either runs or errors), but the local renderer never clears the spinner and the input handler stays blocked on a prompt state that's already been resolved remotely.

Happy to provide \ANTHROPIC_LOG=debug\ traces on request next repro.

View original on GitHub ↗

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