Windows: running `claude -p` from a separate process kills the running interactive session and then hangs (2.1.200 & 2.1.201)
Summary
When a separate process (Windows Task Scheduler job) runs claude -p "..." while an interactive Claude Code session is running in a terminal, the interactive session is killed and the headless claude -p invocation itself hangs (no output, observed hanging for ~1 hour). Reproduced on 2.1.200 and 2.1.201 (Windows native build).
Environment
- OS: Windows 11 Home 10.0.26200
- Claude Code: 2.1.200 and 2.1.201, native installer (
%USERPROFILE%\.local\bin\claude.exe, versions under%USERPROFILE%\.local\share\claude\versions) DISABLE_AUTOUPDATER=1set at both User and Machine scope (this is not the autoupdater session-kill issue — the versions directory was untouched at the time of the kill; no update occurred)- The headless call is made from a scheduled
pwshscript via Pythonsubprocess(shell=False), every 15 minutes:
```
claude -p "<prompt>" --tools "" --strict-mcp-config --disallowed-tools "*"
--dangerously-skip-permissions`)
(no
Repro
- Start an interactive session in a terminal:
claude(orclaude --continue). - From a separate process (e.g. Task Scheduler → pwsh → python subprocess), run
claude -p "Reply with OK" --tools "" --strict-mcp-config --disallowed-tools "*". - Observed:
- The interactive session's process dies (session disappears from the terminal).
- The headless
claude -pprocess hangs — no stdout, still holding our job lock 45+ minutes later.
Timeline from our logs (2026-07-05 JST, on 2.1.201):
[01:00:06] [B] intent_compile start <- claude -p launched by scheduled job
(log goes silent; the interactive session running at that moment died here)
[01:15:05] Lock held (pid=16804, age=15min) <- claude -p still hanging
[01:45:05] Lock held (pid=16804, age=45min)
[02:00:05] Stale lock — taking over
[02:00:56] claude -p completed normally in ~50s <- works fine once no interactive session exists
Counter-observations
- Running the same
claude -pcommand from inside the interactive session (as a child process via the Bash tool) works fine and does not kill the session. - Running the headless command when no interactive session exists completes normally in ~50 seconds.
- So the failure requires: separate-process
claude -p+ a concurrently running interactive session.
This looks like some shared per-user state (lock file / IPC / session registry?) between independent CLI instances where the headless instance terminates the interactive one and then deadlocks.
Workaround
We patched our scheduler to skip the headless call whenever a non-Electron claude process is running, which avoids the kill — but it means headless and interactive use cannot coexist.