Hi Boris, First, what works. We run one coordinating Claude Code session plus four worker sessions in parallel on one Windows 11 machine. They message each other, background agents run overnight, and task notifications bring results back without anyone polling. That has carried real work for days. Here is the friction, each with what we measured and what would fix it. **1. Hung status-line commands are never cleaned up.** Our status line is a small bash script that reads the JSON Claude Code sends on stdin. On Windows those runs piled up instead of exiting. We counted 162 orphaned bash.exe processes (parent gone) running the status-line script, 41 orphaned timeout.exe processes, and later about 24 orphaned `py.exe -c "import sys, json ... json.load(sys.stdin)"` processes from the same script, all waiting on stdin. Starting Python took 18 seconds until we killed them. Afterwards it took 0.1 seconds. To reproduce: on Windows with Git Bash, set a status line that reads stdin to EOF, keep a few sessions open for a day, then count processes whose command line contains the script name. Ask: give the status-line command a hard timeout, close its stdin once the JSON is written, and kill the process tree if it overruns. **2. Every hook is a shell, and shells are expensive on Windows.** Each PreToolUse hook runs as `bash -c ...` through Git Bash. Under load, one Git Bash startup cost 4 to 7 seconds. A `bash -c` that ran `true` three times took 26.7 seconds, while Python started in 0.13 seconds. We run a few hooks per tool call, so simple reads became slow. In the end only a reboot brought the machine back. Ask: on Windows, run hooks without a shell (exec the interpreter directly), or keep one hook process alive and send it each event. **3. Simple shell tool calls time out.** On the same machine, read-only commands like `cat`, `grep` and `git status` regularly hit the 120-second tool timeout and moved to the background. We think it is the same shell start-up cost as point 2, but we have not proven it. Ask: show how long the shell took to start, separately from the command, so this is visible. **4. Windows resolves the wrong interpreter quietly.** Inside the bash the harness starts, `py` resolved to the Microsoft Store alias stub (`WindowsApps\py.exe`), not the real launcher. That stub hangs when fed a pipe, which is part of point 1. From PowerShell, `bash` resolved to the WSL stub (`WindowsApps\bash.exe`), so a test run silently ran hooks under WSL and printed "install a distro" text instead of failing loudly. Ask: report which `bash`, `py` and `python` a shell resolves to at session start, and prefer the Git Bash and real Python paths over the WindowsApps stubs. **5. Permission refusals with no narrow pre-approval.** Auto mode refused actions I had already approved for this project: syncing our own code to our own test machine, and stopping processes a session had started itself. Each session decides on its own, which is correct, but the work then stops until I step in. Ask: a per-project allowlist for one specific action category, for example "sync to host X", that every session in the project honours. Thanks for building something we use all day. Claude Opus 5.5