claude-code - 💡(How to fix) Fix [BUG] in VS Code/Cursor extension spinnerVerbs read from claudeCode.* workspace config instead of ~/.claude/settings.json effective view (one-line fix in extension.js)

function v1(z) { return J3.workspace.getConfiguration("claudeCode").get(z); }
// ...
getSpinnerVerbsConfig() { return v1("spinnerVerbs"); }   // ← reads from VS Code workspace config

The extension is reading from vscode.workspace.getConfiguration("claudeCode").get("spinnerVerbs"), not from the parsed ~/.claude/settings.json it already has cached.

Two facts confirm this is a code defect, not an alternate-but-undocumented config location:

claudeCode.spinnerVerbs is not declared in this extension's own package.json (contributes.configuration.properties lists allowDangerouslySkipPermissions, autosave, claudeProcessWrapper, disableLoginPrompt, enableNewConversationShortcut, enableReopenClosedSessionShortcut, environmentVariables, hideOnboarding, initialPermissionMode, preferredLocation, respectGitIgnore, useCtrlEnterToSend, usePythonEnvironment, useTerminal — but no spinnerVerbs). So the VS Code settings UI can't surface it, and the read on an undeclared property returns undefined silently.

The change-listener at offset 2055742 nevertheless references I.affectsConfiguration("claudeCode.spinnerVerbs") — suggesting the property declaration was dropped at some point and the read path was never updated.

Meanwhile, the correct value is already in memory. The state-push at offset 1648793 simultaneously sends:


spinnerVerbsConfig: this.settings.getSpinnerVerbsConfig(),   // ← broken (VS Code config)
claudeSettings:     this.cachedClaudeSettings,                // ← parsed ~/.claude/settings.json
cachedClaudeSettings is the response from the native binary's get_settings IPC RPC, which has shape { effective, sources } — effective is the merged view across user/project/local scopes, sources is the per-scope breakdown. Existing consumers confirm the shape; the only field paths anywhere in extension.js that touch cachedClaudeSettings are cachedClaudeSettings?.effective?.language and cachedClaudeSettings?.effective?.model. So cachedClaudeSettings?.effective?.spinnerVerbs is the correct path — the data is sitting there, just never read.

The webview side is fine. tL0 at webview/index.js offset 4729488 handles mode: "replace" correctly:


function tL0($) {
  if (!$) return nq1;
  if ($.mode === "replace") return $.verbs.length > 0 ? $.verbs : nq1;
  return [...nq1, ...$.verbs];
}
If spinnerVerbsConfig arrived as {mode:"replace", verbs:["Thinking"]}, the webview would correctly render only "Thinking".


Related open reports that this analysis explains: #41585, #41905, #52532, #56453.

Unlike the other open reports, extensive analysis and proposed fix are contained below under additional information.

### What Should Happen?

With ~/.claude/settings.json containing:


{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "spinnerVerbs": { "mode": "replace", "verbs": ["Thinking"] }
}
…the spinner in the VS Code / Cursor extension chat panel should display "Thinking" exclusively, with no rotation through default verbs. This matches the behavior of the terminal claude CLI, which honors the same setting correctly (the bug is scoped to the VS Code extension's spinner-rendering path; the CLI has a separate, working code path).

Proposed fix — one-line change in extension.js:


- getSpinnerVerbsConfig() { return v1("spinnerVerbs"); }
+ getSpinnerVerbsConfig() { return this.cachedClaudeSettings?.effective?.spinnerVerbs; }
And the now-dead listener reference at offset 2055742:


- I.affectsConfiguration("claudeCode.initialPermissionMode") ||
- I.affectsConfiguration("claudeCode.spinnerVerbs")
+ I.affectsConfiguration("claudeCode.initialPermissionMode")
Known caveats the maintainer should consider for a follow-up:

Initial-render race. cachedClaudeSettings is undefined until M.getSettings() (offset 1619940) resolves asynchronously after the CLI subprocess launches. The first state push at offset 1667447 fires before that, so the webview receives spinnerVerbsConfig: undefined initially and renders default verbs for ~50-500ms until a second pushStateUpdate() lands with the real value. The current broken code is synchronous via getConfiguration().get(), so this is technically a new flicker. Easy mitigation: gate the first state push on the IPC resolving, or initialize cachedClaudeSettings to a deferred sentinel.

No hot-reload on manual settings.json edits. Searching the extension for FileSystemWatcher returns zero occurrences, and the four M.getSettings() call sites are: once at CLI channel launch (1619940), once in a "config loading only" bootstrap (1627405), once after the extension itself writes to settings.json via applySettings (1652045), and the RPC definition (1009674). Nothing re-fetches when the user edits ~/.claude/settings.json outside the IDE. Users still need to reload the window to pick up manual edits. The current broken code has the same property; this isn't a regression introduced by the fix, but it's worth fixing in a follow-up (FileSystemWatcher on the user settings path, or an IPC push from the native CLI's existing settings file watcher).

Silent validation strip. If spinnerVerbs is malformed in user settings (wrong type, empty verbs array, mode outside enum), the native CLI's Zod validator likely strips the field with a warning rather than failing the whole file (it does this for permissions.allow/deny/ask). Maintainers should confirm the validation behavior and surface the warning to the user so they don't think the fix is broken when their config is malformed.

### Error Messages/Logs

```shell
None. The bug fails silently — that is part of why it has been hard to debug from outside.

What I checked in extension.js (build 2.1.143):

vscode.workspace.getConfiguration("claudeCode").get("spinnerVerbs") on the undeclared property returns undefined per the VS Code API contract. No exception, no warning, no log.
The webview's tL0(undefined) falls through to "return defaults." It treats "no config" and "user explicitly set defaults" identically — no way to distinguish.
The only logger.error paths around settings ingestion are guarded against IPC/parse failures only:
offset 1620024: .catch((R) => this.logger.error(Failed to fetch Claude settings: ${R}))
offset 1652088: } catch (O) { this.logger.error(Failed to refresh Claude settings: ${O}) }
offset 1651276: } catch (x) { this.logger.error(Failed to parse settings.json: ${x}) } None of these fire for the spinnerVerbs case because the user's JSON is valid and the IPC succeeds — the value just takes the wrong path through the code and lands in undefined.
The Zod schema (offset 1488575) declares spinnerVerbs as .optional(), so its absence is by definition valid; there is no "you set this but it isn't being used" check anywhere.
VS Code Output panel → "Claude Code" channel: silent.
VS Code Output panel → "Log (Extension Host)": silent.
Surfaces I checked manually and found clean — nothing to attach.


I proved my config IS being read correctly by the native binary — separate from whether the extension uses it — by running: claude config get spinnerVerbs

That prints { mode: 'replace', verbs: [ Thinking' ] }, the CLI sees the setting; the bug is confirmed to be 100% on the VS Code extension side. Additionally, running Claude Code from terminal picks up the setting and it works only showing "Thinking" when prompted (and leaving my mellow undisturbed).

Here is Claude's further feedback from the terminal instance:
PROMPT: Why would that work when I run claude from terminal but not when I run Claude from within VS Code/Cursor                                                   
 
RESPONSE:   
⏺ spinnerVerbs is CLI-only — it controls the terminal spinner's verb (e.g.,
  "Thinking…"). The VS Code/Cursor extension renders status through its own
  native UI panel and ignores terminal-only settings like spinnerVerbs,
  spinnerTipsEnabled, and tui.

  Settings split:
  - Both surfaces read ~/.claude/settings.json, but the IDE only honors non-UI
  keys (permissions, hooks, MCP, env vars).
  - The extension has its own settings under VS Code → Extensions → Claude Code
  (e.g., claudeCode.useTerminal, claudeCode.initialPermissionMode).