anthropics / anthropics/claude-code
VS Code extension: inline code is invisible under High Contrast themes (black-on-black / white-on-white)
- Langage dominant
- Python
- Étoiles
- 145k
- Forks
- 23.1k
- Métriques de merge des PR
- Métriques de PR en attente
Description
### Summary
In the VS Code / Cursor extension, inline `code` spans in assistant messages render with
effectively zero contrast under High Contrast themes. The text is readable only while it is
selected. Fenced code blocks are unaffected, because the syntax highlighter sets colors explicitly.
This affects both built-in VS Code High Contrast themes, in opposite directions:
- **Dark High Contrast** — black text on a black box
- **Light High Contrast** — white text on `#F2F2F2` (contrast ratio ~1.05:1)
### Screenshots
### Environment
- Extension: `anthropic.claude-code` 2.1.270 — also reproduces on 2.1.269; the relevant CSS is byte-identical in both
- Host: Cursor 3.20.17 (VS Code base 1.128.0), macOS 15
- Theme when first observed: "Cursor Dark High Contrast" (`uiTheme: hc-black`)
### Reproduction
1. Select a High Contrast theme (VS Code's built-in "Dark High Contrast" is enough — this is not Cursor-specific).
2. Ask Claude anything that produces inline code in its answer.
3. The inline code spans are invisible. Select the text and they appear.
### Root cause
1. The webview host stylesheet styles every `code` element
(`vs/workbench/contrib/webview/browser/pre/index.html`):
```css
code {
font-family: var(--monaco-monospace-font);
color: var(--vscode-textPreformat-foreground);
background-color: var(--vscode-textPreformat-background);
}
```
2. The extension overrides this with a higher-specificity rule in `webview/index.css`
that sets only the background and leaves the foreground to the host
(class name is hashed in the built CSS):
```css
.root_-a7MRw code { background: var(--app-code-background); ... }
/* --app-code-background: var(--vscode-textCodeBlock-background, #7f7f7f26) */
```
3. The High Contrast themes define neither `textPreformat.foreground` nor
`textCodeBlock.background`, so both resolve to the color registry defaults:
```
textPreformat.foreground : { light: "#A31515", dark: "#D7BA7D", hcDark: "#000000", hcLight: "#FFFFFF" }
textPreformat.background : { light: "#0000001A", dark: "#FFFFFF1A", hcDark: "#FFFFFF", hcLight: "#09345f" }
textCodeBlock.background : { light: "#dcdcdc66", dark: "#0a0a0a66", hcDark: black, hcLight: "#F2F2F2" }
```
→ hcDark: `#000000` text on a black box. hcLight: `#FFFFFF` text on `#F2F2F2`.
Which built-in themes define these tokens (checked in `extensions/theme-defaults/themes/`):
| Theme | `textPreformat.foreground` | `textCodeBlock.background` |
|---|---|---|
| Dark Modern | `#D0D0D0` | `#2B2B2B` |
| Light Modern | `#3B3B3B` | `#F8F8F8` |
| **hc_black** (Dark High Contrast) | **not defined** | **not defined** |
| **hc_light** (Light High Contrast) | **not defined** | **not defined** |
Worth noting that step 2 is what breaks it. Without the extension's override the host pairing
is self-consistent and readable: on hcDark it would be `#000000` text on the
`textPreformat.background` default of `#FFFFFF`. Overriding the background without also
setting the foreground is what decouples the pair.
### Suggested fix
Set the foreground in the same rule, exactly as the extension already does for
`.terminalLink_Eg8KCQ code`:
```css
.root_-a7MRw code {
color: var(--app-primary-foreground); /* var(--vscode-foreground) */
background: var(--app-code-background);
...
}
```
`--vscode-foreground` always resolves to a readable value against the panel background —
the HC themes leave it to the registry defaults `#FFFFFF` (hcDark) and `#292929` (hcLight) —
so this fixes both directions without any theme-specific handling.
### Workaround for users
```json
"workbench.colorCustomizations": {
"[Dark High Contrast]": {
"textPreformat.foreground": "#F0F0F0",
"textCodeBlock.background": "#2A2A2A"
}
}
```
### Possibly related
#89808 (chat diff blocks hardcode Monaco theme `vs-dark`) — different component, same class of
theme-token issue.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Piste de recherche
Start with the inline-code rule in webview/index.css and compare it with the existing .terminalLink_Eg8KCQ code rule. Reproduce the issue in the built-in Dark High Contrast and Light High Contrast themes, then verify that inline code remains readable in both while fenced code blocks are unchanged.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- css, vscode
- Domaine
- accessibility, frontend
- Type d'issue
- Bug
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Activité
- Active
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 82/100