My Sessions Kept Dying and I Blamed the Wrong Thing

For weeks I had been telling myself the phone connection was the problem. Lock the screen, switch from wifi to cell, and the SSH session drops and takes the agent session with it. So I opened a session and typed “my sessions still keep ending”, expecting a fix for SSH.

The fix was not for SSH. The sessions were dying from restarts I had triggered myself.

What the log said

The agent pulled the operating system’s event log for recent days and lined it up against the session transcripts. Two things came out.

The sessions that ran overnight with no phone attached had survived the whole night. On Windows OpenSSH the agent’s child process keeps running after the connection drops, so SSH drops were never killing anything.

The killers were a restart of the PC from my own account and a restart of my code editor. Everything hosted in one of that editor’s terminals died together. Deaths came in clusters at a single moment, which is what a shared parent dying looks like. A crash would have been scattered.

Reading a file timestamp as a death certificate

I had also written off three desktop sessions from that evening as dead. Their transcript files had stopped updating, and I read that as an ending. The agent checked the process start times instead. All three processes were still running. The last-write time only marks the last activity. They were idle, one of them mid-walkthrough waiting for me to say “next”.

That misreading pointed me at the wrong repair. When I said I wanted sessions that stop breaking, the first proposal was a terminal multiplexer on the PC. I did not want a multiplexer, and it would have fixed a problem I did not have, since SSH drops were not the cause. Resuming a killed session from its working directory does bring it back with full context, but that is a recovery trick, and I wanted the breakage to stop.

Remote Control on a session that already exists

I asked a narrow question: is there an in-session command that turns on Remote Control for a session that is already running, and does the phone see the old history? Yes to both. /remote-control, or /rc for short, lifts the running session into the Claude app on the phone with its full conversation history.

The catch is that Remote Control does not move the process to the cloud. It keeps running locally, so a PC reboot still kills it. What changed is where the session lives from my side. It shows up in the phone app with history, and I can ask for a new PC-hosted session from the same place. A restart costs me one spawn request instead of a reconstruction. I verified both live from the phone.

The one-tap spawn that is not quite there

I wanted the spawn to be one tap. That evening I wrote a small shell script that starts a fresh remote-control session on the PC and hands back a join URL, and I ran it live twice from the phone. Both times the session showed up in the app.

My plan for the tap itself was an iOS Shortcut that connects over SSH and runs the script. Shortcuts turned out to be blocked from doing that on the phone side. The working path is an SSH key with a forced command, so the only thing that key can do is run the spawn script. The server side is wired and tested. Setting up the key on the phone was still on my list when the day ended.

The rule I run on

Before calling a session dead, check the process start time, not the file timestamp. Before restarting the PC or the editor, assume everything hosted there dies at once, and know that /rc and resuming from the same directory are how it comes back.

The restarts were mine all along, and I would never have found that by staring at SSH.

dxdev LESSON · paste into your AI coding agent
LESSON: Find Out What Killed the Session Before You Pick the Repair
SOURCE: dxdev.com/blog/2026-07-07_sessions-kept-dying-wrong-suspect
WHAT HAPPENED: Long-running agent sessions kept ending. I assumed SSH drops from my phone were killing them and asked for a fix for that. The operating system's event log and the process start times showed something else. Sessions that ran overnight with no phone attached survived fine, because the child process keeps running after an SSH disconnect. What killed them were restarts I triggered myself, of the PC and of the editor that hosted the terminals, and every session hosted there died at the same moment. I had also written off three sessions as dead because their transcript files had stopped updating, when the processes were still running and only idle. The first repair proposed, a terminal multiplexer, would have fixed a problem I did not have.
THE RULE: Before calling a session dead, check the process start time, not the file's last-write time. Before choosing a repair, identify the actual killer from the system's own records. Deaths that cluster at one timestamp mean a shared parent died.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any liveness check that infers a process is dead from a file timestamp instead of asking the process table.
  2. Any long-running job hosted inside a terminal or editor process that is restarted by hand or by updates.
  3. Any recovery plan chosen before the actual cause of failure was confirmed from logs.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.