claude-code - 💡(How to fix) Fix [BUG] VS Code extension: opening a new editor tab causes 300-500 ms main-thread stalls in the webview [3 comments, 3 participants]

Preflight Checklist

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

What's Wrong?

Opening a new editor tab in VS Code while the Claude Code panel is visible causes a 300 to 500 ms freeze in the renderer hosting the Claude Code webview. During the freeze the mouse cursor stutters, typing is delayed, and the chat panel visibly reflows. The freeze repeats every time the editor area is resized horizontally (open tab, close tab, split, drag the side bar boundary).

Root Cause from Performance Trace

A renderer-process performance trace shows the cause clearly. When the editor area resizes horizontally, the Claude Code webview reacts to a ResizeObserver callback and synchronously re-lays-out and re-renders every chat turn in the panel. The hot call stack is in the extension's bundled webview/index.js:

measureReferenceDomElement
  observe (ResizeObserver)
    fire
      _deliver
        endUpdate
          [Monaco view rendering]
            _finishRenderingNewLines
            _renderWidget
            renderText
            _onRenderScheduled

Top long tasks during one 8.6 second trace that contained a single repro (durations vary with chat length):

Workbench contribution in the same trace is small by comparison:

• doOpenEditor, doCloseEditor, addGroup, removeView, layout in workbench.desktop.main.js: tens of ms combined
• vscode-textmate plus vscode-oniguruma tokenization for the newly opened file: about 32 ms total

So the cost is almost entirely in the extension's webview, not in VS Code itself.

Layout Shifts

The same trace measures CLS 0.41 (CLS over 0.25 is rated poor). Three large shifts come from reflow inside the Claude Code chat panel as it resizes:

Two minor shifts also occur in the workbench editor area itself (editor.modified, lines-content.monaco-editor-background) as it gains width once the Claude Code panel finishes its reflow.

Steps to Reproduce

1. Install Claude Code 2.1.144 (or newer) in VS Code on Windows.
2. Open a workspace and dock the Claude Code chat panel to the side bar with several turns of chat history visible.
3. Open any new editor tab (Ctrl+P then pick a file, or click an unopened file in the explorer) so the editor area must resize.
4. Watch the mouse cursor and the chat panel. The cursor stutters for roughly half a second; the chat panel content visibly jumps as it reflows.

Severity scales with the number of chat turns in the panel. A freshly cleared panel stutters briefly. A long conversation stalls visibly each time.

Expected Behavior

Resizing the panel container should not trigger a synchronous re-render of every chat turn. A width-only change to the outer container should not invalidate Monaco lines that have already been laid out and rendered.

Suggested Fix Directions

Three options, smaller to larger change:

1. Debounce or coalesce the ResizeObserver callback in webview/index.js. At present it appears to fire on every animation frame of the resize and to call into the render pipeline synchronously. A trailing call after the resize gesture stops would remove most of the cost without changing visible behavior.
2. Treat width-only changes as a layout pass, not a render pass. Skip Monaco _finishRenderingNewLines / _renderWidget for turns whose content has not changed since the last render.
3. Render historical (non-streaming) chat turns to a plain DOM surface and only use Monaco for the actively streaming turn. Monaco is expensive to instantiate and re-layout per turn, and most turns are static once the response completes.

Environment

• Claude Code extension: 2.1.144 (win32-x64)
• VS Code: stable channel
• OS: Windows 11 Pro
• Reproduces consistently on every editor area resize when the Claude Code panel is visible.

Possibly Related but Distinct Issues

• #26302 (Claude Desktop app, Cowork VM plus GPU compositor root cause, not the VS Code extension webview)
• #42045 (CLI streaming output on high refresh rate displays, terminal renderer rather than webview)
• #55149 (Claude Desktop, LocalStorage sync payload blocking main thread, different blocker)
• #39807 (VS Code extension full hang, not a per-resize stutter)

These share the surface symptom of UI lag on Windows but identify different products or different root causes. The trigger here (editor area resize while the Claude Code panel is visible) and the bottleneck (ResizeObserver callback driving synchronous Monaco re-render of chat turns) are not in the existing reports I searched.

Trace Artifacts

A Chrome Trace Event Format export from VS Code DevTools (Help, Process Explorer, renderer DevTools, Performance, Record) is available on request. The trace referenced above is roughly 55 MB. The summary in this report was extracted from it.