The Claude Code desktop app on Windows stops responding, or crashes and won't come back. This time the culprit is ssh.exe, and if you use Claude Code to work on remote servers, this is probably the crash you're actually having.
The fix is to open up Task Manager. Find every ssh.exe, end task on each, and the app comes back. From a terminal:
tasklist /FI "IMAGENAME eq ssh.exe"
taskkill /F /IM ssh.exeHere's why it happens.
Windows doesn't clean up after the child
When Claude Code runs a shell command that calls ssh, it spawns an ssh.exe process and holds its output pipes open, waiting for the command to finish. On Linux or macOS, if the parent dies or the session restarts, the process group goes with it. Windows has no equivalent of POSIX process groups, so when the app window closes, restarts, or gets interrupted, the ssh.exe underneath it just keeps going.
Now it's an orphan. It still holds the pipe the app was reading from, and often the session lock under ~/.claude. When you relaunch, the app either waits on a handle that will never close or trips over the lock and gives up, and what you see is a window that opens blank, or never opens, or opens and freezes. It looks exactly like a crash.
If you've read the chrome-native-host.exe writeup, this is the same bug with a different process name. An orphan from the last session holds something the next session needs, and the failure gets treated as fatal instead of being cleaned up. That's three processes now (chrome-native-host.exe, cowork-svc.exe, ssh.exe), and the common fix is always the same: before Repair, before reinstall, open Task Manager and kill the leftovers.
The three ways ssh gets stuck
Once you know to look, the hung ssh.exe almost always got there one of three ways.
A remote prompt waiting for a keyboard that isn't there. The command hits a sudo password prompt, a host-key confirmation, an apt dialog asking about a config file. Stdin is attached but nothing is ever going to type into it, so ssh sits forever. Claude Code waits on ssh, you wait on Claude Code, and eventually you close the window, which orphans the process.
A background job that never let go. Someone runs ssh host 'nohup ./thing &' to kick off a long job and return immediately. But the remote process still has stdout and stderr pointed at the ssh connection, so ssh stays open waiting for output that keeps trickling in. The command "returns" from the remote side's point of view and never returns from yours.
Long foreground work you cancelled locally. A migration, a big rsync, a build. You hit Escape or close the tab because it's taking too long. The local ssh dies eventually, but the remote process keeps running, and depending on timing, the local client survives as an orphan holding the pipe. Worth knowing separately: cancelling on your end does nothing to the remote side. Whatever you started is still going.
Prevent it instead of killing it
Every one of those has a one-flag fix, and I've put them in my CLAUDE.md so Claude Code does them without being asked.
Wire stdin to nothing on every non-interactive remote command:
ssh -n -o BatchMode=yes host 'command'-n points stdin at null, so a prompt fails immediately instead of hanging. BatchMode=yes tells ssh to never ask for a password or passphrase and to fail if it would have to. Between them, the first trigger can't happen.
For fire-and-forget jobs, redirect all three streams so nothing stays attached to the connection:
ssh -n host 'nohup ./job.sh >/tmp/job.log 2>&1 </dev/null &'That closes the second trigger. Ssh returns the moment the job is launched, and the job writes to a log you can read later.
For the third, there's no flag, only a habit: if you're about to cancel a long remote command, understand that it keeps running over there, and check on it afterward rather than assuming it stopped.
And after any session that touched a server, before you close the app, run the tasklist line above. If an ssh.exe is sitting there with no live command behind it, kill it then, when it costs a second, instead of discovering it tomorrow when the app won't open.
The pattern, since it keeps repeating
I don't think Anthropic set out to build an app that gets held hostage by its own child processes. I think they built it on a platform where children die with their parents and then shipped it on one where they don't, and every process that spawns something long-lived is now a potential lock. Native messaging host, VM service, ssh client. There will be others.
Until the app handles its orphans, the one habit that fixes all of them is the same. It doesn't look like a crash from Task Manager. It looks like a list of things that should have exited and didn't, and ending them is faster than any Repair.
