CCometixLine: a Rust statusline for Claude Code with Git and context tracking

What CCometixLine adds to the Claude Code prompt

Claude Code lets you replace its status line with an arbitrary command, and most people point that command at a shell script that prints a few escape sequences. CCometixLine is a compiled Rust binary that fills that slot instead. It reads the JSON payload Claude Code sends on stdin and renders a line containing the working directory, the Git branch with clean/dirty/conflict markers, ahead/behind counts against the tracked remote, a shortened model name, and a context window percentage derived from transcript analysis.

The project is aimed at people who spend their day inside Claude Code in a terminal and want the state of the repository visible without running git status in a second pane. It also bundles a second, unrelated job: patching the Claude Code cli.js file to disable the "Context low" warning and turn on verbose output. Those two roles share one binary, which is the first design decision worth noticing. A status line renderer runs on every prompt refresh and should be cheap; a patcher rewrites a file inside a global npm installation. Keeping them together means the binary needs write access to your Claude Code install if you ever pass --patch, even though the status line path only reads stdin.

The README lists the default segment order as Directory, Git Branch Status, Model, Context Window, with Nerd Font icons throughout. Model names are simplified, so claude-3-5-sonnet renders as Sonnet 3.5 and claude-4-sonnet as Sonnet 4.

How the renderer, TOML config and TUI fit together

The architecture visible in the repository is a single Rust crate named ccometixline that depends on ratatui and crossterm for the interactive interface, serde and toml for configuration, and ureq with semver for update checks. That dependency list tells you the binary does network calls, which matters if you run it in an environment without outbound access.

Configuration lives at ~/.claude/ccline/config.toml, with custom themes in ~/.claude/ccline/themes/*.toml and a separate ~/.claude/ccline/models.toml that the README says is auto-created on first run to control how model names are mapped. Running ccline --init creates the default configuration. The configurable segments are Directory, Git, Model, Usage, Time, Cost and OutputStyle, and each one supports an enable/disable toggle, custom separators and icons, color settings and format options.

When you run the binary with no input it opens an interactive main menu rather than printing a line, and ccline --config opens a TUI editor with a live preview. That is a sensible split: the same executable is both a pipe target for Claude Code and a standalone configuration tool, distinguished by whether stdin carries a payload. The cost is that a misconfigured statusLine command that swallows input will launch a TUI inside your prompt instead of rendering anything, so the first integration attempt is worth testing by hand before you commit it to settings.json.

Installing CCometixLine and wiring it into settings.json

The README recommends npm for installation because it works across platforms. The package is published as @cometix/ccline, and it installs a global command named ccline.

npm install -g @cometix/ccline

After that, the global ccline command is available on your PATH. The README also gives yarn and pnpm equivalents, and an npm mirror flag for faster downloads in some regions.

The next step is telling Claude Code to use it. Add a statusLine block to your Claude Code settings.json. The README marks this cross-platform form as recommended.

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/ccline/ccline",
    "padding": 0
  }
}

The README notes that from Claude Code v2.1.47 onward, Unix-style path parsing works on Windows and the tilde is expanded to your home directory. It explicitly warns not to use %USERPROFILE%, which it says no longer works reliably in that version. If you installed through npm and ccline is on your PATH, the fallback form is simply "command": "ccline".

For a first real use, run the binary without arguments to open the interactive menu, or go straight to the configuration panel to pick a theme.

ccline -c

You should see a TUI with a preview of the status line. Built-in themes named in the README include cometix, minimal, gruvbox, nord and powerline-dark, and you can also select a custom theme file from ~/.claude/ccline/themes/ by name.

ccline --theme gruvbox

A theme passed on the command line overrides the config file for that invocation. Updates go through the same package manager.

npm update -g @cometix/ccline

The README also documents manual installation from GitHub Releases for Linux, macOS (Intel and Apple Silicon) and Windows, plus a cargo build --release path that produces a binary named ccometixline which you copy to ~/.claude/ccline/ccline. The dynamic Linux build requires glibc 2.35 or newer, which the README maps to Ubuntu 22.04+, Debian 11+, CentOS 9+ and RHEL 9+. A static Linux tarball is offered for distributions that do not meet that bar.

The --patch path writes to your Claude Code installation

The enhancement utilities are the part of CCometixLine that deserves the most caution. Running ccline --patch /path/to/claude-code/cli.js disables the context warning and enables verbose mode by modifying that file. The README describes the patcher as surviving Claude Code version updates and says automatic backups make recovery easy.

What the README does not document is a rollback command. It says backups are created, but it does not name a flag to restore one, so recovery appears to mean locating the backup file yourself and copying it back over cli.js. That is a real gap for a tool that edits a globally installed npm package. It also means the patched file is outside the package manager's checksum tracking; a later npm update of Claude Code may replace it, and the README's claim that the patcher survives updates is about re-patching, not about the patch persisting on its own.

The example path in the README points into an fnm-managed Node installation, which is a reminder that the target file lives wherever your Node version manager put the global @anthropic-ai/claude-code package. If you use nvm, fnm, volta or a system Node, that path differs. Passing the wrong path is the obvious failure mode, and the README does not describe what the patcher does when the file it is given is not a Claude Code cli.js. If you only want the status line, skip --patch entirely; nothing in the status line path requires it.

Where CCometixLine is the wrong tool

The binary assumes a Nerd Font is installed and configured in your terminal. The README describes a minimal design built on Nerd Font icons, and the Git indicators are glyphs such as a check mark for clean, a filled circle for dirty, a warning sign for conflicts, and up/down arrows with counts for ahead and behind. On a terminal without a patched font those render as boxes or question marks, and there is no documented fallback mode that swaps them for ASCII.

The second constraint is the Git integration. It reads repository state, and the README does not describe behaviour in a directory that is not a Git repository at all, or in a detached HEAD, or during a rebase or merge with conflicts. The status glyphs imply conflict handling exists, but the documentation does not spell out what the segment shows when there is no branch name to show.

The third is the network dependency. The crate pulls in ureq and semver, which suggests an update check, and the README does not document a flag to disable it. On an air-gapped machine or behind a proxy that blocks the endpoint, that check is either silently skipped or adds latency to a command that runs on every prompt refresh. The README does not say which.

Finally, the licence situation is confusing. The README carries an MIT badge and Cargo.toml declares license = "MIT", while the repository metadata shown alongside the project lists the licence as unknown. Trust Cargo.toml and the badge over the metadata, but if licence terms are a blocker for your organisation, confirm against the repository's own LICENSE file, which does not appear in the top-level listing.

CCometixLine against a hand-written statusline script

The realistic alternative is the shell script most Claude Code users start with: a small bash or Python file that reads the JSON on stdin, calls git rev-parse and git status, and prints a line. The difference in approach is where the work happens. A script shells out to git on every render and depends on whatever jq, git and coreutils are present on the machine; CCometixLine is a single compiled binary that parses the payload itself and ships its own rendering, theme and configuration layers.

That buys you a configuration file and a TUI instead of editing a script, plus model name mapping and transcript-based context tracking that a naive script would have to reimplement. It costs you a build or an npm package, a font requirement, and a binary that does more than render text. A script is easier to audit because you can read all of it in one sitting; CCometixLine is a Rust crate with ratatui, tree-sitter and ureq in its dependency tree, and the README does not publish checksums or signing information for the release archives.

If your needs are a branch name and a directory, the script wins on transparency. If you want context window percentage, theme presets, per-segment colour control and a preview while you edit, the script becomes a project of its own and CCometixLine is the more direct answer.

Maintenance status and upgrade cost

The repository is not archived. The most recent push recorded is 2026-03-14, and the latest release is v1.1.2 on the same date, following v1.1.1 on 2026-02-09 and v1.1.0 on 2026-01-25. That is a cadence of roughly one minor release per month across the visible window, which is worth stating plainly rather than calling the project active.

The upgrade path is cheap if you installed through npm: one command updates the global package. Manual installers re-download a tarball or zip and copy the binary over the old one, which is also mechanical. The expensive part of upgrading is the patch. Every time Claude Code ships a new cli.js, the enhancement utilities have to be re-applied against the new file, and the README's claim that the patcher survives version updates is the thing to verify on your own installation rather than assume. Budget for re-running the patch after each Claude Code release and for keeping the backup files until you have confirmed the new one works.

The dependency list is a second maintenance consideration. ratatui, crossterm, tree-sitter and ureq all move, and the crate pins major versions rather than exact ones, so a cargo build --release today may resolve differently than it did for the v1.1.2 release. If you build from source, commit your Cargo.lock, which the repository does include.

Editorial conclusion

Adopt CCometixLine if you run Claude Code in a terminal with a Nerd Font and want Git state, model name and context usage in one line, and you are comfortable with the tool writing backups before it patches cli.js. Do not adopt it if you need a signed or audited binary, if you cannot install a Nerd Font, or if you are unwilling to re-run the patch after Claude Code updates. Before installing, check the Releases page for a build matching your platform and glibc version, run ccline --init to see the generated config.toml, and inspect the backup files under ~/.claude/ccline before enabling --patch.

Frequently asked questions

Official sources

1. Haleclipse/CCometixLine on GitHub
2. Issues
3. README
4. Releases