[Bug]: CLI is unreadable on light/cream terminal backgrounds — no light mode support

[aster2709]

Problem

Hermes CLI is completely unreadable on terminals with light or cream backgrounds. All built-in skins (default, ares, mono, slate, poseidon, sisyphus, charizard) use light-colored text designed for dark backgrounds. On a light terminal, the banner text, welcome message, prompt symbol, and user input text are nearly invisible.

Environment

• OS: macOS 15 (Darwin 25.2.0)
• Terminal: Terminal.app with cream/light background
• Hermes: Latest (fresh install via official installer script)
• Model: claude-opus-4-6 via Anthropic provider
• Skin: default (also tested mono, slate — all unreadable)

Steps to Reproduce

1. Use any terminal with a light/white/cream background (e.g. Terminal.app default light theme)
2. Install Hermes Agent via curl -fsSL ... | bash
3. Run hermes
4. Observe: banner text, welcome message, prompt text, and live input text are all nearly invisible

What Happens

• Banner text uses colors like #FFF8DC, #FFD700, #FFBF00, #B8860B — all designed for dark backgrounds
• Welcome message is rendered in a light yellow that disappears on cream
• User input text while typing is invisible until Enter is pressed (prompt_toolkit text color issue)
• The HUD status bar (dark background) is the only readable element

What I Expected

Either:

1. A built-in light skin with dark text colors for light terminal backgrounds
2. Auto-detection of terminal background color and adaptive theme selection
3. At minimum, the skin engine's prompt color key should also control prompt_toolkit's input text color, so custom skins can fix this

Skin System Analysis

The skin engine (hermes_cli/skin_engine.py) supports custom color overrides via ~/.hermes/skins/*.yaml, and it correctly applies to banner, response borders, and UI elements. However:

• Input text color while typing is not controlled by any skin key — it appears to be set by prompt_toolkit's default, which inherits from the terminal's ANSI color palette rather than the skin's prompt color
• All 7 built-in skins assume dark backgrounds
• The colors.prompt key in the skin schema exists but does not affect the actual typing input color

Workaround

Creating ~/.hermes/skins/light.yaml with dark hex values fixes banner/UI text but NOT the live input text. The only full workaround is switching to a dark terminal profile.

Suggested Fix

1. Add a built-in light skin with dark text colors
2. Wire colors.prompt (or add colors.input_text) to prompt_toolkit's input style so skins can control typing text color
3. Consider auto-detecting terminal background via $COLORFGBG env var or similar

Screenshots

[Will attach screenshots showing the unreadable UI on a cream terminal background]

Feature Type

Bug / CLI improvement

Contribution

• I'd like to implement this myself and submit a PR

[aster2709]

hardly see text, as you can see I select it to make it visible in this image.

[ygd58]

Submitted a fix in PR #4811. Added a built-in "light" skin with dark text colors optimized for light/cream terminal backgrounds. Activate with /skin light. Colors use dark browns and deep tones readable on white/cream backgrounds.

[shickylee]

Submitted a fix in PR #4811. Added a built-in "light" skin with dark text colors optimized for light/cream terminal backgrounds. Activate with /skin light. Colors use dark browns and deep tones readable on white/cream backgrounds.

Add auto-detection of system light/dark mode to automatically switch skins

The daylight and warm-lightmode skins are great — but users on macOS with auto-switching theme enabled still have to manually switch skins every time the system switches between light and dark mode.

What's missing: Hermes currently only reads display.skin from config.yaml at startup. There is no code that detects the operating system's current appearance (e.g. reading AppleInterfaceStyle on macOS via defaults read), so the CLI cannot adapt in real time when the system theme changes.

Proposed solution: At startup (and optionally on theme change notification), detect the active OS appearance and auto-select:
- default / slate / ares / etc. for dark mode
- daylight or warm-lightmode for light mode

This would make the UX truly seamless for users who prefer auto-switching themes — which is a common preference on macOS.

[ygd58]

Submitted a fix in #16330 that adds display.skin: auto support.

At startup, Hermes now detects the OS appearance (macOS via defaults read, Linux/GNOME via gsettings, Windows via registry) and automatically selects a light skin (daylight, warm-lightmode, or light) when in light mode, falling back to default for dark/unknown.

Also works at runtime: /skin auto

[pxxxe]

Still shows light input text in light mode

[vikasbnsl]

still broken

[konsisumer]

Thanks for the bumps. PR #9461 (merged) shipped the daylight and warm-lightmode skins, and the live input text color is wired to the active skin's prompt color via hermes_cli/skin_engine.py (input-area prompt_toolkit class). Auto-selection based on OS appearance is being tracked in PR #16330 (still open).

To narrow down what's still unreadable, could the recent reporters confirm:

1. Which skin is active when the input text is unreadable — output of /skin or the display.skin value in ~/.hermes/config.yaml?
2. Whether running /skin daylight (or /skin warm-lightmode) makes the live, typed input text readable on your terminal.
3. Your terminal emulator + theme (e.g. Terminal.app default light, iTerm2 light preset, GNOME Terminal light).
4. Whether the unreadable element is the typed input, the welcome banner, or another part of the UI — a fresh screenshot with a daylight/warm-lightmode skin active would help separate cases.

If daylight / warm-lightmode already make typing readable and the remaining gap is just "I don't want to switch manually," PR #16330 is the right thread to follow. If typed text stays light even under those skins, the answers above will let us reproduce and fix the specific case.