Let themes set the terminal's 16 ANSI colors

[mathiasaerts]

Problem

The integrated terminal's 16 ANSI colors are hardcoded in ThreadTerminalDrawer.tsx (TERMINAL_PALETTES, added in #17168, which deliberately left settings out of scope). Themes already own the other terminal colors (terminalBackground, terminalForeground, terminalCursor, terminalSelection, terminalScrollbar, terminalScrollbarHover), but there is no way to make the terminal match a palette like Nord, Solarized or Dracula, or to match the user's system terminal. Imported VS Code themes also lose their terminal.ansi* colors, so a Dracula import gets Dracula chrome with VS Code's default terminal colors.

Proposal

Treat the ANSI colors as theme roles, completing the terminal set that themes already carry:

• Add 16 roles to THEME_COLOR_ROLES in packages/shared: terminalAnsiBlack … terminalAnsiWhite and terminalAnsiBrightBlack … terminalAnsiBrightWhite.
• Default them to the current VS Code light and dark palettes, so every built-in theme renders exactly as today.
• Expose them as --terminal-ansi-* CSS variables next to --terminal-background etc. terminalThemeFromApp reads those instead of the constant, so the existing theme observer repaints open terminals on theme change.
• Map terminal.ansiBlack … terminal.ansiBrightWhite in the VS Code importer.
• Add a "Terminal palette" group to the theme editor's advanced view.
• Mobile keeps its own palette, as it does today.

Compatibility

No migration. Stored custom themes, theme files and server-published themes are already parsed by merging over the defaults for their appearance, so a theme without the new roles keeps the current palette. Exported theme files simply gain 16 keys. The short canvas + accent generator format gets the defaults through createVividThemeColors.

Alternative considered: a separate "terminal palette" entity

I'd argue against it:

• ANSI colors are designed against the terminal background, which the theme already owns. Red on a dark navy and red on near-white need different values. Splitting them would separate colors that have to be chosen together and would need precedence rules for who owns terminalBackground.
• Every theme source already bundles them. VS Code themes, Nord, Dracula and Catppuccin all ship UI and terminal colors as one unit, and the importer can map them one to one, so an imported theme gets a matching terminal for free.
• The theme pipeline already handles the hard parts: storage, file import/export, light/dark variants, default merging for older files, and server publishing via t3 theme set. A second entity would need its own versions of each.

The cost is mix-and-match: wanting "Grove UI with a Nord terminal" means duplicating Grove and editing 16 colors, which is the same duplicate-and-tweak flow themes use for every other role.

Possible follow-up

If mix-and-match matters, a dropdown in the editor's Terminal palette group could fill the 16 roles from another installed theme or a bundled preset list (Nord, Solarized, Dracula, …). That is an editor convenience on the same data model, so it would not need any migration and does not need to be part of the first change.

Status

I have a working branch with the above: https://github.com/mathiasaerts/t3code/tree/feat/theme-terminal-ansi-palette

It includes tests for the theme-file parsing and the VS Code mapping, and vp run check:changed passes. Happy to open a PR if this direction is acceptable. Does this fit the "focused configuration option for an established capability" route, or would you like to settle the shape here first?

[joshka]

TL;DR: +1 to the ANSI roles. I'd also like a separate terminal theme setting, so Ghostty and iTerm2 themes work as they are. It can reuse the existing theme pipeline and follow your change.

I disagree with this part:

• ANSI colors are designed against the terminal background, which the theme already owns. [...] Splitting them would separate colors that have to be chosen together and would need precedence rules for who owns terminalBackground.
• Every theme source already bundles them. VS Code themes, Nord, Dracula and Catppuccin all ship UI and terminal colors as one unit [...]

Agreed that they're chosen together, which is why a terminal theme should own all the terminal colors: background, foreground, cursor, selection, and the 16 ANSI colors. Either the terminal matches the app theme, or a terminal theme sets all of them. No per-role precedence.

That's what Ghostty and iTerm2 theme files contain, and there are hundreds of them. Nord, Dracula, and Catppuccin publish these terminal ports separately from their editor themes. Each file is one mode; Ghostty pairs them with theme = light:X,dark:Y.

The foreground and background are the terminal's default colors, not just paint. Programs query them (OSC 10/11, plus OSC 12 for cursor and OSC 4 for the palette) to pick light or dark output, e.g. Neovim, delta, bat.

Duplicating an app theme to change its terminal colors also stops it getting that theme's updates, and has to be repeated for each app theme.

A terminal theme can be an ordinary theme that only sets terminal roles, so storage, import/export, light/dark, and t3 theme set carry over. The new part is one setting: "Match app theme" (default) or a light and a dark terminal theme.

🤖 Claude Opus 5.5