CShip: A Starship-Style Statusline for Claude Code Sessions

The gap CShip fills in a Claude Code session

Claude Code exposes a JSON feed describing the live session: model, cost, context window usage, API limits, and more. The README points at the Claude Code status line documentation for the full list, and CShip turns each field into a `$cship.<module>` token. Without a statusline renderer, that data sits in a JSON blob you have to inspect manually. CShip is aimed at engineers who keep Claude Code in a terminal tab all day and want the numbers on screen: how much this session has cost so far, how full the context window is, and whether the 5-hour or 7-day API limit is close.

The audience is narrow on purpose. The README's showcase configs assume a terminal with a Nerd Font, and the recommended setup embeds a Starship prompt alongside native modules. If your workflow is an IDE panel or a web UI, none of this applies. CShip solves a terminal-shaped problem.

How the render pipeline and Starship passthrough work

The architecture is visible in the repository layout and Cargo.toml. `src/` holds the Rust implementation, `cship.toml` at the repository root is the project's own config, and `tests/` plus `install.sh` and `install.ps1` sit alongside. The binary is a single command that Claude Code invokes as its `statusLine` command, receiving context JSON on the way in and printing one or more rendered rows on the way out.

The config model is a `lines` array. Each element is a format string that mixes `$cship.<module>` tokens with Starship module tokens such as `$git_branch`. That mixing is the interesting design choice: CShip does not reimplement git or language-runtime detection. It embeds a Starship module, and the README lists `$starship_prompt` as a token that renders the full configured Starship prompt in one row. So a typical setup is two rows, one delegated to Starship and one built from CShip's own modules for cost, context, and usage limits.

Dependencies in Cargo.toml confirm the shape of the thing. `serde_json` is pulled in with `preserve_order`, which matters when you are reading a feed and want stable field handling. `nu-ansi-term` handles colour output. `ureq` is present for HTTP, which fits the usage-limits modules that need API data. `schemars` suggests generated config schema. Terminal width detection is Unix-only: the comment in Cargo.toml explains that the statusline child has no tty of its own, so the code walks up to an ancestor's controlling tty to read window size, and Windows falls back to config or 80 columns. That is a real platform asymmetry, not a footnote.

Installing CShip and rendering a first statusline

Three install paths exist. The curl installer is the shortest on macOS and Linux. According to the README it auto-detects OS and architecture, downloads the binary to `~/.local/bin/cship`, creates a starter config at `~/.config/cship.toml`, and wires the `statusLine` entry in `~/.claude/settings.json`.

curl -fsSL https://cship.dev/install.sh | bash

After it finishes, restart Claude Code or start a new session. You should see the starter statusline render in place of the default one. Optional dependencies are Starship for passthrough modules and `libsecret-tools` on Linux for usage limits. The README states that an interactive terminal prompts for each, `--yes` installs them without prompting, and a non-interactive environment such as a Docker `RUN` or CI pipeline skips them and prints manual instructions.

curl -fsSL https://cship.dev/install.sh | bash -s -- --yes

On Windows, the PowerShell installer targets PowerShell 5.1 or later. It installs to `%USERPROFILE%\.local\bin\cship.exe`, writes config to `%USERPROFILE%\.config\cship.toml`, and registers the statusline in `%USERPROFILE%\.claude\settings.json`.

irm https://cship.dev/install.ps1 | iex

If you prefer the Rust toolchain, `cargo install cship` works, but the README is explicit that you then wire the statusline yourself. On macOS and Linux that means editing `~/.claude/settings.json`:

{
  "statusLine": { "type": "command", "command": "cship" }
}

On Windows with cargo, the same JSON goes in `%APPDATA%\Claude\settings.json`. Once wired, edit `~/.config/cship.toml`. The `lines` array defines the rows, and each row is a format string of tokens. A minimal first edit is to replace the starter rows with one line that shows model, cost, and context bar, using `$cship.model`, `$cship.cost`, and `$cship.context_bar` as listed in the README's module table. A `cship.toml` in your project root overrides the global config for that project. When a module renders nothing, `cship explain` dumps what CShip sees from the context JSON, and `cship --version` confirms which binary is on your PATH.

Where CShip gets in the way

The installer rewrites `~/.claude/settings.json` to add the `statusLine` entry. That is convenient and also the first thing to check if you already had a statusline configured, because the README does not document a merge or backup step. The cargo path avoids this by leaving wiring to you, at the cost of doing it by hand.

The Unix-only terminal width detection is a genuine functional gap. `$fill` right-alignment depends on reading a controlling tty from an ancestor process, and Cargo.toml states Windows has no equivalent and falls back to config or 80 columns. If your Windows terminal is wider or narrower than that, right-aligned output will not line up.

Usage limits are the other soft spot. They depend on `libsecret-tools` on Linux, and the README says non-interactive installs skip optional dependencies. In a container or CI environment you get a statusline without usage-limit data, and the installer only prints instructions rather than failing loudly. If usage limits are the reason you want CShip, verify them on the target machine before rolling the config out to a team.

Finally, the README does not document rollback. Removing the `statusLine` entry from the settings file is the obvious reversal, but the project does not describe an uninstall command, so plan on editing JSON by hand.

CShip against Starship alone and against Ccstatusline

Starship on its own is a shell prompt, not a Claude Code statusline. It has no notion of session cost or context window usage because it never sees Claude Code's JSON feed. CShip's relationship to Starship is complementary: the README's `$starship_prompt` token renders your existing Starship configuration inside a CShip row, so you keep your git and language modules and add CShip's session modules next to them. Choosing between them is not really the question. The question is whether you want Starship embedded at all, since that pulls in a second binary and its own config file.

Ccstatusline appears in the related searches as another statusline option for the same problem. The repository does not describe its internals, so the honest difference to state is the configuration model: CShip uses Starship-compatible TOML with `$cship.<module>` tokens and a `lines` array, while Ccstatusline's approach is not documented here. If your team already has Starship configs, CShip's passthrough is the concrete reason to prefer it. If you want to avoid TOML entirely, CShip is the wrong direction.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-06. Releases v1.8.3 and v1.8.2 both landed on 2026-09-06, with v1.8.1 on 2026-08-04. Cargo.toml pins the package version at 1.8.3, matching the latest release. That cadence suggests active work, but the upgrade path itself is not described in the README. There is no documented self-update command, so upgrading means rerunning the installer or `cargo install cship` again.

The practical upgrade risk is config drift. Because `cship.toml` is user-owned and the installer writes a starter config, a version bump that adds or renames a module will not migrate your file. `cship explain` is the tool the README offers for diagnosing a module that stopped rendering, and that is the check to run after any upgrade.

CShip is Apache-2.0, which permits commercial use and modification with the usual notice and patent terms. Note that the embedded Starship passthrough runs a separate binary under its own licence, and the optional `libsecret-tools` dependency on Linux is a system package with its own terms. Nothing here is legal advice; read the licence files if you plan to redistribute a bundled binary.

Editorial conclusion

Adopt CShip if you run Claude Code in a terminal, want session cost and context window usage visible without leaving the prompt, and are comfortable editing a TOML file. Skip it if you want a GUI, refuse to install Nerd Fonts for the glyph-based configs, or cannot accept a binary that reads the Claude Code settings file and rewrites the statusLine entry. Before committing, run cship explain against a real session to confirm the modules you care about actually receive data, and check whether your config depends on Starship or libsecret-tools, since the installer skips both in non-interactive environments.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. stephenleo/cship on GitHub