Anyone else had an AI coding agent (Claude Code, Codex, etc.) silently die mid-task when your connection dropped?
I've been running long Claude Code sessions in the background while doing other stuff, and a couple of times the whole session just died when my Wi-Fi dropped for a few seconds. No error, no warning, I only found out 20+ minutes later when I came back to check on it.
Curious if this is a shared pain or just my setup. Do you run agents (Claude Code, Codex, Cursor, whatever) unattended for stretches without watching the terminal? Ever come back to find it just... stopped?
If so, how do you currently catch it? Just eyeballing the terminal now and then, or do you have some actual way of knowing? Trying to figure out if this is a real, common annoyance or if I'm the only one hitting it.
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.
Exactly that's why I built NetCheck (mac-only though). Right now it just pings me when the connection's back and how long it was down. Beats staring at a dead terminal wondering if it's dead or just slow.
That makes sense. The silent failure is probably the part that makes the problem frustrating in practice. Would you be open to sharing the best email to reach you on?
tulon@metulon.com works. Happy to chat more if you're actually running into this.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
The thing worth separating here is detection versus recovery, because the thread is solving the first and the pain is actually the second. A network monitor tells you the wifi came back and how long it was down, which is genuinely useful, but it doesn't get back the 20 minutes of work the dead session took with it. Catching the death faster doesn't change what the death cost. I run an agent unattended for long stretches, and the reframe that actually killed this problem for me was to stop trying to keep the session alive and instead make its death a non-event: the task commits progress to disk continuously and every run is resumable from that state, so a session dying costs me the last small increment, not the whole run. Once the work is durable, "is it still alive" stops being a question I need answered in real time. Two things fall out of that. First, the connection drop isn't even the main killer. Long sessions also die from context exhaustion, rate limits, the machine sleeping, plain crashes. If you only watch the network you catch one failure mode and stay blind to the rest. Second, and this is the one that bit me hardest: liveness is not progress. An agent can be perfectly connected and alive while doing nothing useful, stuck in a loop, re-reading the same file, waiting on a prompt it will never get. A heartbeat that only proves the process is running gives you false confidence. What you actually want to watch is whether a new artifact or commit showed up in the last N minutes, a progress heartbeat rather than a network one, because that single check catches both the dead session and the alive-but-stuck one. So the real question is which problem you are actually trying to solve: do you need to know the instant it dies, or do you need to not lose work when it dies? Those are two different products, a monitor versus a checkpoint-and-resume harness, and the second one makes the first a lot less urgent.