TL;DR. Windows runs SSH sessions in a separate, invisible place called Session 0. Terminal sessions you start over SSH keep running there, but your desktop can't see them and will tell you they're stopped. The fix is to SSH to the machine from itself. Also: a recent herdr update broke multi-line paste, and the bug reports blame the wrong terminal.
I created a terminal session on my Windows desktop from a tablet, detached, walked to the desk, and got this:
PS C:\Users\joehahn> herdr --session vstplugins
herdr: Access is denied. (os error 5)
The session was fine. Fifteen workspaces, fourteen live Claude Code agents, all idle and waiting. herdr session list told me it was stopped. It was not stopped. It was in a place my desktop couldn't look.
Session 0, and why you've never heard of it
Windows keeps services separate from your desktop. Services live in Session 0. You live in Session 1. It's a security boundary from the Vista era and it's entirely reasonable.
Windows OpenSSH lands in Session 0.
So when I started a terminal session from my tablet over SSH, it ran there. It survived my disconnect, exactly as documented. What isn't documented is that my desktop can't see it, and says so with confidence.
The same command, two answers
Same machine, same build, same minute. Only the Windows session differs.
- apps: from the desktop: stopped, over SSH: running
- vstplugins: from the desktop: stopped, over SSH: running
- four others: running from both
Session 0 sees everything. Session 1 sees only its own. The better-informed view is the one you're least likely to be using.
What actually caught it was simpler than the process table. The socket timestamps disagreed with the status:
Get-Item "$env:APPDATA\herdr\sessions\<name>\herdr.sock" | Select LastWriteTime
The two sessions reported stopped had been used seven hours more recently than the three reported running. When a status field disagrees with a filesystem timestamp, trust the timestamp.
The fix is a loopback SSH
You get a Session 0 shell by SSHing to a machine from itself.
ssh smoreo # from smoreo. lands in Session 0.
herdr --session vstplugins
All fourteen agents attached, intact. It feels absurd. SSH to localhost to reach a process running as you, on your own machine. But the boundary is real and this is the door through it.
The rule that falls out: start a session in the context you'll normally use it from. A tablet-over-SSH session is usable only over SSH. If you want it both ways, start it on the desktop and attach to it from the tablet, not the reverse.
The same machine is two machines
WSL quietly doubles everything.
My desktop runs Ubuntu under WSL2. That Ubuntu is its own Tailscale node, with its own address, its own terminal multiplexer, its own Claude. The two installs share nothing. Different versions, different sockets, different session lists, and both are correct.
This is fine once you know it. It is confusing when you're wondering why the session you just made isn't there.
The paste bug, and a correction to the record
Partway through, multi-line pastes started submitting line by line. One paste, one message per line. A pasted job description became thirty separate messages.
That's bracketed paste failing. When it works, the terminal wraps a paste in invisible markers so the receiving app treats it as one blob. Without them, every newline is just an Enter keypress, and any multi-line editor submits on each one.
It was a regression, and several issues were filed. Here's the part worth publishing: several of those reports characterize it as affecting conhost, the legacy Windows console. That was not my experience. I hit it in Windows Terminal, on PowerShell 7. If you skipped those issues because you assumed Windows Terminal was unaffected, look again.
Switching to the preview channel fixed it.
What I'd check first next time
The username, before the key. Across my machines my accounts are joehahn, jofurky, and user0. Connecting as the wrong one gives you Permission denied (publickey), which reads as a key problem and sends you off regenerating keys. It was in my own notes the whole time.
Status fields that can't fail loudly. herdr session list isn't lying. It genuinely can't see across the boundary. But "I can't determine this" and "it is not running" got collapsed into one answer, and the collapsed answer invites you to start a second server on the same socket.
Honest limits. This is n=1, on one Windows 11 box, with one WSL distro. I haven't tested whether Session 0 behaves differently under a service-based SSH setup, or whether other multiplexers hit it the same way. I'd expect any that use a socket to.
And the thing I still don't have an answer for: none of this is discoverable from the tools. Every boundary here was found by noticing a number that didn't match a story. A socket newer than a stopped session. A version string that differed inside WSL. The tools report their own view confidently and give you no hint that another view exists.