Windows: running `claude -p` from a separate process kills the running interactive session and then hangs (2.1.200 & 2.1.201)

Open 💬 0 comments Opened Jul 4, 2026 by omelta

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=1 set 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 pwsh script via Python subprocess (shell=False), every 15 minutes:

``
claude -p "<prompt>" --tools "" --strict-mcp-config --disallowed-tools "*"
`
(no
--dangerously-skip-permissions`)

Repro

  1. Start an interactive session in a terminal: claude (or claude --continue).
  2. From a separate process (e.g. Task Scheduler → pwsh → python subprocess), run claude -p "Reply with OK" --tools "" --strict-mcp-config --disallowed-tools "*".
  3. Observed:
  • The interactive session's process dies (session disappears from the terminal).
  • The headless claude -p process 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 -p command 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.

View original on GitHub ↗