Codeman maintainer
c211461500
#409 (Claude truecolor). The changeset becomes the changelog, and its premise does not hold on tmux 3.2 or newer. Measured here on tmux 3.4: `default-terminal` sits at its compiled default of `tmux-256color`, a live claude pane reports `TERM=tmux-256color`, and supports-color reads that as 256 colors, where rgb(55,55,55) lands on ESC[48;5;237m — visible, just not the color the theme named. The invisible block the PR describes needs TERM to resolve to a 16-color entry: tmux older than 3.2, or a ~/.tmux.conf setting `default-terminal screen`, which Codeman's own tmux server does read (it passes no -f). Both the changeset and the invariants paragraph now say that, so the next report here gets paired with the reporter's tmux -V instead of being read as universal. The change itself stands on the simpler argument: claude was one of two entries not asking for truecolor while twelve do. Also reorders buildClaudeEnv(). It applied the registry's unset/exports AFTER the whole env was built, so a clis.json entry naming CODEMAN_HOOK_SECRET_FILE or PATH would strip it on the direct-PTY path while the tmux pane kept it — buildEnvExports() emits `...cliEnv` ahead of `export CODEMAN_MUX=1` and cannot. The block now runs first and Codeman's own keys are assigned on top, matching the pane. #404 (Ctrl+Z trap). Adds the missing changeset, and records what the trap does not cover: an agent CLI already holds its tty with ISIG off (verified on three live panes: `susp = ^Z -isig -icanon`), so this is defence for the startup window rather than a fix for the steady state, and two input paths still reach the PTY unfiltered — the mobile accessory bar's one-shot Ctrl and the CJK textarea. #399 (path picker sort). The server sorts by name and cuts at 500, so the client sorting those 500 by date gives "the newest of the first 500 by name", which is wrong in exactly the >500-entry folder the date sort exists for. The status line now says "(first 500 by name)" so the cut is legible, with the reasoning parked on _sortEntries. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.5 KiB
aicodeman
| aicodeman |
|---|
| patch |
fix(terminal): let Claude use truecolor so its themed backgrounds render
Claude draws the user's own messages as a block of background color, and it renders as an
approximation of the theme color at best. Claude's registry entry deleted COLORTERM, which
left it the only agent CLI here besides opencode not asking for 24-bit color, so every RGB
color its theme asks for was quantized down to whatever palette TERM alone implies. Claude
now exports COLORTERM=truecolor like codex, gemini, antigravity, pi, grok, deepseek and omp
already do, and the block renders in the color the theme actually names.
How bad the quantization was depends on TERM, which is why this looks different on different
machines. On tmux 3.2 and newer, whose default-terminal defaults to tmux-256color,
supports-color reports 256 colors and rgb(55, 55, 55) lands on ESC[48;5;237m — visible, but
not the color the theme asked for. Where TERM resolves to a 16-color entry instead — tmux
older than 3.2, or a ~/.tmux.conf setting default-terminal screen, which Codeman's tmux
server does read — every dark background collapses to ESC[40m, the terminal's own black, and
the block disappears entirely. That is the case this was reported from, and a custom Claude
theme could change the color there with nothing on screen moving.
Those seven CLIs 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. It applies that entry before assigning Codeman's own
variables, mirroring buildEnvExports(), so a clis.json override naming one of them cannot
strip it on this path while the tmux pane keeps it. 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, and aiming to fall back to 256-color mode. 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 CLIs that ask for it.