claude-hl

Syntax colours for shell commands in Claude Code's output. Like Codex does it.

Claude Code shows inline commands in one flat colour. git commit -m "fix" --no-verify is just a string. claude-hl sits between Claude Code and your terminal and paints the command blue, the flags pink, the string gold. Claude Code itself runs unchanged, so hooks, skills, MCP, permissions and /rc all keep working.

Install

Needs a Rust toolchain (rustup.rs).

cargo install --git https://github.com/rashedInt32/claude-hl

That drops claude-hl into ~/.cargo/bin, which rustup already put on your PATH. Or clone and build it yourself:

git clone https://github.com/rashedInt32/claude-hl
cd claude-hl
cargo build --release
cp target/release/claude-hl ~/.local/bin/

One dependency (libc), one 411 KB binary. Built and used on macOS; Linux should work but hasn't been tried.

Use

claude-hl                  # instead of `claude`; any args pass straight through
claude-hl --resume abc123

That's it. There's nothing to configure.

Tweak

claude-hl --selftest prints a sample so you can check colours without starting Claude. claude-hl --themes prints that sample once per theme, so you can pick one by eye. claude-hl --version prints the wrapper's own version; every other argument goes to Claude.

The screenshot at the top is the default codex theme. Here is the same session in tokyonight.

Why is there a remap at all?

Claude Code's inline code (like this) always uses the stock lavender, even with a custom theme. The markdown renderer looks the theme up by name and never sees your overrides. claude-hl already knows every cell's colour, so it swaps that lavender for something that fits each theme. Set your own pair if you disagree with the pick.

Why not a custom frontend?

There are good ones. claude-code-rust is a Ratatui TUI over the Agent SDK with real syntax highlighting on real markdown, and toad does similar over ACP. Editor integrations like CodeCompanion and Sidekick render Claude's output inside a buffer where the editor's own highlighter takes over.

All of them replace the Claude CLI. That's the part I didn't want to give up. The CLI is where hooks, skills, plugins, MCP servers, permission prompts, plan mode, /resume, /plugin, Remote Control and every new feature land first. A frontend has to re-implement each of those or live without it, and it's always a release behind.

claude-hl is the other trade. It gives up knowing the markdown (it only sees rendered ANSI) in exchange for changing nothing else. Claude Code runs exactly as shipped; the wrapper just recolours what's already on screen. If one day Claude Code colours inline commands itself, delete the binary and nothing else changes.

How it works

The child's output passes through byte for byte. Alongside, a small terminal emulator mirrors the screen: cursor, cells, attributes, scroll regions, the alternate screen. After each chunk, rows whose text changed are re-tokenised and only the cells whose colour should differ get rewritten with an absolute cursor move. Then the cursor and attributes are put back.

That design is what makes it stable. Claude Code streams a line in fragments (Ran git, then status, then --short), and a byte-level filter can't colour a fragment it can't see the start of. A screen model can.

Tokens it knows: command (bold), subcommand, flag (--long, -s, -20, +x, --key= with its value painted separately), quoted string, operator (&& || | ; > >> < << 2>&1), path and glob, number and version (5, v1.2.0, 10s), variable ($HOME, $(pwd), PORT=3000), URL (underlined) and a trailing # comment. Prefix runners chain: in sudo systemctl restart nginx both words paint as commands, and so do time, watch, env, xargs.

Prose is the hard part. make sure, go ahead and next step are all valid command shapes. The wrapper uses two signals a byte filter never sees. Claude Code draws inline code in one fixed colour, so a command inside backticks is trusted completely and the highlight stops where the code span stops. Tool recaps start with Ran, so a command after that prefix is trusted too. Anywhere else, a command only paints once a flag, path, string, number or operator turns up; git push --follow-tags in a sentence paints, git status in a sentence does not, and neither does make sure the build passes.

Beyond commands, a second pass paints what the first left alone:

• Paths and URLs anywhere. target/release/build.log, ~/.config/app.toml, README.md, .gitignore, https://docs.rs/libc. A src/main.rs:42:7 reference gets its line number in the number colour. Bare words need a known extension or a leading /, ./ or ~/, so "and/or" and "e.g." stay plain.
• Tool output. Claude Code draws tool results in one flat gray. Inside that gray only, error, FAILED and panicked go red, warning yellow, ok, passed and Done green, numbers and durations (23, 0.42s, 1.2k) get the number colour, and git status --short codes paint by kind. The same words in Claude's prose are left alone.
• Tool lines. ⏺ Read(src/main.rs), ⏺ Bash(cargo test): the tool name in its own colour, the argument as a path or a command.
• Chrome. Box drawing and the ⎿ connector are dimmed when the app drew them in the default colour.

Repaints are cheap on the terminal side: tokens a few cells apart share one cursor move and one SGR, and attributes are emitted as a single sequence.

Limits

It reads rendered ANSI, not markdown. It can't know a fence's language, and it recognises commands by vocabulary, so now and then a prose word gets painted, or an unbackticked git status in a sentence stays plain. That's inherent to the approach. If a real command is missed, add it with CLAUDE_HL_COMMANDS, or to COMMANDS in src/main.rs. cargo test covers the tokenizer and the screen model, so a vocabulary change is easy to check.

The palettes assume a dark background. Claude Code's light themes have no matching palette yet.

License

MIT