Feature request: allow transparent/none value for userMessageBackground (transparent terminals)

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 25, 2026

Feature request

Allow userMessageBackground (and related background tokens like userMessageBackgroundHover) in custom themes to accept a value like "none" / "transparent" / "default" that skips painting an explicit ANSI background color, falling back to the terminal's default background.

Motivation

When running Claude Code in a terminal with background transparency (e.g. Ptyxis/GNOME with opacity < 1.0 so the desktop wallpaper shows through), any explicitly painted background color remains fully opaque. The grey fill behind past user messages in the transcript stands out as a solid box against the otherwise translucent terminal background.

Custom themes can change the color of userMessageBackground (which does apply in the default renderer, not just fullscreen — docs say fullscreen-only), but there is no way to remove the fill entirely. The best workaround today is manually approximating the perceived blended color of (terminal background × opacity + wallpaper), which breaks whenever the wallpaper or opacity changes.

Proposal

  • Accept "none" (or "transparent") as a value for background color tokens in ~/.claude/themes/*.json, meaning "do not emit an SGR background sequence; use the terminal default background".
  • Alternatively, a boolean theme/setting option to disable message background fills.

Related: #86221 (dark-daltonized userMessageBackground contrast issue)

Environment: Claude Code on Linux (Ubuntu, Ptyxis terminal with opacity 0.8), default renderer (/tui = default), theme base dark-daltonized.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗