Terminal color inversion in dark mode — does not occur when running claude directly

[maxmilneaus]

Bug Description

When running claude directly (no wrapper), the Claude Code TUI renders correctly in Terminal, Ghosty and CMUX. When running claudish, the same Claude Code TUI renders with inverted/unreadable colours — dark text on dark background, selection highlight is the only readable element.

This suggests claudish is passing terminal flags or environment variables that trigger the color bug in Claude Code's TUI, whereas direct claude invocation does not.

Environment

• macOS (latest)
• Claude Code: 2.1.12 (also present in 2.1.86, downgraded to test)
• Terminal: Terminal, Cmux and Ghosty
• Shell: zsh
• Claudish: 6.4.5

Steps to Reproduce

1. Open terminal
2. Run claude directly → TUI renders correctly ✓
3. Run claudish → TUI renders with inverted colours ✗
4. Same terminals, same session — only differs by whether claude is invoked directly or via claudish

Workarounds Attempted

Workaround	Result
TERM=dumb claudish	Does NOT fix
NO_COLOR=1 via claudish	Does NOT fix
FORCE_COLOR=0 via claudish	Does NOT fix
Downgrading Claude Code to 2.1.12	Issue still present
Multiple terminals (iTerm2, Ghostty, Terminal.app)	Same issue in all via claudish

Key Observation

Running claude directly works perfectly. The inversion ONLY happens when invoking via claudish. This is reproducible every time — not intermittent.

Screenshots

[screenshot attached — iTerm2 dark mode via claudish: black text on near-black background]

Possible Cause

Claudish may be setting or overriding terminal capability detection (TERM, TERM_PROGRAM, COLORTERM, etc.) in a way that causes Claude Code's TUI color renderer to behave incorrectly. The TERM=dumb workaround does not fix it, suggesting the issue may be in how claudish initializes the Claude Code subprocess rather than in Claude Code's terminal capability detection itself.

[claudish-bot]

@maxmilneaus I dug into the spawn path in packages/cli/src/claude-runner.ts (line 327-441) and claudish doesn't explicitly touch TERM, COLORTERM, or any color-related env vars — it spreads process.env into a Record<string, string> and passes that as the env option to spawn().

The suspicious part is that passing an explicit env object to spawn() at all (even with ...process.env) can behave differently than letting Node inherit the environment implicitly. There's also the question of whether you're hitting the mtm PTY path (interactive mode uses pty-diag-runner.ts which hardcodes -t xterm-256color) vs the standard stdio: "inherit" fallback.

Could you check two things?

• Does claudish --model <your-model> --no-interactive (or a non-interactive prompt like claudish "say hi") also show the inversion? That would rule out the mtm/PTY path.
• What does claudish --probe <your-model> output? Specifically whether it shows mtm as active.

If it reproduces even in non-interactive mode, the env spread itself is likely the culprit and we'd need to conditionally omit the env option when no overrides are needed.

[maxmilneaus]

Screenshot

The screenshot is available here:

[claudish-bot]

@maxmilneaus Thanks for the screenshot — confirms the inversion is clearly happening.

Would you still be able to check the two things from my earlier comment? Specifically:

• Does it reproduce with a non-interactive invocation like claudish "say hi"?
• What does claudish --probe <your-model> show?

That'll tell us whether it's the mtm/PTY layer or the env-spread in the standard spawn path, which narrows the fix significantly.

[maxmilneaus]

Yes seems limited to the interactive mode.

FYI, when I boot in terminal with just claude, there is no issue.

Claudish "say hi" (non-interactive) → perfect, no inversion. Bug is specifically in the interactive TTY layer. / renders normally.

"claudish --profile fireworks-turbo --model fireworks-turbo "say hi"% xxxxx@Book-Pro ~ % claudish --profile fireworks-turbo --model fireworks-turbo "say hi"
Hi! How can I help you today?"

and in the probe:

[claudish-bot]

@maxmilneaus That narrows it down perfectly — since non-interactive works fine, the issue is in the mtm/PTY layer (packages/cli/src/pty-diag-runner.ts), which hardcodes TERM=xterm-256color when spawning the PTY. That override likely conflicts with iTerm2's dark-mode color reporting.

This is a bug on our side. I'd recommend @jackrudenko take a look at whether we should inherit TERM from the parent environment instead of forcing xterm-256color in the PTY spawn path.