[BUG] VS Code extension ignores claudeCode.useTerminal and renders a blank activity-bar icon on VS Code 1.136.2 (correct on 1.135.0)

Preflight

• Searched existing issues; I could not find this reported.
• Single bug report: two symptoms are described because they share one trigger and one likely fix point. Happy to split them if preferred.
• The extension is on the latest build (2.1.266, matching the standalone CLI). The variable in this report is the VS Code client version, not the extension version — see the matrix below, where two different extension builds behave identically on one client and the behaviour only changes when the client changes.

What's Wrong?

On a VS Code 1.136.2 client, the Claude Code extension silently ignores claudeCode.useTerminal: true and opens the native webview UI instead of the terminal, so the CLI/terminal experience becomes unreachable: Claude Code: Open in Terminal and its Ctrl+Escape binding never appear. The extension's entry in the left activity bar is also drawn as a blank icon — the slot is reserved but no glyph is painted.

Connecting to the same remote host from a VS Code 1.135.0 client works correctly: the terminal path is used and the icon renders normally.

What isolates the cause is that the extension version does not matter and the client version does:

| VS Code client | Extension | Result |
| --- | --- | --- |
| 1.135.0 (08d4889f) | 2.1.263 | works — terminal path, icon renders |
| 1.135.0 (08d4889f) | 2.1.266 | works — terminal path, icon renders |
| 1.136.2 (88e44fa0) | 2.1.263 | broken — webview opens, no terminal affordance, blank icon |
| 1.136.2 (88e44fa0) | 2.1.266 | not re-tested; the client was downgraded to 1.135.0 as the workaround before the extension was updated |

Both clients use the same remote user account, so ~/.vscode-server, the installed extension, the standalone CLI, Machine/settings.json and the workspace's .vscode/settings.json are identical across the rows above.

Likely mechanism — package.json gates three containers on a single context key:

activitybar:       claude-sidebar           -> claudeVSCodeSidebar
                   when: claude-code:doesNotSupportSecondarySidebar
                   claude-sessions-sidebar  -> claudeVSCodeSessionsList
                   when: claude-vscode.sessionsListEnabled
secondarySidebar:  claude-sidebar-secondary -> claudeVSCodeSidebarSecondary
                   when: !claude-code:doesNotSupportSecondarySidebar

Once the client supports secondarySidebar, the key flips to false, which (a) leaves the two activity-bar containers with no visible view, so VS Code reserves the slot but draws no glyph, and (b) makes the webview the default surface, so a restored panel issues launch_claude before useTerminal is consulted. The keybinding claude-vscode.terminal.open.keyboard is itself gated when: config.claudeCode.useTerminal, so it never binds.

Separately, resources/claude-logo.svg is declared width="1em" height="1em" with a hardcoded fill="#D97757". Activity-bar icons are expected to be absolutely sized and monochrome so VS Code can mask and recolor them; 1em can resolve to zero in that context, which would blank the glyph even when a view is present.

Also worth noting: in the broken case the webview auto-launches a Claude session on every window open, without the user asking for one.

What Should Happen?

With "claudeCode.useTerminal": true, Claude should launch in a terminal and Claude Code: Open in Terminal plus its Ctrl+Escape binding should be available. An explicitly set user preference should win regardless of the VS Code version or of which view container the extension chooses — the setting should be checked before any webview panel is restored or opened.

The activity bar should never show a container with a blank icon. When the extension moves its UI to the secondary sidebar, the now-empty activity-bar containers should be dropped rather than left registered, so no empty slot is painted.

Behaviour should be identical across VS Code versions for the same extension build against the same remote host.

Suggested fixes:

1. Let claudeCode.useTerminal win regardless of the container branch — check it before restoring or opening the webview panel.
2. Drop the empty activity-bar containers when the secondary-sidebar branch is taken, instead of leaving them registered.
3. Ship the activity-bar icon as an absolutely sized, monochrome SVG with no hardcoded fill.

Error Messages/Logs

There are no errors or warnings — this is a silent failure. The extension activates successfully in every case; it simply takes a different path. Grepping the remote extension host log for error/warn/failed/ENOENT around the Claude extension returns nothing relevant.

The evidence is therefore comparative. All logs below are from the same remote host, same day, same settings:
~/.vscode-server/data/logs/<ts>/exthost*/Anthropic.claude-code/Claude VSCode.log

BROKEN — VS Code 1.136.2 client, extension 2.1.263:

09:20:26.661 [info] AuthManager initialized
09:20:26.661 [info] Claude code extension is now active?
09:20:26.661 [info] MCP Server running on port 17673 (localhost only)
09:20:26.661 [info] Getting authentication status
09:20:26.661 [info] OAuth tokens found in secure storage
09:20:27.414 [info] Received message from webview: {"type":"request","requestId":"3l2xxtrgwlq","request":{"type":"init"}}
09:20:27.487 [info] resolveShellPath: /bin/bash -> 16 entries
09:20:27.609 [info] Received message from webview: {"type":"request","requestId":"f64juwobym4","request":{"type":"get_claude_state"}}
09:20:27.609 [info] Received message from webview: {"type":"launch_claude","channelId":"v0l5of2ahg","cwd":"<workspace>","freshStartIfUnresumable":false,...}
09:20:27.732 [warning] Channel not found for logEvent: v0l5of2ahg
09:20:27.736 [info] Launching Claude on channel: v0l5of2ahg
09:20:29.804 [info] Spawning Claude with SDK query function - cwd: <workspace>, permission mode: undefined, version: 2.1.263

A webview panel opens on window load and drives launch_claude through the SDK. claudeCode.useTerminal: true is never consulted. The only warning in the entire session is Channel not found for logEvent, which looks incidental rather than causal.

WORKING — VS Code 1.135.0 client, extension 2.1.266:

09:34:58.904 [info] AuthManager initialized
09:34:58.904 [info] Claude code extension is now active?
09:34:58.904 [info] MCP Server running on port 32403 (localhost only)
09:35:54.473 [info] Creating new Claude terminal
09:35:54.830 [info] Terminal shell integration available
09:35:55.704 [info] New WS connection from: /
09:35:55.705 [info] MCP server connected to transport
09:35:55.705 [info] [DiagnosticStreamManager] Started streaming diagnostics
09:35:56.206 [info] Logging event: run_claude_command

Note Creating new Claude terminal — the preference is honoured and no webview is involved.

WORKING — VS Code 1.135.0 client, extension 2.1.263 (earlier session, entire log):

09:26:59.751 [info] AuthManager initialized
09:26:59.751 [info] Claude code extension is now active?
09:26:59.751 [info] MCP Server running on port 64238 (localhost only)
09:27:04.537 [info] AuthManager initialized
09:27:04.753 [info] Extension update check: 2.1.261 -> 2.1.265 (attempt 1): ok, telemetry posted
09:27:04.753 [info] OAuth tokens found in secure storage

No webview messages, no SDK spawn.

Counts across sessions on the same host:

client 1.135.0, ext 2.1.263 :  "from webview" = 0    "SDK query function" = 0
client 1.135.0, ext 2.1.266 :  "from webview" = 0    "SDK query function" = 0
client 1.136.2, ext 2.1.263 :  "from webview" = 25   "SDK query function" = 2

Steps to Reproduce

Requires two clients with different VS Code versions connecting to the same remote host over Remote-SSH. The remote side is never changed.

1. On a Linux host, install anthropic.claude-code (2.1.263 or 2.1.266 — both behave the same) into ~/.vscode-server/extensions from the gallery.
2. Set "claudeCode.useTerminal": true in every layer that could apply, so the preference is unambiguous: the client's user settings.json, ~/.vscode-server/data/Machine/settings.json, and the workspace's .vscode/settings.json.
3. From a VS Code 1.135.0 client (commit 08d4889f), connect over Remote-SSH and open a folder.

Result: correct — the log shows Creating new Claude terminal, the activity-bar icon renders, and Claude Code: Open in Terminal with its Ctrl+Escape binding are available.

1. Without touching anything on the remote, connect to the same host and open the same folder from a VS Code 1.136.2 client (commit 88e44fa0).

Result: broken — a webview panel opens and immediately issues launch_claude, Claude is spawned via the SDK, the terminal command and keybinding never appear, and the activity-bar icon is blank.

1. Confirm from the remote logs that the 1.135.0 sessions contain zero from webview and zero SDK query function lines while the 1.136.2 session contains both.

Notes that rule out the obvious alternatives:

• Updating the extension does not help — 1.135.0 is correct on both 2.1.263 and 2.1.266, so the extension version is not the variable.
• Reloading the window does not help on 1.136.2 — VS Code restores the webview panel, which takes the decision again before useTerminal is read.
• Closing the restored panel and then invoking Claude Code: Open in Terminal from the Command Palette does reach the terminal, so the terminal path itself works; only the automatic decision is wrong.
• A completely clean VS Code reinstall on the 1.136.2 client (user data and extensions removed) did not change the behaviour.
• Downgrading the 1.136.2 client to 1.135.0 restores correct behaviour immediately, isolating the client version as the only variable.

Is this a regression?

Yes — but triggered by the VS Code client version, not by a Claude Code version change. The same extension builds are correct on VS Code 1.135.0 and incorrect on 1.136.2.

Last Working Version

VS Code client 1.135.0 (commit 08d4889f9ec4a1685d257b9b95de036c8e1ce1e5, 2026-08-25), with Claude Code extension 2.1.263 or 2.1.266 — both correct.

Claude Code Version

Extension anthropic.claude-code 2.1.266 (linux-x64, from gallery); also reproduced with 2.1.263. Standalone CLI on the remote: 2.1.266.

Platform

VS Code client on Windows 11 x64 (10.0.26200); remote host Debian, kernel 6.8, over Remote-SSH 0.128.0. Broken client: VS Code 1.136.2 (commit 88e44fa0e00b08f7758b4f6d05632e4fd5e4df6f, 2026-09-04).

Workaround

Pin the client to VS Code 1.135.0 and set "update.mode": "none"; otherwise it auto-updates back to 1.136.x and both symptoms return.