[BUG] The window terminated unexpectedly (reason: 'killed', code: '9')

This bug ist very costful because resuming the session after Window reload consumes about 5 € with Opus and 20 € with Fable.

Further problem repeatedly occuring with latest version is "Claude Code stopped responding in this tab, usually because the editor restarted its extensions. Your most recent messages may not have reached Claude. If this notice is still here after a minute, close this tab and reopen the conversation from the session list in the Claude Code sidebar."

Diagnosis from the VS Code logs, and what Claude Code could change

I went through VS Code's logs, the Crashpad dumps and the Claude Code extension's own log for the crashes on 2026-09-27. Short version: every crash and every "Claude Code stopped responding in this tab" happened within a minute or two of starting a Claude Code workflow run with several worktree-isolated agents.

• Claude Code runs in VS Code's shared extension host. When that host is starved or crashes, every session in the window disconnects.
• Several things during a workflow run starve it. Some are in Claude Code; one is a third-party extension (reported upstream, linked below).

Environment: VS Code 1.139.1; Claude Code 2.1.283 (extension and CLI); macOS 27.0 (26A428) on Apple Silicon, 128 GB RAM, so memory pressure at the OS level is not the issue.

Timeline of one crash (local time, paths shortened)

10:19     Claude Code extension log: workflow starts. 827 log lines this minute, 388 the next
10:20:29  renderer.log: [File Watcher ('parcel')] Events were dropped by the FSEvents client. File system must be re-scanned. (path: <workspace>)
10:20:42  (repeated 4× between 10:20:29 and 10:20:42)
10:20:30  Claude Code extension log goes silent
10:20:45  renderer.log: Extension host (LocalProcess pid: 77432) is unresponsive.
10:21:27  main.log: Extension host with pid 77432 exited with code: 6 … crashed with code 6 and reason 'crashed'
10:21:27  renderer.log: … terminated unexpectedly … Automatically restarting the extension host.
10:21:29  Claude Code extension log: "Claude code extension is now active" (restart). The session shows "stopped responding in this tab"

• The other crash type. The window renderer (the process that draws the chat) was killed twice the same day: main.log: CodeWindow: renderer process gone (reason: killed, code: 9) at 08:33 and 10:03. That is the The window terminated unexpectedly (reason: 'killed', code: '9') in this issue. Crashpad wrote minidumps for both kinds of crash.
• What exit code 6 means. It is SIGABRT, which fits V8 aborting under heap pressure. I did not capture a heap-limit message, so that part is an inference.

What Claude Code could change

1. Worktree isolation puts the worktrees inside the workspace.

• Worktree agents are created in <workspace>/.claude/worktrees/. VS Code therefore watches and indexes them, and so do all language extensions (TypeScript, ESLint, Vue, Angular, GitLens…).
• In a Node project each agent runs npm ci in its worktree, about 100,000 files each. Five at once overflowed macOS FSEvents: the "Events were dropped … must be re-scanned" lines above, three seconds before the host went unresponsive.
• Suggestion: place worktrees outside the workspace folder.
• files.watcherExclude for **/.claude/worktrees/** is not enough. I added it, and the same "Events were dropped" warnings came back at 11:06 during the next workflow run, because the FSEvents stream overflows at the workspace root before VS Code applies exclusions.
• The exclusion (with search.exclude and git.repositoryScanIgnoredFolders) still stops VS Code and the other extensions from reacting to the worktrees. It would be a sensible configurationDefaults entry in the extension until the worktrees move.

1. The chat webview floods the extension host during workflows.

• In about two minutes while background agents changed state, the extension logged 151 update_session_state, 149 rename_tab and 49 show_notification requests from the webview, peaking at 15 to 20 messages a second. Many were rename_tab repeating the same title, and update_session_state flapping.
• Suggestion: coalesce and deduplicate these on the webview side.

1. A failed permission prompt is reported to the model as a user decision.

• While the extension host was restarting, tool-permission requests failed with Tool permission request failed: AbortError: Stream closed.
• Some came back to the model, and to subagents, as a refusal: "The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed."
• Every running agent then stopped mid-task, although the user had refused nothing. The transport failed.
• Suggestion: distinguish a failed permission channel from a user refusal, and re-present pending prompts once the channel is back.

1. Sessions do not survive a restart of the extension host.

• Because Claude Code shares the host with every other extension, any extension that blocks or crashes it disconnects all sessions ("Your most recent messages may not have reached Claude").
• Resuming a long session then re-sends the whole context, which is expensive, as the comment above notes.
• Suggestions:
• reattach automatically to the still-running session after a host restart;
• consider running the CLI bridge outside the extension-host lifetime;
• recommend extensions.experimental.affinity for anthropic.claude-code.

1. Very large sessions. This session's transcript is 120 MiB, plus about 540 MB of agent transcripts. I did not prove that the chat view's memory for such a session contributed to the renderer kills, but it is worth checking with sessions of that size.

Third-party contribution, reported upstream

The Claude Code Workflow Dashboard extension was also installed. On every file-system event in a workflow run's directory, it synchronously re-reads and re-parses every agent transcript, inside the same extension host. That is reported with source references at https://github.com/gagarinlg/claude-code-workflow-dashboard/issues/3.

Status

I uninstalled that extension and excluded .claude/worktrees/** from VS Code's watcher.

• Since then: no unresponsive extension host and no crash, over a short window so far.
• The flood itself continues: the FSEvents warnings recurred during the next workflow run.
• So the dashboard looks like the main cause of the host crashes, and the worktree flood a contributing load. Item 3 is a separate defect: it turns any extension-host outage into stopped agents.

I have not compared older Claude Code versions, so I cannot say which change made this appear. The trigger in practice was starting to use workflows with several worktree-isolated agents: items 1 to 3 above are the Claude Code side of it.

Reproduction that should show items 1 to 3: in VS Code, open a Node project with a lockfile and a few language extensions installed. Start a workflow of five or more agents with worktree isolation, each running npm ci, and watch renderer.log and the Claude Code output channel.