[BUG] Claude Code in CLI does not (always) correctly display color

Status Open
Reported on v2.1.210
Maintainer reply None cached
Activity 0 comments · opened Jul 16, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code in CLI does not (always) correctly display color. This affects some color expression in the tool itself, though not all, and it affects color rendition by statusline extensions. As has become common, some of Claude Code's tooling just fires out color codes without checking what the terminal supports. (That's an error, but not the bug I'm reporting.) Other parts however do it correctly and only issue what the terminal type claims support for.

When I set COLORCODE=truecolor in the environment, or if I set TERM=xterm[-256color], I get colors. Using my terminal's terminal type I do not. Because my terminal emulator asserts COLORTERM in its local shell, I don't typically see this problem until I run Claude Code over SSH. SSH sends and accepts TERM natively, but does not naturally/by default accept COLORTERM even if you tell the SSH client to send it. Result: terminfo-aware applications show color fine, but Claude Code does not.

What Should Happen?

Claude should fully render color if TERM is set to a terminal type that a local terminfo file describes as supporting color.

Error Messages/Logs

Steps to Reproduce

  1. Create a replica terminal type with color support: infocmp xterm-256color | sed -e '/^#/d;s/^x.*/faketerm,/' | tic -
  2. Set your terminal type: export TERM=faketerm
  3. Verify that terminfo applications work: echo "$(tput setaf 1)this is red$(tput sgr0)"
  4. Construct several limited environments (free of red herrings) and run claude, observing color behavior:
    env -i "PATH=$PATH" HOME=$HOME TERM=$TERM COLORTERM=truecolor claude     # shows color
    env -i "PATH=$PATH" HOME=$HOME TERM=$TERM TERM_PROGRAM=iTerm.app claude  # shows color
    env -i "PATH=$PATH" HOME=$HOME TERM=$TERM claude                         # no color
    env -i "PATH=$PATH" HOME=$HOME TERM=xterm claude                         # shows color

Claude Model

Sonnet (default) (but not applicable)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.210 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2 (but not applicable)

Additional Information

Claude itself suggested that the fault may lie with chalk/supports-color. I can't validate whether that's the cause because it's in Claude's closed source arena, but it is a problem in that code. However the chalk maintainers say this is a feature, and aren't planning to fix it (https://github.com/chalk/supports-color/issues/167).

So, if that is indeed a cause of this issue, please adopt terminal color capability detection that uses terminfo correctly. https://github.com/nberlette/terminfo/ might be an option.

Even with that fixed, there might be a different problem on MacOS, where local terminfos exist (and should be used) but the same, equivalent terminfo doesn't necessarily exist inside the Ubuntu VM. In this case it should be feasible to mount the correct terminfo into the container, or else to propagate it from MacOS with something like TERMINFO=$(infocmp -0 -Q 2).

The current workaround for this issue is to artificially set TERM to some alternative terminal type string that is similar enough to one's actual terminal, or to set COLORTERM=truecolor even though the shell environment may not know whether the terminal supports true color. Either of these can lead to incorrect behavior since the actual defined behavior of a terminal is described exclusively by its terminfo data, not by its name or other environment properties.

View original on GitHub ↗