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

Real, not just your setup. I come at it from the other side: an agent batch of mine fires on a schedule every morning with nobody watching it start, so "dead or thinking" is the normal state here, not the exception.

The thread has handed you two levers - detect that it died (heartbeat, done-marker, absence-as-signal) and resume from where it died (checkpoints, small stages) - plus a few that go at the connection itself (tmux on another box, mosh, a newer CLI). There's a third category nobody has raised, and up front: it does not fix your case. A run that refuses to start.

The check I nearly cut as over-engineering is the one that makes my runner decline the job. The log line is blunt about it - credentials expire in 19 minutes, so the entire run gets skipped rather than leave half-finished work behind. It checked how much life it had before touching anything, decided that wasn't a full pass, and produced nothing on purpose.

That does nothing for a Wi-Fi blip, and that's the useful part. It splits dead runs into two classes: the ones the run could have known about at second zero (auth expiry, quota, a lock the previous run left behind) and the ones it couldn't (yours). Only the first class is preventable. For the second, detection really is the whole lever, and the question narrows to how fast you want to know.

Worth separating before you build, because the two look identical from the terminal and want opposite fixes. A single alarm covering both is how you end up still checking on runs: it tells you a half-state exists, not whether it should have existed. So the call I'd make is to take your last handful of dead runs and sort them into those two piles. If they're all connection drops, build the detector and stop there - that's your answer. If the avoidable pile isn't empty, an alarm is the wrong build for those, because they shouldn't have started.

Yeah, real pain. I run long agent sessions over SSH, and tmux fixed most of it -- the session survives a dropped connection and I just reattach. For the silent-hang case I have the agent touch a heartbeat file every few minutes, and a cron pings me if it goes stale.

I’ve run into a similar problem while using coding agents for longer tasks. For me, the most useful safeguard has been asking the agent to work in small, verifiable stages and keep a persistent checklist of what has actually been completed.

That way, if the connection drops, I can compare the repository state with the checklist instead of restarting the entire task or trusting that everything finished correctly. Running tests after every important stage also makes partial changes much easier to detect.

A notification would still be useful, but I think checkpointing and resumability solve the more dangerous problem: not knowing what state the project was left in.

Would your solution focus mainly on detecting the stopped session, or also help the agent resume safely from its last completed step?

Same shared pain, and the fix that stuck for us was not about keeping the connection alive either, it was about never trusting the agent's own report that a step succeeded. We had a case this week where an automated fix looked completely fine, the code was live, the deploy logs were clean, no error anywhere, and it still failed silently in production because the fix was real but pointed at the wrong asset. Nothing in the process ever complained. The only thing that caught it was going and looking at the actual rendered result with our own eyes instead of trusting the green checkmarks. Now any unattended run has to end with a real visual or output check on the live thing, not just a log that says it ran.

Shared pain here — and after months of running agents unattended (a good chunk of our company ops runs on scheduled agent sessions), the fix that stuck for us wasn't keeping sessions alive. It was giving up on long-lived sessions entirely.

We flipped to short, resumable execution windows: the agent wakes on a timer or an event, reads durable state from a task tracker (not from its own context), does one bounded chunk, writes status + a comment back to the tracker, and exits. A death is then always visible as "no update since 14:07" on a ticket instead of a quiet terminal — and recovery is nearly free, because the next window cold-starts from the tracker rather than from a lost session.

Two lessons that took real losses to learn:

1. Absence of errors is not progress. We once burned an hour on a "my config change does nothing" mystery because a stale process was silently still serving on the same port — same failure class as your dead session: the system looked alive because nothing said otherwise. Now every window ends by verifying observed state (did the artifact actually change?) before reporting done.

2. The terminal is the wrong source of truth. If status only lives in the live session, every disconnect is data loss. Once status lives outside the process, the wifi drop stops mattering at all.

+1 to vitsamin: if you build for this, the valuable signal is "it stopped 20 minutes ago and nobody told you," not reconnection.

Oh man, the silent death is the worst. You come back 30 mins later expecting a finished feature and the terminal is just dead.

But honestly, this is why I don't rely on AI for the foundational stuff. I manually built and tested all the boilerplate for my Next.js template (Nexus) so I don't have to worry about an agent dying mid-task while setting up auth or admin panels. I use AI to help me debug or write small functions, but the core architecture and the 626 tests are mine. I just don't trust it with the important parts yet lol.

Have you tried running your agents inside a tmux session? Or does the agent crash itself when the network drops?

This is one of those failure modes that is easy to miss until it costs you real work. Curious what your recovery process looks like now, do you checkpoint manually, or has it just made you paranoid about long running tasks in general?

Yes — this is a shared pain. I've had Claude Code drop mid-refactor and come back to a half-written file and a broken build. The silent failure is worse than an error because you lose time and trust.

One thing I started doing: wrapping long agent tasks in a simple retry/heartbeat script that pings a local endpoint every 30s. If the agent goes quiet, I get a notification. Not elegant, but it beats discovering a dead session an hour later.

On a related note — if you're shipping what the agent builds, the codebase complexity compounds fast (especially with AI-generated code). We built SecondRead to audit those codebases for non-technical founders: security holes, cost sinks, things that break at scale. Happy to run a free beta audit if you ever want a second pair of eyes on what your agent produced.

I havent tried it yet but what i noticed is sometimes ai can just break the momentum especially if you are trying to ask them a repetitive task, and after a few repeition theyll break the cycle so you need to inform them again on what to exactly do which is a bit of a hassle

Not just you, and the annoying part is that it's not really a network bug, it's a missing failure signal. A dropped session that ends quietly looks identical to a session that finished, so you can't tell the difference by looking at a terminal. Cheapest fix that worked for me: run the agent inside tmux so a local disconnect can't kill it, and have the task itself write a "done" marker file as its last step. Then a dumb cron check on the marker's timestamp tells you if it stalled, no heartbeat plumbing needed. If you're thinking about building for this, I'd chase the "silently stopped 20 minutes ago and nobody told me" part rather than reconnection — that's the bit that actually costs time.

What I'd want here isn't another connectivity ping. I'd want a state change I can trust. A heartbeat helps, but I'd also save a checkpoint after each meaningful step. I'd send the completion notice only after verifying the final artifact. Then the next step is clear: resume from the checkpoint or review the finished result.

This is exactly why we built retry logic into our API platform — connection drops during long-running API calls are the #1 source of silent failures. At GoldBean API, we use a checkpoint-and-resume pattern: every call gets a transaction ID, and if the connection drops mid-stream, the client can resume from the last checkpoint instead of starting over. The real fix isn't just better reconnection — it's making 'no completion signal' a first-class failure state that the system handles automatically.

Happened to me too — the session dies silently and you only find out when you come back. What helped: run agents with a heartbeat log (append a line every N minutes) and check it before trusting the result. No recent heartbeat = re-run from the last checkpoint instead of assuming it finished.

Not just you — I hit exactly this on an older Claude Code build (around the Opus 4.7 era): Wi-Fi drops for a few seconds, the session dies silently, no error, and I'd only notice 20 minutes later. After updating the CLI (and moving to 4.8) it hasn't happened again, so I'd check your Claude Code version first — the newer builds reconnect through short network blips.

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.

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.

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.

The dangerous part seems less like the disconnect itself and more like losing confidence about the final state. A useful pattern could be a lightweight heartbeat plus explicit checkpoints: have the agent write the current step, expected files, and last test result to a small state file, then emit an alert if the heartbeat stops. On reconnect, it can inspect that state and the repository diff before resuming instead of blindly repeating work. I’d also treat “waiting for input” as a separate status from “crashed,” since the recovery action is different.

"This hit close to home — we run a multi-stage LangGraph pipeline (research → synthesis → multi-round review) and the scariest failures aren't crashes, they're the ones where a stage looks 'done' but nothing actually verifies it finished cleanly. Treating 'no completion signal' as failure-by-default instead of assuming it's still running would've saved us a few silent partial runs."