BitSquare/Codeman
2
0
Fork 0
mirror of https://github.com/Ark0N/Codeman.git synced 2026-09-30 12:39:42 +02:00
Code Issues Packages Projects Releases Wiki Activity

fix(terminal): read the colour env from the registry on every local spawn path

Browse Source 
buildClaudeEnv(), the direct-PTY fallback taken when mux creation fails, now
reads getCli('claude').env and applies its unset and exports lists. It used to
delete COLORTERM and CLAUDECODE from a hand-maintained list of its own, which
left it contradicting the registry entry that the tmux pane and the attach
client both read. An engine value needing a mux name has nothing to resolve
against on this path, so it is skipped rather than guessed.

Claude no longer unsets NO_COLOR. The invisible-background bug does not need
it, and unsetting it overrides a preference the user set deliberately, so a
user who exports NO_COLOR globally keeps monochrome panes. The other seven
truecolor CLIs still unset it; that inconsistency is intentional and the
comment on the entry says so.

The invariants doc gains a Terminal colour env paragraph under Session launch
modes, where a reader looking up Claude will find it — the previous sentence
sat under a heading that lists only the non-Claude CLIs. It now says the lists
are the stock catalog and a clis.json override replaces them wholesale, and
that the declarations reach the tmux pane, its attach client and the direct
PTY but not a remote pane, whose command carries no env exports at all. Docker
hands COLORTERM=truecolor to every mode, including the two the registry says
must unset it.

The changeset named six peer CLIs and there are seven: deepseek also exports
truecolor. A test beside the existing OpenCode assertion pins the new
behaviour, so a future registry edit cannot make the backgrounds vanish again
in silence.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Michael Grundberg
2026-09-13 14:42:30 +02:00
co-authored by Claude Opus 5
parent 7767b16d4f
commit dae2ac580f
5 changed files with 43 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.changeset/fix-claude-truecolor-in-panes.md
+10 -4
View File
@@ -11,11 +11,17 @@ therefore quantized every RGB color its theme asked for down to the basic palett
`rgb(55, 55, 55)` and every other dark background becomes `ESC[40m` — the terminal's own
black. A custom Claude theme could change the color and nothing on screen moved.
Claude now exports `COLORTERM=truecolor` and unsets `NO_COLOR`, which is what codex, gemini,
antigravity, pi, grok and omp already do. `CLAUDECODE` stays unset, because Claude reads it
as a signal that it is running nested inside itself.
Claude now exports `COLORTERM=truecolor`, which is what codex, gemini, antigravity, pi, grok,
deepseek and omp already do. Those seven also unset `NO_COLOR`; Claude does not, so a user who
exports `NO_COLOR` globally keeps the monochrome panes they asked for. `CLAUDECODE` stays
unset, because Claude reads it as a signal that it is running nested inside itself.
`buildClaudeEnv()`, the direct-PTY fallback used when tmux is unavailable, now reads the same
registry entry as the tmux pane and its attach client instead of deleting `COLORTERM` from a
hand-maintained list of its own. A remote pane still exports nothing — `buildRemoteLaunchCommand()`
never carried these declarations — so an SSH-remote Claude session keeps the old rendering.
PR #3 introduced the `unset COLORTERM` in February, citing xterm.js#484 for the claim that
xterm.js mishandles truecolor. xterm.js closed that issue in April 2019, Codeman now depends
on `@xterm/xterm` 6, and `TmuxManager` sets `terminal-overrides ",*:Tc"` on its own tmux
server, so 24-bit color already reaches the browser for the six CLIs that ask for it.
server, so 24-bit color already reaches the browser for the CLIs that ask for it.