[BUG] CLI repeatedly self-spawns sessions with prompt "Code" every ~12s, independent of VSCode

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?

Summary

Starting 2026-07-01, the Claude Code CLI (claude.exe) has been repeatedly and automatically spawning new sessions in my workspace C:\Users\Utente\Claude\Claude Code, roughly once every 12-15 seconds, continuously, for hours. Each spawned session sends a single fixed prompt — the literal string "Code" — receives a normal assistant reply, then triggers its Stop hooks, and the cycle repeats indefinitely. Each iteration is a fully functional session: it loads project context (skills, agents, MCP servers) and spins up all project MCP servers (fatture-in-cloud, leanus, sqlcl-studiocg), so this is not a cheap no-op — it consumes real API calls/tokens and disk space (session transcripts).

The loop is not tied to any VSCode window: it continued for several minutes after all VSCode windows were closed, and only stopped when the underlying claude.exe "Code" process tree was forcibly killed.

Environment

• OS: Windows 10.0.26200.6899 (Windows 11 Pro)
• Claude Code CLI (global, C:\Users\Utente\.local\bin\claude.exe): version 2.1.198
• Claude Code VSCode extension (anthropic.claude-code): version 2.1.198 (was 2.1.197 on 2026-07-01)
• VSCode: 1.127.0
• Workspace has .claude/settings.local.json with a Stop hook, several enabled MCP servers, and the hookify plugin installed

Observed pattern

• Every affected session file has "entrypoint":"claude-vscode", cwd = the workspace root, and its very first user message is the literal string "Code" (preceded by a queue-operation: enqueue/dequeue pair with the same content).
• Process command line for each spawn: "C:\Users\Utente\.local\bin\claude.exe" Code — note this uses the global CLI binary, not the VSCode extension's bundled copy (...\extensions\anthropic.claude-code-x.x.x\resources\native-binary\claude.exe), which is what the extension itself uses for legitimate --resume/interactive spawns.
• Each such process, when it finishes, launches child MCP server processes (Python mcp-fatture-in-cloud/server.py, 06.05-mcp-leanus/server.py, sqlcl-mcp.sh) exactly as a normal interactive session would.

Timeline / evidence

• 2026-07-01: ~995 such sessions created across 5 bursts (07:xx, 11:xx, 13:xx, 14:xx, 16:xx), sustained rate ~10-12/minute. VSCode extension-host logs for that window were rotated out before I could inspect them.
• 2026-07-02: Reproduced live. I resumed an existing chat in the workspace at 10:03:55 and opened a new chat at 10:04:29. The flood began independently at 10:10:44 and continued at a steady ~12s cadence until I killed all claude.exe processes at 10:41:12 — roughly 150 spawned sessions in that window alone.
• Today's VSCode extension log (Claude VSCode.log, not rotated) shows only 7 legitimate Spawning Claude with SDK query function... events all day, all using the extension's bundled binary with correct --resume/permission-mode flags. None of them correspond to the flood. This rules out the extension's own spawn logic as the direct cause.
• The flood continued for several minutes after closing all VSCode windows (taskkill /IM Code.exe), proving it is independent of any VSCode process once started.
• It stopped immediately and completely (verified over a subsequent 2-minute clean monitoring window) once every claude.exe process with "Code" in its command line (and children) was force-killed.

Ruled out

• Windows Scheduled Tasks: only one relevant task exists (Sync Esterno - Claude), a daily 19:00 robocopy job — timing doesn't match, action is a .bat with no reference to claude.exe.
• Claude Code hooks: project has one Stop hook (notify-done.ps1, a Windows balloon-notification script) — inspected full source; it only shows a toast notification and exits, never invokes claude.
• hookify plugin: also registers UserPromptSubmit and Stop hooks (hooks/stop.py) but they are currently broken — every invocation fails with ModuleNotFoundError: No module named 'hookify'. Inspected the source: it catches the ImportError, prints a JSON error message, and exits 0 without ever calling claude. (Real, separate, reproducible bug — see below — but not the cause of the flood.)
• Batch scripts in the project: matched a text search only because they mention "Claude Code" as a string; none invoke the CLI.
• Startup folder / AutoHotkey / registry Run keys: nothing relevant found.
• Process-tree tracing (Get-CimInstance Win32_Process) repeatedly showed the parent of each flood claude.exe as a very recently-created powershell.exe running the notify-done.ps1 balloon-tip script content — but that script's source clearly contains no claude invocation, so this is most likely PID-reuse noise from very high process churn, not a real causal link. Could not identify the true spawning process before it exited, even with ~200-300ms polling.

Impact

• ~995 sessions on 2026-07-01, ~150+ more on 2026-07-02 before being stopped — each a real, billable Claude Code turn with full MCP server startup.
• Disk: >1200 session transcript files accumulated in ~/.claude/projects/....
• I had deleted the ghost sessions from the VSCode session list on 2026-07-01, but the underlying .jsonl files were never actually removed from disk — suggesting the "delete" UI action only clears a cached/displayed list, not the persisted session files.

Secondary bug (separate, also worth fixing)

The hookify plugin's UserPromptSubmit and Stop hooks fail on every single prompt/turn in this environment with:
Hookify import error: No module named 'hookify'
Source: hooks/stop.py in the hookify plugin (sys.path manipulation based on CLAUDE_PLUGIN_ROOT env var doesn't result in an importable hookify package). Fails gracefully (exit 0) so doesn't block anything, but adds ~1.3s latency and a hook_system_message to every turn.

Suggested next steps for investigation

• Since this is not reproducible from any inspectable config/script, the likely location is native/bundled logic in the claude.exe CLI binary itself (session resume, hook-retry, or queue-replay logic) — possibly related to the queue-operation: enqueue/dequeue mechanism visible at the start of every affected session's transcript, or to how the Stop hook's response is interpreted when a hook exits successfully.
• A debug/verbose trace of the parent process that issues the claude.exe Code invocation, captured with something faster than WMI polling (e.g. Sysinternals Process Monitor filtered on claude.exe process creation), would help catch the true parent before it exits.

What Should Happen?

non dovrebbe aprire in autonomia una chat

Error Messages/Logs

Steps to Reproduce

quando apro una chat e scrivo un prompt iniziano le sessioni fantasma

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.198

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_