VSCODE Extension: Chat panel inline code and code blocks have no background, ignore VSCode theme tokens

Status Fixed / completed
Reported on v2.1.96
Maintainer reply None cached
Activity 8 comments · opened Apr 9, 2026 · closed Jun 30, 2026

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?

In the Claude Code VSCode extension chat panel, both inline code (` foo `) and fenced code blocks render with no background fill, making them visually indistinguishable from prose. Compared to GitHub Copilot's integrated chat — which uses a clear pill for inline code and a distinct tile with border for blocks — Claude Code's chat is significantly harder to read when responses contain code.

The root cause appears to be a dead CSS variable plus hardcoded rules that don't reference any VSCode theme tokens, so users can't fix it via workbench.colorCustomizations either.

What Should Happen?

Either:

Option A — wire the existing variable to a theme token (smallest change):

.root_-a7MRw {
  --app-code-background: var(--vscode-textPreformat-background, rgba(127,127,127,.13));
  --app-code-foreground: var(--vscode-textPreformat-foreground, inherit);
  --app-code-block-background: var(--vscode-textCodeBlock-background, var(--vscode-editor-background));
  --app-code-block-border: var(--vscode-widget-border, rgba(127,127,127,.25));
}

.root_-a7MRw code {
  background: var(--app-code-background);
  color: var(--app-code-foreground);
}

.root_-a7MRw pre code {
  background: transparent;
  padding: 0;
}

.codeBlockWrapper_-a7MRw pre {
  background: var(--app-code-block-background);
  border: 1px solid var(--app-code-block-border);
  padding: 10px 12px;
}

This would make the chat respect any VSCode theme out of the box, and workbench.colorCustomizations overrides for textCodeBlock.background etc. would Just Work.

Option B — expose a setting:

claude-code.chat.codeBlockStyle: "default" | "minimal" | "github" or similar. Less ideal — option A is essentially free.

Error Messages/Logs

In `webview/index.css` (minified, single line), the relevant rules are:


.root_-a7MRw code {
  font-family: var(--app-monospace-font-family);
  word-break: break-word;
  border-radius: 3px;
  padding: 2px 4px;
  font-size: .9em;
  /* no background, no border, no color */
}

.codeBlockWrapper_-a7MRw pre {
  overflow-x: auto;
  white-space: pre;
  box-sizing: border-box;
  border-radius: 4px;
  max-width: 100%;
  margin: 0;
  padding: 8px;
  /* no background, no border */
}


Meanwhile `--app-code-background` is referenced elsewhere in the same CSS (e.g. `.toolResult_uq5aLg`) but is **never defined** anywhere in the bundled CSS or JS — it's a dead variable.

VSCode does expose `--vscode-textCodeBlock-background`, `--vscode-textPreformat-background`, `--vscode-textPreformat-foreground`, and `--vscode-widget-border` to webviews. None of them are referenced by the chat-area code rules, so users cannot work around this with `workbench.colorCustomizations`.

Steps to Reproduce

  1. Install the Claude Code VSCode extension.
  2. Open the chat panel (primary or secondary sidebar).
  3. Ask any question that returns inline code or a fenced code block, e.g. "show me a hello world in C".
  4. Observe: inline code has no background pill; the <pre> block has no background tile or border, just monospace text floating on the chat background.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.96

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

For a tool whose primary output is code, code rendering being hard to read is a real friction point. It's also a ~10-line CSS fix with zero behavioral risk, and it would make the chat panel respect every VSCode theme automatically rather than looking the same regardless of the user's setup.

View original on GitHub ↗

8 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/18738
  2. https://github.com/anthropics/claude-code/issues/35318
  3. https://github.com/anthropics/claude-code/issues/8879

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Vigilans · 3 months ago

Still not fixed yet

ironashram · 2 months ago

not stale

bwilliams1980 · 2 months ago

Same root cause, second instance: markdown _table_ cell borders are invisible — Claude Code VS Code extension running inside Cursor

This issue is about inline code / code blocks, but the same dead---app-*-variable / missing---vscode-*-fallback pattern also kills markdown table cell borders. Commenting here instead of opening a duplicate.

Environment: Claude Code VS Code extension running inside Cursor (a VS Code fork); extension versions 2.1.167 / 2.1.168 / 2.1.169 — the relevant CSS is byte-identical in all three, so this is not a recent extension regression, it's exposed by the host not supplying the theme token; Windows 11.

CSS chain (from webview/index.css):

.root_-a7MRw table { border-collapse: collapse; border: 1px solid var(--app-input-border) }
.root_-a7MRw th, .root_-a7MRw td { border: 1px solid var(--app-input-border); padding: 2px }
--app-input-border: var(--vscode-inlineChatInput-border)   /* no fallback */

Two problems:

  1. No fallback (same as this issue). --app-input-border resolves only to --vscode-inlineChatInput-border. Cursor doesn't inject that token into the webview context, so border: 1px solid <undefined> paints nothing and table gridlines vanish entirely.
  2. **Even when the token is defined, tables borrow the input-field border color**, which is intentionally subtle — so gridlines render barely-visible. Tables arguably want a dedicated, slightly stronger border token rather than reusing the input border. The padding: 2px is also quite tight for cell readability.

Suggested fix (mirrors the Option A pattern proposed here):

/* fallback chain so it degrades on hosts/themes that don't define the inline-chat token */
--app-input-border: var(--vscode-inlineChatInput-border, var(--vscode-input-border, var(--vscode-widget-border, rgba(127,127,127,.4))));

plus optionally giving tables their own slightly-more-visible border token + a little more cell padding.

Current workaround: hand-patching webview/index.css restores borders, but it's wiped by every extension auto-update (observed 2.1.168 → 2.1.169 mid-session).

bwilliams1980 · 2 months ago

Another instance of the same root cause, for the tracking list: chart colors in the chat panel also fail to render in Cursor.

In webview/index.css (ext v2.1.170) the chart palette maps to VS Code chart tokens with no fallback:

--app-chart-1: var(--vscode-charts-orange);
--app-chart-2: var(--vscode-charts-blue);
--app-chart-3: var(--vscode-charts-green);
--app-chart-4: var(--vscode-charts-yellow);
--app-chart-5: var(--vscode-charts-purple);
--app-chart-6: var(--vscode-charts-red);
--app-chart-8: var(--vscode-charts-foreground);
--app-recording-foreground: var(--vscode-charts-blue);

Cursor doesn't inject --vscode-charts-*, so these resolve to nothing and charts render colorless.

Notably, the extension's own status colors in the same file already handle it correctly:

--app-status-busy:    var(--vscode-charts-green,#22c55e);
--app-status-pending: var(--vscode-charts-blue,#3b82f6);

— so the Option A fix (wire --vscode-* tokens with fallbacks) would resolve code-block backgrounds, table borders, and chart colors in one pass, using the same pattern already present for the status colors. (--app-chart-7--vscode-terminal-ansiCyan is unaffected, since Cursor does inject the terminal ansi tokens.)

bwilliams1980 · 2 months ago

Opened #71646 as a consolidated, standalone report covering the shared root cause behind this issue and the table-border / chart-color variants noted in the comments above — webview CSS using var(--vscode-*) tokens without fallbacks. It includes the concrete ~10-line fix (mirroring the fallback pattern the extension already ships for its status colors). Cross-linking for triage.

ironashram · 1 month ago

completed where exactly? 2.1.198 stock CSS is still broken 😞

aaronsleeper · 1 month ago

Related: the same 'ignores VS Code theme tokens' problem shows up on the prompt input's focus ring — it's a hardcoded orange that ignores the theme's focusBorder. Filed as #76989. Honoring the standard workbench theme tokens (focusBorder, input background/border, code-block background) across the extension's webview would fix this whole family at once.