hermes - 💡(How to fix) Fix Remote/Docker deployments: skin selection should auto-set TUI light/dark mode base

Summary

When running Hermes in a Docker container or over SSH, the TUI cannot detect the client's terminal background color because:

1. DEFAULT_LIGHT_MODE = detectLightMode() in theme.js is evaluated once at module load — no re-detection ever happens
2. fromSkin() in createGatewayEventHandler.js is called once at session start with the already-computed DEFAULT_LIGHT_MODE
3. OSC11 background probing (tracked in #30092) cannot cross SSH/Docker process boundaries — the terminal is on the client, the Node.js process is on the server

The HERMES_TUI_THEME env var workaround exists but requires external wrapper scripts to detect the client system theme and pass it in at launch. For remote deployments, this is the only option — and it only works at session start, not mid-session.

Problem

When a user sets display.skin = warm-lightmode (or daylight) in their config, they explicitly intend to use a light-background theme. But the TUI's DEFAULT_LIGHT_MODE may still be false (dark) if HERMES_TUI_THEME wasn't set externally — causing the TUI to use DARK_THEME as the base, then apply skin color overrides on top. Colors not explicitly present in the skin definition (e.g., completion menu backgrounds, status bar) fall through to dark defaults.

The Python skin engine knows whether a skin is designed for light or dark backgrounds, but it doesn't communicate this to the Node.js TUI layer.

Suggested Fix

When display.skin is set to a skin that targets light terminals (warm-lightmode, daylight), the Python skin engine should include a light_mode: true flag in the gateway skin config event. The TUI's fromSkin() would use this to select the correct base theme instead of relying solely on DEFAULT_LIGHT_MODE.

This would mean: setting display.skin = warm-lightmode in config.yaml would work correctly without any external HERMES_TUI_THEME wrapper — the skin's intent propagates through the gateway.

Workaround (current)

For remote/Docker deployments, a shell wrapper is needed:

hermes() {
  local mode=$(defaults read -g AppleInterfaceStyle 2>/dev/null | tr '[:upper:]' '[:lower:]')
  if [ -z "$mode" ]; then
    ssh -t n8n "docker exec hermes /opt/hermes/.venv/bin/hermes config set display.skin warm-lightmode; docker exec -it -e HERMES_TUI_THEME=light hermes /opt/hermes/.venv/bin/hermes chat"
  else
    ssh -t n8n "docker exec hermes /opt/hermes/.venv/bin/hermes config set display.skin default; docker exec -it -e HERMES_TUI_THEME=dark hermes /opt/hermes/.venv/bin/hermes chat"
  fi
}

This works at session start. Mid-session theme switches (e.g., automatic sunset transitions in macOS) still require restarting the session.

Related Issues

• #30092 — OSC11 background probe bug on macOS Terminal.app (P2) — same root cause for local users
• #18625 — Auto-switch skin based on system theme (marked dup of #16330)
• #4807 — CLI unreadable on light/cream terminal backgrounds