Prompt mode colors (plan/autopilot) render as bold white in tmux-over-SSH since v1.0.4

[maxned]

Prompt mode colors (plan/autopilot) render as bold white in tmux-over-SSH since v1.0.7

Description

Since v1.0.7 the prompt mode labels and chevron/border no longer display their expected colors in a tmux-over-SSH terminal setup. They render as bold white instead.

• Plan mode — should be cyan, renders as bold white
• Autopilot mode — should be green, renders as bold white

The /theme command and FORCE_COLOR=3 environment variable do not resolve the issue.

Environment

• CLI version: 1.0.7
• OS: Linux (remote VM via SSH)
• Terminal: iTerm2 (macOS) → SSH → tmux
• TERM: xterm-256color (confirmed in outer shell before launching copilot)
• Config: "theme": "dark" in ~/.copilot/config.json
• Color support: Full ANSI color works in the same terminal for all other applications

Steps to Reproduce

1. SSH into a Linux host from iTerm2
2. Inside a tmux session, run copilot
3. Press Shift+Tab to switch to plan or autopilot mode
4. Observe the mode label in the footer bar and the chevron/border — they are bold white instead of cyan/green

Expected Behavior

• Plan mode label and border: cyan (theme SELECTED)
• Autopilot mode label and border: green (theme SUCCESS)

This worked correctly prior to v1.0.4.

Root Cause Analysis

Claude Opus 4.6 traced through the minified index.js and identified the issue in the ThemeProvider component:

1. On mount, the ThemeProvider calls p("auto", columns) which probes the terminal's ANSI color palette via OSC 4 escape sequences.
2. If terminalColors is detected, it uses sat(terminalColors, isDark) to build the palette from the terminal's actual color values, and sets a lock flag (zPr = true).
3. The lock flag causes subsequent theme applications (including the user's saved "dark" preference) to return early from p() via if (zPr && !w) return.
4. While the React state (an().theme) is correctly updated to the "dark" theme with SELECTED: "cyan" and SUCCESS: "green", the underlying Ink rendering layer may still reflect the degraded auto-detected palette.

The likely failure point: tmux does not reliably forward OSC 4 color query responses back to the outer terminal (iTerm2). When the adaptive color engine's probing fails or times out, the "graceful degradation" path produces a colorless or incorrect palette, overriding the explicit "dark" theme preference.

Suggested Fix

1. When OSC 4 probing fails or times out, fall back to named ANSI colors (cyan, green, etc.) rather than degrading to colorless output.
2. An explicit user theme preference (e.g., "theme": "dark") should take priority over auto-detection results.
3. Consider detecting tmux ($TMUX env var) and skipping OSC 4 probing, since tmux's OSC forwarding is unreliable.

Relevant Changelog Entries

• v1.0.4: "Adaptive color engine with dynamic color modes and interactive theme picker. Gracefully degrades on limited-color terminals and Windows"
• v1.0.7: "Improve color contrast across CLI themes for better readability and accessibility"

[rumeetgoradia]

Seeing same with Git Bash on windows, whether that's through the Windows Terminal or the Git Bash terminal emulator itself