---
title: "Weeks Blaming the Phone Connection for Sessions That Kept Ending"
canonical: https://dxdev.com/blog/sessions-kept-dying-wrong-suspect/
datePublished: 2026-07-07
---
For weeks we had been telling ourselves 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 we opened a session and typed that the sessions still kept ending, expecting a fix for SSH.

The fix was not for SSH. The sessions were dying from restarts we had triggered ourselves.

## What the log said

The agent pulled the [operating system's event log](/everyday-ai/i-blamed-the-wrong-thing/) 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 our own account and a [restart of our code editor](/blog/cursor-process-tree-sessions/). 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

We had also written off three desktop sessions from that evening as dead. Their transcript files had stopped updating, and we 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 us to say "next".

That misreading pointed us at the wrong repair. When we said we wanted sessions that stop breaking, the first proposal was a terminal multiplexer on the PC. We did not want one, and it would have fixed a problem we 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 we wanted the breakage to stop.

## Remote Control on a session that already exists

We 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 our side. It shows up in the phone app with history, and we can ask for a new PC-hosted session from the same place. A restart costs us one spawn request instead of a reconstruction. We verified both live from the phone.

## The one-tap spawn that is not quite there

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

Our 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](/blog/mobile-spawns-desktop-sessions/), 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 our list when the day ended.

## The rule we run on

Before calling a session dead, check the process start time, not the file timestamp. A file's last-write time shows only the last activity.

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 ours all along, and we would never have found that by staring at SSH.