Sessions That Die Silently: The WSL-to-Windows Spawn Fix

Jul 19, 2026 · 4 min read

At 11:03 PM, a new remote-control session would register, print its join URL, and die a few seconds later.

That is a nasty failure shape. The phone showed a fresh session. The service had accepted it. The spawn script returned the URL it was supposed to return. Then the session changed to Disconnected, and any message posted from the phone sat behind a gray spinner forever.

I was building a one-tap path from a phone to a fresh Claude Code Remote Control session on a Windows development machine. The phone was deliberately thin. It connected by SSH, invoked one narrow script, received a join URL, and opened it. The actual workspace, credentials, project context, and interactive process all belonged on the PC.

The first version looked sensible:

phone -> Windows SSH -> WSL -> tmux -> claude.exe --remote-control

The phone ran this command over SSH:

wsl -d Ubuntu -- bash /mnt/g/Projects/workspace/admin/rc_spawn.sh

rc_spawn.sh created a detached tmux session, started claude.exe --remote-control, then captured the pane to pull out the join URL. The script was not failing before launch. It created a visible session, returned a real URL, and made the phone look successful. That made the failure easy to blame on the relay, the phone connection, or Remote Control itself.

A registered session is not a live process

The diagnostic path started with the symptom that mattered: the failure followed the launcher, not the phone.

The URL was printed before the session died. The phone could open it. A message from the app did not receive an ordinary error, it just spun. The process had made it far enough to announce itself, then vanished. Dropped phone connectivity was an attractive theory, but it could not explain a process dying moments after a local spawn. The detached tmux session was another attractive theory because it was supposed to outlive the SSH command that created it.

It did outlive that command. The Windows child did not.

WSL interop has a lifetime boundary that tmux does not erase. When a Linux process starts a Windows executable, the Windows executable remains tied to the wsl.exe client that launched it. In this case, tmux owned a Linux shell, but that shell had launched claude.exe across the WSL boundary. Once the launcher-side WSL client disconnected, Windows cleaned up the interop child. tmux stayed alive, the URL remained in its scrollback, and the actual Remote Control process was gone.

That explained the misleading combination: a successful registration, a valid URL, and a dead session. We confirmed the fix live from the phone after changing the process tree, not after adding retries or another health check.

The rejected fixes were all attached to the wrong boundary

I considered three simpler repairs before changing the chain.

The first was to keep the direct tmux -> claude.exe design and make the WSL side more persistent. That lost because the problem was not whether the Linux multiplexer survived. It was that the Windows process was an interop child. A longer-lived tmux session cannot adopt a process that Windows tears down with its WSL launcher.

The second was to detach the Windows command with redirected standard input and output. That ran into a separate constraint. claude --remote-control needs an interactive terminal. Give it pipes, as redirected process launches do, and it falls into --print behavior or never initializes a Remote Control session. A plain SSH command without -t has the same problem. It can run a command, but it does not provide the terminal the program expects.

The third was a WSL keepalive. That treated the symptom as a distro-lifetime issue. It was not necessary once the session had a real owner on the Windows side. In the final design, the Ubuntu distro stays up while tmux runs even with zero attached WSL clients. The important relationship is the one between the durable Linux process and the native Windows terminal.

The SSH hop is the ownership transfer

The working chain adds one hop that initially felt redundant:

tmux on Linux
  -> Linux SSH client
    -> Windows sshd
      -> rc_native.ps1
        -> claude.exe --remote-control in a ConPTY

tmux now owns a Linux SSH client and keeps that connection open. Windows SSH receives the connection, starts a native PowerShell entry point, and gives Claude Code a real ConPTY terminal. The program is no longer a Windows executable launched through WSL interop. It is a native Windows process launched by Windows SSH, with an interactive terminal and a parent connection whose lifetime tmux owns.

The spawner still does two small jobs. It creates a named tmux session such as rc-<stamp>, then uses tmux capture-pane to scrape the join URL. That is enough for the phone. The session can survive the original launcher exiting, an SSH drop, and the phone locking. If I need to inspect or clean one up, tmux ls and tmux kill-session -t <name> are the control surface.

The important correction was not “use SSH instead of WSL.” WSL is still in the path, and tmux is still doing useful work. The correction was to stop asking WSL to be the parent of a Windows interactive process that had to outlive its launcher.

That distinction is now a hard rule in our cross-platform automation: when the child must outlive the handoff, make sure the component that owns the child actually lives on the child’s operating system.

AI Skills

Use this lesson with the AI assistant you already use

A remote-control session launched from WSL into Windows would register successfully, print a real join URL, then die within seconds, because Windows tears down an interop-launched child the moment the WSL client that started it disconnects, regardless of what the Linux-side process supervisor believes it still owns.

Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.

Optional: for a visual report and saved memory, run /dxdev first. Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.

dxdev LESSON · paste into your AI coding agent
LESSON: A process launched across an OS interop boundary is tied to the launcher that started it, not to whatever supervisor on the other side appears to own it
SOURCE: dxdev.com/blog/2026-08-22_wsl-session-spawn-ssh-reroute
WHAT HAPPENED: A remote-control session spawned by having a Linux shell under WSL start a persistent process manager, which in turn launched an interactive Windows executable across the WSL interop boundary, would register successfully and print a real join URL, then die within seconds, with the Linux-side process manager staying alive and the URL sitting in its scrollback the whole time. That maximally misleading signature, apparent success followed by silent disappearance, pointed suspicion toward the phone connection or the relay service rather than the actual cause: Windows ties an interop-launched child process's lifetime to the WSL client that launched it, and tears that child down the moment the launching client disconnects, no matter what Linux-side supervisor believes it still owns the process. Three simpler fixes were tried and rejected: making the WSL side more persistent, since the Windows process, not the Linux side, was the one dying; redirecting standard input and output to detach the Windows command, which broke because the interactive program required a real terminal and fell back to non-interactive behavior without one; and a WSL distro keepalive, which addressed the wrong lifetime entirely. The actual fix added a genuine ownership transfer: the Linux-side supervisor keeps open a persistent SSH connection, which lets Windows's own SSH service spawn the interactive process natively on Windows with a real terminal, no longer as a WSL interop child at all.
THE RULE: When a process must outlive the mechanism that spawned it, the component responsible for keeping it alive has to actually run on the same operating system as that process; a supervisor on one side of an interop boundary cannot keep a process on the other side alive no matter how persistent it is, because the operating system ties that child's lifetime to the launching client, not to whatever the other side believes it is supervising.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any cross-platform process spawn, such as WSL to Windows or container to host, where a long-lived supervisor on one side is assumed to keep a process on the other side alive, without confirming that assumption against how that operating system actually manages the child's lifetime.
      2. Any registered or returned confirmation, such as a URL, being treated as proof of a live, ongoing process, when the actual liveness has not been separately confirmed after the initial handoff completes.
      3. A process requiring a genuine interactive terminal being launched with redirected, non-interactive input and output as a detachment strategy, without first checking the program's documented behavior under non-interactive input.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.

Send us what your agent found →

Prefer to talk it through first? See the AI workflow assessment or get in touch.

Lesson: A process launched across an OS interop boundary is tied to the launcher that started it, not to whatever supervisor on the other side appears to own it

Choose your next level of detail

Want the practical version?

How AI Helps starts with the work problem, what improves, and where human judgment still matters.

See how AI helps Start a conversation