Your session is still running.
Your phone doesn't know.
Claude Code Remote Control retries for about 31 seconds and then gives up for good. cckeep notices, and re-arms the session — without ever typing into one that's busy.
Zero dependencies · zero cloud · zero telemetry — it reads your tmux panes and nothing leaves the machine.
Thirty-one seconds is the whole budget.
Every one of these outlasts it. The link closes, and the documented recovery is to walk back to your desk and type /remote-control.
You close the laptop to move rooms. It reconnects for 31 seconds, then stops trying.
Wi-Fi to LTE, office to café, VPN reconnecting. Longer than half a minute, and it's over.
Two floors of no signal costs you the session you were about to check on.
Sometimes it just sits in “reconnecting” forever — issue #34255, open since March, 99 👍, no fix.
It will not type into a session that's working.
A watchdog that types into your terminal on a timer is a liability unless it's certain the moment is safe. Every rule below is enforced and tested.
The pane is captured twice, two seconds apart. A running turn animates a spinner and a token counter — identical captures mean nothing is happening, different ones mean hands off.
Permission prompts turn Enter into a selection. If a selection marker is on screen, the pass is skipped entirely.
/remote-control opens a status panel with a QR code. cckeep presses Enter there only when it opened the panel itself.
Only panes seen connected at least once are ever chased. Disable Remote Control deliberately and it stays off.
One action per pane per five minutes, so a genuinely broken link can't turn into a stream of keystrokes.
The decision is made from one capture, then re-verified after the wait. Reconnected in between? Dialog appeared? Nothing is sent.
--dry-run prints exactly what it would do and sends nothing. Run it for a day before you trust it.
What it watches for.
| State on screen | What it means | What cckeep does |
|---|---|---|
/rc active | connected | remembers the pane, nothing else |
/rc reconnecting | inside the 31-second budget | waits — this usually resolves on its own |
/rc reconnecting · 2 min | wedged (#34255) | cycles the bridge: opens the panel, disconnects, reconnects |
Remote Control disconnected | gave up | re-arms immediately |
| no indicator, pane had one before | notification scrolled away | re-arms after 4 quiet checks |
| no indicator, pane never had one | not your setup | nothing, ever |
One command away.
npm i -g cckeep # install globally — an npx path would vanish cckeep enable # launchd on macOS, systemd user timer on Linux cckeep # what it sees right now — changes nothing cckeep watch # run in the foreground instead of scheduling cckeep doctor # tmux, panes, scheduler, paths cckeep logs # what it has done cckeep disable # remove the background job
A session started in a bare terminal can't be reached from another process — there's no channel to type into, so no tool can help it. Restarting the process isn't an alternative: that ends the conversation, which is the thing you were trying to save.
The README has a drop-in shell function that wraps interactive launches only, so claude update and claude -p keep behaving normally.
The best outcome is that this becomes unnecessary.
cckeep re-arms a connection. It can't raise Claude Code's retry budget — that's a constant inside a closed-source binary, and only Anthropic can change it. If #34255 gets fixed, the right move is to archive this repo. Until then, a 👍 over there is worth more than a ⭐ here.