[BUG] `claudeCode.useTerminal` still never read in 2.1.214 (first Windows report) - re-file: #9741 closed "completed", #38642 / #40925 / #44546 / #49864 all closed and locked

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?

Re-file, not a duplicate. This bug has been reported before. Every prior report is closed and locked, so there is no existing thread to comment on and no way to reopen one. The preflight checkbox wording ("hasn't been reported yet") is fixed template text and could not be qualified — this note is the correction.

| issue | date | version | closed as |
|---|---|---|---|
| #9741 | 2025-10-31 | — | completed |
| #38642 | 2026-03-25 | 2.1.83 | not_planned (stale) |
| #40925 | 2026-03-30 | 2.1.87 | not_planned (stale) |
| #44546 | 2026-04-07 | — | not_planned (stale) |
| #49864 | 2026-04-17 | 2.1.112 | duplicate (auto-closed by bot) |

#9741 was closed as completed in October 2025, but the behaviour it
describes is still present today. #40925 explicitly noted "#9741 is still
relevant". The rest lapsed to stale or were auto-duplicated. No human triage
ever concluded this was fixed, and all five are now locked.

What is new here:

1. Still present in 2.1.214 (July 2026) — 9 months after #9741 was closed as

completed, 4 months after #38642.

1. First report on Windows. #38642, #40925, #44546 and #49864 are all macOS

or Cursor. This confirms the bug is platform-independent.

1. A currently-recommended workaround does not work. Open issue #70205 (the

useTerminal deep-link freezing Cursor) advises "set the value directly in
settings.json instead of using the link". Per the analysis below that is
also ineffective — nothing reads the value however it is set.

1. Independent source confirmation at a new version, including a false-positive

trap that could otherwise make it look like the setting is consumed.

---

The bug. claudeCode.useTerminal has no effect. Enabling it changes
nothing, across many VS Code restarts.

The shipped bundle shows why: the setting is never read by any code. It is
declared in package.json, migrated between configuration namespaces, and
linked from the in-panel banner — but no code path retrieves its value.

The terminal interface itself works; it is simply not reachable via this
setting. The contributed command claude-vscode.terminal.open ("Claude Code:
Open in Terminal") does work.

Source-level evidence, from the shipped extension.js (v2.1.214,
anthropic.claude-code-2.1.214-win32-x64):

The generic config reader is defined at line 344:

function Vn(e){ return xs.workspace.getConfiguration("claudeCode").get(e) }

A read of this setting would therefore appear as Vn("useTerminal"). Other
settings do exactly that — e.g. Vn("disableLoginPrompt") at line 839.

There is no such call. useTerminal occurs exactly twice in
extension.js, and neither is a read:

1. Line 344 — namespace migration from legacy claude-code to claudeCode:

let r=["environmentVariables","useTerminal","allowDangerouslySkipPermissions",
       "claudeProcessWrapper","respectGitIgnore"];
for(let n of r){ let i=e.inspect(n)?.globalValue;
  if(i!==void 0) t.update(n,i,...), e.update(n,void 0,...) }

1. Line 845 — opening the settings editor at this key, from the banner:

await ge.commands.executeCommand("workbench.action.openSettings",
                                 "claudeCode.useTerminal")

useTerminal occurs zero times in webview/index.js.

False-positive warning for whoever verifies this: useTerminal appears 8
times in the bundled resources/native-binary/claude.exe, which makes a naive
grep -r look like the value is consumed. All 8 are React/Ink hook names
containing the string as a substring — useTerminalViewport, useTerminalTitle,
useTerminalFocus, useTerminalNotification, useTerminalSize. None is the
setting.

Terminal launching does exist, at two createTerminal sites (lines 845 and
899), reachable via the contributed command claude-vscode.terminal.open.
Nothing connects the setting to those code paths.

This matches the analysis independently reached in #38642 (v2.1.83) and #40925
(v2.1.87). Three separate source inspections across three versions and two
operating systems reach the same conclusion.

What Should Happen?

Enabling claudeCode.useTerminal should switch the extension to the terminal
interface, as its own description states: *"Launch Claude in the terminal
instead of the native UI."*

Error Messages/Logs

(none - the setting fails silently)

Steps to Reproduce

1. Set "claudeCode.useTerminal": true in user settings.
2. Restart VS Code.
3. The graphical panel is still shown; nothing changes.
4. Confirm in the shipped bundle:

grep -c useTerminal extension.js → 2, being the migration list and the
openSettings call. There is no Vn("useTerminal") anywhere.

Configuration causes ruled out before inspecting the bundle:

• Settings file is valid JSONC (comments and trailing commas handled): valid,

55 top-level keys.

• No duplicate key — claudeCode.useTerminal appears exactly once.
• Correct settings file is active — the workspace maps to

__default__profile__, so %APPDATA%\Code\User\settings.json is effective.
The only other profile present declares useDefaultFlags.settings: true and
would inherit the same value.

• No workspace-level override — no .vscode/settings.json in the workspace.
• Not a stale session — VS Code fully restarted many times after enabling it.

Impact

The setting is surfaced in the settings UI with a description promising specific
behaviour, and an in-panel banner ("Prefer the Terminal experience? Switch back
in Settings") links users directly to it. Users enable it, see nothing happen,
and reasonably conclude they have misconfigured something — restarting and
hunting through config. The banner actively drives users toward a control that
does nothing.

Suggested Fix

Either wire the setting to the existing terminal path (the createTerminal code
is already present and already reachable via claude-vscode.terminal.open), or
remove the setting and have the banner invoke that command directly.

If the setting is deliberately deprecated in favour of the command, mark it
deprecated in package.json so the settings UI reflects that, and stop linking
the banner to it.

Workaround for affected users: run Claude Code: Open in Terminal from
the command palette. That is the working path to the terminal interface; the
setting is not.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.214 (extension: anthropic.claude-code-2.1.214-win32-x64)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

#9741 was closed as "completed" in October 2025, but the behaviour persists —
so this is not a regression so much as a fix that either did not land or did not
cover this path.

Please also consider whether the dup-bot / stale-bot behaviour is contributing.
#49864 was auto-closed against #44546 three days after filing with no human
review, and #44546 itself then lapsed to stale. The same pattern is called out
in #62149 ("re-filing after #41036 and #53647 were auto-misrouted by dup-bot")
and #67749 ("recurring bug, repeatedly auto-closed unfixed").