Anyone else had an AI coding agent (Claude Code, Codex, etc.) silently die mid-task when your connection dropped?

Yes — I’ve seen the same failure mode with long-running agent work. The network drop is only half the problem; the dangerous part is not knowing whether the task stopped before a step, during a step, or after a partial change.

What helped me was making every unattended run leave behind an explicit state trail:

• a heartbeat while the task is active
• a durable run log with the last completed stage
• a clear success or failure marker
• a notification when the heartbeat stops or the final marker never arrives
• small, independently verifiable steps instead of one huge task

For remote work, tmux or screen keeps the process alive, while a webhook or local notification tells you whether it actually finished. I also treat “no completion signal” as a failure state rather than assuming the session is still running.

The key distinction is between preserving the process and preserving confidence in the result. Even if the agent survives the disconnect, each stage should leave enough evidence to verify what was applied before resuming.

The interesting part is the silent failure, not the connection drop itself. If an agent can run unattended for 20+ minutes, knowing that it stopped becomes part of the workflow rather than just a convenience.

Yes, this feels like a real issue, especially with long-running agent tasks. The annoying part isn’t just the connection drop — it’s that you may not realize anything failed until much later.

I think a simple heartbeat or completion/failure notification would solve a big part of it. For unattended tasks, getting an alert when the agent stops responding or loses connection would be much better than periodically checking the terminal.

Curious whether this happens more often with specific tools, or if it’s mainly a general problem with long-running sessions and unstable connections.

The part that stands out is the 20+ minutes gone before you noticed, not the Wi-Fi blip itself.

What helped me was writing one sentence for the core job of a background run: this session has to leave the repo in a state I can read without asking the agent what happened. Once that sentence exists the fix gets obvious, every stage commits or appends a line to a run log, so the terminal is never the only record of what happened.

I keep the checklist I use for that here: https://durablefoundations.gumroad.com/l/pyramid-reality-check

What does a long session have to leave behind before you would trust it unattended?

Kael Voss / DurableFoundations

The connection-drop failure mode isn't the scariest part for me, it's that I can't tell, as someone who doesn't write the code, whether a session that got cut mid-task left something half-applied or fully rolled back. An engineer can read the diff and know. I can't, not reliably. That's why I stopped running Claude Code unattended for longer than one task small enough that I can verify the result myself just by using the feature, not by reading what changed. Building Alisio, the cost of a silent death used to be discovering a broken build 40 minutes later with no idea which part of a multi-file change actually landed. Now I keep the unit of work small enough that even a silent failure only ever costs me one verifiable check, not a debugging session I'm not equipped to run.

Yes, and the reason it stings is that a dead terminal looks exactly like a working one — there's no signal to react to, so you find out by walking back to the desk. What fixed it for me was stopping treating the laptop as the host: run long sessions inside tmux (or screen) on a box that isn't the machine whose Wi-Fi drops. Then the connection dying just detaches the client, the process keeps going, and I reattach later. If the session has to live locally, mosh instead of plain SSH survives brief drops far better than TCP does.

The other half is making silence noisy: have the task's last step write a done-marker file or ping you, so "no message" means failure rather than "probably still running." Cheap version is long-task; notify-send done or a curl to a webhook at the end. Once absence of a signal is itself a signal, you lose minutes instead of half an hour.