Failure and recovery
What survives when something goes wrong, and what doesn't. ccr-cloud is built so that dropped connections and control plane restarts don't lose task activity. It does not make a task's actions exactly-once, and a crashed task loses what it hadn't reported yet.
#How delivery works
- Activity from a task (Claude's messages, tool calls, approval requests, status) is numbered by the task's runner and kept in its memory until the control plane confirms it has written it to the task's log. After a reconnect, the runner resends everything unconfirmed, and the control plane skips numbers it already has.
- Your actions (follow-ups, approvals, interrupts) are saved in the task's record first, then sent until the runner confirms receipt. The runner ignores repeats during one run.
- The app replays the task's log from where it left off when you reconnect.
#What happens when…
| Situation | Effect on the task |
|---|---|
| Your browser, phone or SSH tunnel disconnects | None. The task keeps running; the app catches up when you reconnect. |
| The control plane restarts or is updated | Tasks keep running. Their runners reconnect and resend unconfirmed activity; your saved actions are delivered. Open approvals stay open. |
| The connection between a runner and the control plane drops | Same as a restart: activity and actions are resent when it reconnects. |
| The runner or Claude Code crashes or exits | The task becomes Stopped or Failed, within about 10 seconds if nothing reports it. Open approvals are cancelled. See below. |
| You select Interrupt turn or Stop session | Claude stops the current turn or exits. Open approvals are cancelled. |
| The server reboots | Everything stops. Restart the service, then resume tasks; see Operate your server. |
Resume restarts the task's runner, which continues Claude Code's saved conversation in the same workspace.
#What a crash can lose
When a runner or Claude Code process dies unexpectedly:
- Unreported activity. Anything the runner hadn't yet had confirmed by the control plane is lost with it. On a normal exit, the runner waits up to 10 seconds to deliver everything first.
- Follow-ups waiting for the current turn. The runner holds them until Claude finishes the turn. If it dies first, they're lost; send them again after resuming.
- Open approvals. They're cancelled and shown as Cancelled. Claude never got a decision, so it may ask again after you resume.
- The tool call in progress. It isn't retried. Its side effects, such as edited files or a command that already ran, stay as they were. Check the workspace before asking Claude to continue.
#What isn't guaranteed
- Exactly-once actions. A follow-up or decision can, rarely, be delivered twice: if a runner restarts after receiving it but before its confirmation reaches the control plane, the next run receives it again. A decision only applies to the exact request it answers, and a new run starts with no open requests, so a repeated decision can't approve something else; it fails harmlessly.
- Exactly-once tool effects. ccr-cloud records what Claude did; it can't undo or deduplicate commands. That's why approvals show the exact command.
- Power-loss durability. Logs are written as each event arrives but aren't forced to disk. A power failure or kernel crash can lose the last moments of activity.
- Partial tool output. Tool output is recorded when the tool finishes, not while it runs, so a long command shows nothing until it ends.
#Approvals
- A decision applies only to the one request it answers, in that task.
- A request can be answered once. A second answer, from another device or from Discord, is rejected.
- Interrupting, stopping, restarting or crashing a task cancels its open requests.
- Allow once runs the tool with exactly the input you reviewed.