[BUG] 2.1.141 release regression: output panel auto-reveal, debug log spam, settings not persisting

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?

Version 2.1.141 introduced multiple user-visible regressions that were not present in 2.1.140. Rolling back to 2.1.140 resolves all of them.

Filing as a single issue because the bug is the release, not three independent feature bugs. Three unrelated regressions shipping together in one point version points to a release/QA process gap, and treating them separately would obscure that. Symptoms below are evidence of the underlying release-quality issue.

Symptom 1: Output panel auto-reveals on stream error fallthrough. When an SDK stream ends with had_error: true, the extension surfaces an error reading Unhandled case: [object Object] and the Output panel is force-opened via an open_output_panel webview message. Happens on every failed stream, steals focus mid-task.
The error string Unhandled case: [object Object] indicates a default branch in a switch on an error type, with the object stringified via template literal instead of .message / JSON.stringify. The fallthrough then calls open_output_panel unconditionally.

Symptom 2: Excessive DEBUG-level logging in default Output channel. The Output channel is flooded with DEBUG entries on every turn — OAuth token checks, LSP diagnostic polls, hook registry checks, autocompact stats, dynamic tool loading, billing attribution headers. Well past anything a user needs by default. Amplifies Symptom 1 because the auto-revealed panel is full of noise.

Symptom 3: Thinking-level setting reverts on every window open / new chat. Setting thinking level to max via the UI, then closing and reopening the window (or starting a new chat), reverts it to a lower default. Reproduces every session. Checked both User and Workspace scope in Ctrl+, — setting either isn't being written, is being written to a scope different from the one it's read from, or the config key changed between versions and the old value isn't migrating.

What Should Happen?

Symptom 1: Stream errors should surface inline in the chat UI without forcing the Output panel open. The Unhandled case default branch should either handle the object correctly (via .message or JSON.stringify) or, at minimum, not call open_output_panel as a side effect.

Symptom 2: Default log level should be INFO or WARN. DEBUG output should require an explicit opt-in setting (e.g. claudeCode.logLevel: "debug").

Symptom 3: Thinking-level setting should persist across window reloads and new chat sessions, like any other extension setting. Value set in the UI should round-trip cleanly through whatever storage scope the extension uses.

Overall: A point release should not ship three unrelated user-visible regressions. The release pipeline should catch this class of issue before rollout.

Error Messages/Logs

Relevant log excerpt showing Symptom 1 (stream error → open_output_panel):

2026-05-14 17:22:54.982 [info] Received message from webview: {"type":"request","channelId":"xzhdx8brrvp","requestId":"7g1nelxmpyp","request":{"type":"log_event","eventName":"sdk_stream_ended_no_result","eventData":{"had_error":true,"subagent_count":0,"message_count":462}}}
2026-05-14 17:22:55.936 [info] From claude: [WARN] Streaming stall detected: 31.0s gap between events (stall #1)
2026-05-14 17:23:00.019 [info] From claude: [WARN] Streaming completed with 1 stall(s), total stall time: 31.0s
2026-05-14 17:25:25.269 [info] Received message from webview: {"requestId":"9gxbs1ihxan","request":{"type":"open_output_panel"}}

The user-visible error rendered in the UI is literally:

Unhandled case: [object Object]

Sample of DEBUG-level noise (Symptom 2) — representative slice from a single turn:

[DEBUG] [API:auth] OAuth token check starting
[DEBUG] [API:auth] OAuth token check complete
[DEBUG] [API REQUEST] /v1/messages x-client-request-id=... source=sdk
[DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
[DEBUG] LSP Diagnostics: Checking registry - 0 pending
[DEBUG] Hooks: Found 0 total hooks in registry
[DEBUG] Hooks: checkForNewResponses returning 0 responses
[DEBUG] autocompact: tokens=[REDACTED] level=ok effectiveWindow=980000
[DEBUG] Dynamic tool loading: found 6 discovered tools in message history
[DEBUG] Dynamic tool loading: 6/257 deferred tools included
[DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.141.a18; cc_entrypoint=claude-vscode; cch=00000;

This pattern repeats on every single turn. Multiply by message count to see the noise floor.

Steps to Reproduce

Symptom 1 (output panel auto-reveal):

Update Claude Code extension to 2.1.141.a18
Open a long-running chat session (462 messages reproduces reliably; smaller sessions intermittently)
Wait for or trigger an SDK stream that ends with had_error: true (stream stalls past ~30s reproduce this)
Observe: Output panel force-opens, error reads Unhandled case: [object Object]
Dismiss / close the panel
Continue the session — repeats on every subsequent stream error

Symptom 2 (DEBUG log spam):

Update Claude Code extension to 2.1.141.a18
Open the Output channel (View → Output → "Claude Code")
Send any message
Observe: ~10+ DEBUG-level log lines per turn for normal operation

Symptom 3 (thinking-level reverts):

Update Claude Code extension to 2.1.141.a18
Set thinking level to max via the UI
Confirm setting is applied to the current session
Close the VS Code window (or reload window via Ctrl+Shift+P → "Developer: Reload Window")
Reopen / start a new chat
Observe: thinking level has reverted to a lower default

Confirming this is a 2.1.141 regression:

With 2.1.141.a18 installed, observe all three symptoms above
In the Extensions sidebar, click the gear icon next to Claude Code → "Install Specific Version..." → select 2.1.140
Reload window
Repeat steps for all three symptoms — none reproduce on 2.1.140

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

VS Code extension 2.1.140

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Why this is filed as one issue rather than three: The three symptoms are unrelated in code surface area (webview message handler, logging configuration, settings persistence) but landed together in a single point release. That pattern points to a release/QA process gap rather than three independent code defects. The most valuable investigation is probably "what changed in the 2.1.141 release pipeline" rather than three separate symptom fixes.

Workaround for affected users in the meantime: Roll back the VS Code extension to 2.1.140 via Extensions sidebar → gear icon → "Install Specific Version..." → 2.1.140, then reload window. All three symptoms resolve.

Note on Symptom 1 diagnosis: The literal string Unhandled case: [object Object] shown in the UI is a strong signal that an error object is being interpolated into a template literal at a switch/match default branch, e.g. Unhandled case: ${err} instead of Unhandled case: ${err.message} or JSON.stringify(err). Whoever owns the webview error handler for sdk_stream_ended_no_result events should be able to find it quickly. The open_output_panel webview message firing on the same path is the second half of the bug — that branch shouldn't be auto-revealing the panel at all.