Remote Control: mobile app connection dies overnight while tmux session stays alive

Resolved 💬 6 comments Opened Feb 26, 2026 by omachala Closed Apr 21, 2026

Description

Remote Control sessions started via the Claude mobile app lose connection overnight. The underlying Claude Code process in tmux remains alive and interactive (can tmux attach and use it normally), but the mobile app just shows a spinner and never reconnects.

This is not an initial connection failure — the remote control works fine when first set up. The connection silently dies after several hours of inactivity (overnight).

Environment

  • Claude Code version: 2.1.58 (started) / 2.1.59 (current)
  • OS: Ubuntu 24.04 LTS, kernel 6.8.0-94-generic
  • Hardware: AMD Ryzen 9 7940HS, 32GB DDR5
  • Plan: Max
  • Mobile app: Claude iOS app

Steps to reproduce

  1. Start Claude Code in a tmux session (e.g. tmux new-session -s claude "claude --dangerously-skip-permissions")
  2. Connect from mobile app via remote control — works fine
  3. Leave the session running overnight (~8+ hours idle)
  4. Next morning, open the mobile app — session shows a spinner, never connects
  5. tmux attach -t claude in terminal works perfectly — the Claude process is alive and responsive

Reproduction rate

Consistent — reproduced with two independent sessions in two different working directories on the same machine, both died overnight the same way.

Expected behaviour

The mobile app should either:

  • Maintain the remote control connection across idle periods, or
  • Gracefully reconnect when the app is reopened

Actual behaviour

  • Mobile app shows a perpetual spinner
  • No reconnection occurs
  • The Claude Code process itself is fully functional via tmux attach
  • Suggests the remote control WebSocket/signaling layer dies silently without the CLI process noticing or recovering

Additional context

The Claude Code processes also exhibit significant memory growth overnight (~480-770MB RSS after ~10 hours), which may be related to the known GC/memory leak issues (#4953, #24282). However, the processes are still responsive in the terminal — only the remote control link is dead.

View original on GitHub ↗

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