Claude Code responses disappear immediately after streaming completes in VS Code extension

Resolved 💬 5 comments Opened Apr 2, 2026 by warment Closed May 11, 2026

Claude Code responses disappear immediately after streaming completes in VS Code extension

Bug Description

When sending a message to Claude in the VS Code extension, the response streams normally (text appears token-by-token). As soon as the response finishes streaming, the entire message instantly disappears from the UI. The CLI process appears to still be running, but the webview shows nothing.

After restarting VS Code, the conversation history fully recovers — all "disappeared" messages are visible again.

Environment

  • Extension: Claude Code for VS Code v2.1.89
  • CLI: Claude Code v2.1.89
  • Platform: macOS darwin-arm64 (Apple Silicon)
  • VS Code: installed via Homebrew
  • Where Claude opens: Sidebar and Editor panel (both reproduce the issue)

Reproduction Steps

  1. Open VS Code with Claude Code extension installed
  2. Open Claude in sidebar (or editor panel)
  3. Type any message and send
  4. Watch the response stream normally
  5. As soon as streaming completes, the response disappears
  6. Restart VS Code — messages are visible again

What I've Tried

  • Terminal mode (claudeCode.useTerminal: true) — same disappearing behavior
  • Session data inspection — confirmed ~/.claude/history.jsonl, session files in ~/.claude/sessions/, and backups in ~/.claude/backups/ all exist with correct data (proving CLI persists state to disk)
  • Webview DOM inspection — checked webview bundle (webview/index.js) for innerHTML (24 uses), textContent (142 uses) — no obvious clear-on-message_stop bug found

Root Cause Investigation

The extension fails to pass sessionId when the webview is restored:

Problem 1: deserializeWebviewPanel

M6.window.registerWebviewPanelSerializer("claudeVSCodePanel", {
  async deserializeWebviewPanel(A, I) {
    let v = I, w;
    if (typeof v?.isFullEditor === "boolean") w = v.isFullEditor;
    else w = M6.window.tabGroups.all.findIndex((E) => E.viewColumn === A.viewColumn) === 0;
    Z.setupPanel(A, void 0, void 0, w)  // ← sessionId and initialPrompt are NULL
  }
})

Problem 2: resolveWebviewView

resolveWebviewView(K, V, H) {
  ...
  K.webview.html = this.getHtmlForWebview(K.webview, void 0, void 0, !0)  // ← sessionId = undefined
  ...
  new B5(this.context, G, ..., void 0, ...)  // ← void 0 for initialSessionId
}

On any webview restore (sidebar refresh, visibility change, extension host recycle), the webview initializes with a session ID of undefined instead of reconnecting to the existing CLI session.

Two Possible Failure Modes

  1. CLI process crash after message_stop — The CLI may be crashing after completing a response. The extension doesn't detect this or show an error. Terminal mode also failing supports this hypothesis.
  1. Webview re-creates with blank session — The webview re-renders with undefined sessionId, creating a blank new session instead of restoring the existing conversation.

Expected Behavior

Responses should remain visible in the webview after streaming completes. The webview should maintain its connection to the CLI session across visibility changes and restores.

Impact

The VS Code extension is practically unusable without a full restart after each interaction.

Recommended Fix Areas

  1. Pass sessionId on webview restore — Store the session ID in Memento/state API and pass it to setupPanel() / resolveWebviewView()
  2. Detect CLI process crashes — Add process liveness monitoring; show error on unexpected exit
  3. Implement getPanelState() / setPanelState() — Persist and restore communication channel state across webview lifecycle events
  4. Investigate CLI crash on message_stop — Check for panics, OOM, or stream termination issues

View original on GitHub ↗

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