Windows: SessionStart hooks cause input freeze on second concurrent CLI instance (v2.1.37)

Resolved 💬 3 comments Opened Feb 9, 2026 by eclinicalguru Closed Feb 12, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

On Windows 11 (PowerShell / Windows Terminal), launching a second Claude Code CLI instance in the same project directory causes the terminal to become completely unresponsive to keyboard input when any SessionStart hook is configured.

  • The first instance works correctly
  • The second instance renders the UI normally but does not accept keystrokes
  • The hook completes successfully in all cases
  • Debug logs confirm [REPL:mount] REPL mounted, disabled=false — Claude Code believes input is ready, but the terminal does not deliver keystrokes

What Should Happen?

The second CLI instance should accept keyboard input normally, identical to the first instance. Multiple concurrent instances with SessionStart hooks should all be interactive.

Error Messages/Logs

All frozen sessions show identical debug log patterns:
[DEBUG] Hook SessionStart:startup (SessionStart) success: {...}
[DEBUG] [render] initLayout starting
[DEBUG] [render] initLayout complete
[DEBUG] [REPL:mount] REPL mounted, disabled=false
[DEBUG] [render] first ink render: 4065ms since process start
After REPL mount, frozen sessions show only periodic 30-minute update checks. No UserPromptSubmit events ever fire. Frozen sessions also show an extra initLayout cycle (3 total) compared to working single-instance sessions (2 total)

Steps to Reproduce

  1. Create a minimal hook script (e.g., .claude/hooks/minimal-hook.js):
// Drain stdin and exit — does no actual work
process.stdin.resume();
process.stdin.on('end', () => process.exit(0));
  1. Create (or add to) .claude/settings.local.json:

{
"hooks": {
"SessionStart": [
{
"hooks": [
{
"type": "command",
"command": "node .claude/hooks/minimal-hook.js",
"timeout": 10
}
]
}
]
}
}

  1. Open Windows Terminal and run claude --debug from the project directory
  2. Confirm input works (type any prompt) — this succeeds
  3. Open a new tab in Windows Terminal
  4. cd to the same project directory
  5. Run claude --debug
  6. Expected: UI renders, input accepts keystrokes
  7. Actual: UI renders, cursor visible, but typing produces no characters. Input is permanently frozen

Control: Setting "hooks": {} allows both concurrent instances to accept input normally.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.37

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Systematic Isolation Testing

Tested across 7 debug sessions with controlled isolation:

| Condition | Input Works? | Sessions Tested |
|-----------|-------------|-----------------|
| Single instance + SessionStart hook | Yes | 2 |
| Second concurrent instance + SessionStart hook | No | 4 |
| Any instance, no hooks configured ("hooks": {}) | Yes | 1 |
| Minimal hook (drain stdin + exit, no work) | No (concurrent) | 1 |

The minimal hook test is decisive: even a hook that does nothing except drain stdin and exit causes the freeze when a second instance is running. This rules out hook code as the cause.

Control Test

Setting "hooks": {} in settings.local.json allows both concurrent instances to accept input normally. The hook configuration is the sole differentiator.

Debug Log Pattern (frozen sessions)

Frozen sessions show an extra initLayout cycle (3 total) compared to working single-instance sessions (2 total), possibly triggered by file-watcher cross-talk when concurrent instances write to ~/.claude.json:

Working (single instance):

  • initLayout x2, REPL mount, first ink render: 4849ms

Frozen (concurrent):

  • initLayout x3, REPL mount, first ink render: 4065ms
  • Extra initLayout appears between first render and hook execution

Workaround

Adding "async": true to the SessionStart hook prevents the freeze, but breaks the use case of synchronous session-boundary validation (where the hook result must be available before the first user prompt).

Single-instance discipline (only one CLI per project directory) also avoids the issue.

Possibly Related

  • #22906 — Keyboard input not working (v2.1.30+)
  • #22970 — TUI completely freezes on Windows startup

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗