[BUG] VS Code extension 2.1.211: renderer crash (SIGBUS, code 135) opening projects with large session-transcript dirs

Status Fixed / completed

Reported on v2.1.211

Maintainer reply None cached

Activity 3 comments · opened Jul 17, 2026 · closed Jul 18, 2026

This was generated by claude fable 5 xhigh:

Summary

The Claude Code VS Code extension v2.1.211 reliably crashes the VS Code renderer process (SIGBUS, exit code 135) within ~15–25 seconds of opening a workspace folder that has a large Claude Code session-transcript directory (295 MB / 149 .jsonl files under ~/.claude/projects/<project>). The window dies with:

The window terminated unexpectedly (reason: 'crashed', code: '135')

Crash happened on every open of the affected project. Projects with smaller session dirs (≤82 MB) open fine on the same machine.

After updating the extension to v2.1.212 the crash no longer reproduces, so this may already be fixed — filing for awareness/confirmation, and in case others hit it on 2.1.211.

Environment

VS Code: 1.129.0 (125df4672b8a6a34975303c6b0baa124e560a4f7), x64
Extension: anthropic.claude-code 2.1.211 (crashes) → 2.1.212 (appears fixed)
OS: Linux, kernel 7.0.0-27-generic, GNOME on Wayland
Affected project session dir: 295 MB, 149 transcript .jsonl files (heavy recent usage, none older than 30 days)

Repro (on 2.1.211)

Have a project whose ~/.claude/projects/<project-hash>/ contains hundreds of MB of session transcripts.
Open that folder in VS Code with the Claude Code extension enabled.
Renderer process crashes with code 135 (SIGBUS) within ~15–25 s, every time.

Isolation evidence

| Configuration | Result |
|---|---|
| Normal open (all extensions, claude-code 2.1.211) | crash ≤25 s, 6+ times over 2 days |
| code --disable-extensions | no crash |
| Only anthropic.claude-code disabled (100+ other extensions on, incl. Copilot) | no crash |
| All extensions on, claude-code updated to 2.1.212 | no crash |

Also ruled out: cleared the workspace's workspaceStorage (203 MB, incl. 71 MB state.vscdb and 35 MB chatSessions) — crash persisted, so not stale editor/chat UI state. Disk space, RAM, and GPU logs clean. Other workspaces unaffected.

Log signature (sanitized)

main.log:

[info] Extension host with pid <old> exited with code: 0, signal: unknown.
[info] Extension host with pid <new> exited with code: 0, signal: unknown.
[error] CodeWindow: renderer process gone (reason: crashed, code: 135)
[error] Extension host with pid <old> still exists, forcefully killing it...

renderer.log, seconds before each crash — chat-session-type warnings followed by extension-host restart and then repeated IPC deserialization failures:

[warning] Attempted to report in-progress status for unknown chat session type 'copilot-cloud-agent'
[warning] Attempted to report in-progress status for unknown chat session type 'copilotcli'
[warning] Attempted to report in-progress status for unknown chat session type 'claude-code'
[info] Started local extension host with pid <new>.
[error] Cannot read properties of undefined (reading '0'): TypeError: Cannot read properties of undefined (reading '0')
    at GHt.onBuffer (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:1076:1523)
    ...
    at MessagePort.we (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:431:15546)
[error] Cannot read properties of undefined (reading '0'): TypeError: Cannot read properties of undefined (reading '0')
    at cLi.onRawMessage (vscode-file://vscode-app/usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js:1074:6161)
    ...

A Crashpad minidump of the renderer crash exists; happy to share it privately if useful (not attaching raw dumps/transcripts publicly).

Hypothesis

Extension's chat-session enumeration/sync on window open chokes on very large session-transcript directories, triggers an extension-host restart mid-handshake, and the renderer dies (SIGBUS) while deserializing the resulting IPC buffers.

View original on GitHub ↗

3 Comments

capaj · 2 months ago

Local minidump analysis of the renderer crash (rust minidump-stackwalk + register forensics; VS Code ships a custom Electron build so no public symbols, but the registers are conclusive):

Crash reason:  SIGBUS / BUS_ADRERR
Crash address: 0x0000746a62c54000
Thread 0 (crashed, main renderer thread)
 rip = code + 0x46fe750   (inside /usr/share/code/code)
 rbx = 0x0000746a62c43000  <- buffer base (page-aligned)
 r15 = 0x000000000002f5db  <- expected buffer length (~194 KB)
 rax = rbx + 0x2f5c0, r12 = rbx + 0x2f5db  <- end pointers
 rdx = 0x0000000000011000  <- fault offset: crash addr == rbx + 0x11000 (exactly 68 KB, page boundary)
 r13/r14 = 0x0234...       <- destination pointers, V8 heap range

Interpretation: the renderer was linearly copying an IPC shared-memory payload into a V8 heap object. The mapping advertised ~194 KB (r15) but was physically backed only up to 68 KB — the first access past the backing (base + 0x11000, page-aligned) raised SIGBUS / BUS_ADRERR, i.e. a memfd/shm-backed mmap shorter than the mapped range. Textbook truncated-shared-memory fault.

This lines up with the renderer.log errors seconds before each crash (Cannot read properties of undefined (reading '0') in onBuffer/onRawMessage): the extension-host restart that the extension triggers during chat-session sync tears down the IPC channel mid-stream; small corrupted messages produce those TypeErrors, and one large truncated buffer kills the process.

One correction to the original report: dump uptime shows the renderer had been alive 4201 s — the crash fires at the moment of the extension-host restart, not strictly at window open (opening the folder just triggers the session sync, and with a 295 MB transcript dir the restart follows within seconds).

capaj · 2 months ago

turns out it keeps crashing without claude extension too, so closing this here. It's a vscode bug, not this extension

github-actions[bot] · 29 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.