Show HN: Cckeep – Claude Code's remote session gives up reconnecting in 31s Cckeep, a new open-source tool by developer Kamihork, prevents Claude Code's Remote Control sessions from silently disconnecting by re-arming them within 31 seconds, addressing a known issue where sessions give up reconnecting after 5 attempts with exponential backoff. The tool runs as a background job via launchd on macOS or systemd on Linux, checking every 15 seconds, and requires Claude Code to run inside tmux. It also works around a separate bug (anthropics/claude-code#34255) where sessions wedge in reconnecting mode, which has been open since March 2026 with 99 upvotes and no fix. Keeps Claude Code Remote Control from silently going dead. Remote Control retries for about 31 seconds and then gives up for good. cckeep notices, and re-arms the session β€” without touching one that's busy. Remote Control https://code.claude.com/docs/en/remote-control lets you drive a local Claude Code session from your phone or from claude.ai. It reconnects on its own when the link drops β€” for 5 attempts with 1/2/4/8/16-second backoff . That is a 31-second budget. Close your laptop lid, switch Wi-Fi, ride an elevator, and the budget is gone. The connection closes and never comes back. There is a second failure too: the session wedges in /rc reconnecting and sits there forever. That one is anthropics/claude-code 34255 https://github.com/anthropics/claude-code/issues/34255 β€” open since March 2026, 99 πŸ‘, no fix. Either way you find out the same way: you reach for your phone, and the session is gone. The documented recovery is to walk back to your desk and type /remote-control . npm install -g cckeep cckeep enable npm install only puts the CLI on your PATH ; cckeep enable is the step that registers a background job β€” launchd on macOS, a systemd user timer on Linux β€” that checks every 15 seconds and re-arms whatever went dead. Install it globally rather than running npx cckeep enable . The scheduled job runs cckeep from wherever it was installed, and npx's cache is throwaway: a job pointing into it keeps working until the cache is cleared and then stops, silently β€” the one failure a watchdog must not have. cckeep enable refuses to schedule from an npx path for that reason. To look before installing anything, npx is fine β€” neither of these changes a thing: npx cckeep what it sees right now npx cckeep doctor check tmux, panes, and the scheduler command not found: cckeep right after installing? You are on a shim-based version manager. nodenv and rbenv -style setups need a rehash before a newly installed binary appears on PATH , and nvm needs a new shell: nodenv rehash nodenv asdf reshim nodejs asdf nvm: just open a new shell One requirement: Claude Code has to be running inside tmux. A session started in a bare terminal cannot be reached from another process, so there is nothing any tool can do for it. See Running Claude Code in tmux running-claude-code-in-tmux . If cckeep saved you a walk back to your desk, a ⭐ helps other Remote Control users find it. This is the whole design problem. A watchdog that types into your terminal on a timer is a liability unless it is certain the moment is safe. Every one of these is enforced, and tested /kamihork/cckeep/blob/main/test : Never on top of what you typed. Enter submits whatever is in the composer, so an unsent draft would go out with the command glued onto it. If anything is in the box β€” or the box cannot be found at all β€” nothing is sent. The idle check cannot cover this: a draft sitting in the box is perfectly still. Never during a turn. The pane is captured three times. A running turn animates a spinner and a token counter, so identical captures mean nothing is happening. Three rather than two, at an interval that is deliberately not round, because any animation whose period divides the interval would otherwise alias into identical frames. Never into a dialog. Permission prompts turn Enter into a selection. A selection marker counts anywhere on screen; the plain English phrasings only count near the composer, since Claude Code writes sentences like "Do you want me to run the tests as well?" in ordinary replies. Never into the panel you opened. /remote-control opens a status panel with a QR code. cckeep only presses Enter there when it opened the panel itself, and only if the panel is still up when it goes to press it. Never a session that only mentioned it. The indicators are read from the last few rows, never from the transcript, so a session discussing /rc active is not mistaken for a connected one. A pane that has never been seen connected is only ever acted on when Claude Code itself prints that the link died. Never in a tight loop, and never twice at once. One action per pane per 5 minutes, and a lock so that cckeep watch running alongside the scheduled job cannot interleave two passes into one garbled prompt. Never against a wall. Replies like β€œRemote Control requires a claude.ai subscription” mean reconnecting is impossible here β€” an auth or plan problem the command cannot fix β€” so the pane is dropped until the link is seen healthy again. And for failure modes it cannot recognise, at most 3 re-arms per outage; after that it stops and waits to see the link healthy rather than retyping into your transcript forever. Re-checked at the last moment. The decision is made from one capture, then re-verified after the wait β€” reconnected in between, dialog appeared, something typed? Nothing is sent, and the pane keeps the progress it had made rather than starting its wait over. --dry-run prints what it would do and sends nothing. | State on screen | What it means | What cckeep does | |---|---|---| /rc active , or a truncated /rc | connected | remembers the pane, nothing else | /rc reconnecting | inside the 31-second budget | waits β€” this usually resolves | /rc reconnecting , 2 minutes on | wedged | Remote Control disconnected cckeep status: one line per Claude Code pane cckeep watch run in the foreground instead of scheduling cckeep once a single pass β€” what the scheduler runs cckeep enable start checking in the background cckeep disable stop checking cckeep doctor tmux, panes, scheduler, paths cckeep logs what it has done Options: --dry-run , --json , --interval