fix(coding-agent): detect GNU screen TERM values and downgrade to 256color (#1809)

GNU screen does not support truecolor escape sequences. When pi emits
truecolor SGR sequences (e.g. \x1b[38;2;102;102;102m for the dim color
#666666), screen misparses the semicolon-separated parameters as
individual SGR codes. The RGB value 102;102;102 maps directly to
SGR 102 (bright green background), which then bleeds into every
subsequent \x1b[2K line-erase, producing a bright green background
on most info/status messages.

detectColorMode() now returns '256color' for any TERM value that is
'screen', starts with 'screen-' (e.g. screen-256color), or starts
with 'screen.' (e.g. screen.xterm-256color). The existing COLORTERM
check at the top of the function already handles the opt-in case for
users who have configured screen's truecolor passthrough.
This commit is contained in:
waldner 2026-03-04 17:50:39 +01:00 committed by GitHub
parent d4b473e298
commit b4f9986d23
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -174,6 +174,11 @@ function detectColorMode(): ColorMode {
if (process.env.TERM_PROGRAM === "Apple_Terminal") { if (process.env.TERM_PROGRAM === "Apple_Terminal") {
return "256color"; return "256color";
} }
// GNU screen doesn't support truecolor unless explicitly opted in via COLORTERM=truecolor.
// TERM under screen is typically "screen", "screen-256color", or "screen.xterm-256color".
if (term === "screen" || term.startsWith("screen-") || term.startsWith("screen.")) {
return "256color";
}
// Assume truecolor for everything else - virtually all modern terminals support it // Assume truecolor for everything else - virtually all modern terminals support it
return "truecolor"; return "truecolor";
} }