stephenleo/cship: a Rust statusline that ships three installers and two config paths

The curl installer wires the settings file, cargo install does not

Four install routes exist and only two of them finish the job.

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

The script auto-detects the operating system and architecture, covering macOS on arm64 and x86_64 and Linux on x86_64 and aarch64. It downloads the binary to `~/.local/bin/cship`, creates a starter config at `~/.config/cship.toml`, and edits the `statusLine` entry in `~/.claude/settings.json`.

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

The PowerShell route does the equivalent for Windows, installing to `%USERPROFILE%\.local\bin\cship.exe` and registering the statusline in `%USERPROFILE%\.claude\settings.json`. It requires PowerShell 5.1 or later, and unlike the shell script its source can be inspected at the published install.ps1 address before you run it.

The cargo route stops early:

cargo install cship

That one requires the Rust toolchain and installs the binary only. The wiring is left to you as a manual edit, which is stated rather than automated. The reason is structural: a package manager has no business rewriting your Claude settings file, so the shell and PowerShell scripts take on that responsibility and cargo does not.

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

A person who already keeps dotfiles in version control may prefer that, but it is a real behavioral difference between the routes, not just a packaging preference.

Windows ends up with two config locations depending on the route

The Windows story is internally inconsistent, and the inconsistency is visible in the install instructions alone.

The PowerShell installer writes its config to `%USERPROFILE%\.config\cship.toml` and registers the statusline in `%USERPROFILE%\.claude\settings.json`. Both paths sit under the user profile. The documented default config path for Windows matches, also being given as `%USERPROFILE%\.config\cship.toml`, which is consistent with the script.

The manual wiring instructions for a cargo install on Windows point somewhere else entirely, at the settings.json under `%APPDATA%\Claude`. A Windows user who installed the binary with cargo and followed those instructions ends up with a statusline registered in a different Claude settings location than a user who ran the PowerShell script.

Nothing in the visible text explains whether both locations are honored or whether one is legacy. If you already keep a Claude settings file in one of those two places, that is the first thing to check, because an installed-but-unregistered binary looks identical to a broken one. The diagnostic for that is short, since cship --version confirms what is on your PATH:

cship --version   # or: cship -v

and cship explain shows what the process is actually being handed.

Non-interactive installs drop Starship and the secret store silently

Two optional dependencies ride along with the shell installer: Starship, needed for the passthrough modules, and `libsecret-tools` on Linux, needed for usage limits. How they are handled depends on how you invoke the script.

In an interactive terminal it prompts for each one. With an explicit flag it installs them all without asking:

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

With no TTY at all, the behavior is the one that will surprise you. A Docker `RUN` layer or a CI pipeline counts as non-interactive, and there the optional dependencies are skipped automatically. The installer prints instructions for manual installation, but nothing is installed.

The consequence is a statusline that renders but has holes. Without Starship, every `$starship_prompt` token and any embedded Starship module token has nothing behind it. Without `libsecret-tools` on Linux, the usage-limit and account modules have no credential store to read. Neither failure announces itself at render time, because a statusline that cannot resolve a token simply renders less.

So the same one-line command produces three different installations depending on whether a human, a flag or a build system ran it.

The $fill right-alignment assumes 80 columns on Windows

The clearest platform gap in the project is not in the user documentation at all. It is a comment on the terminal-size dependency in Cargo.toml, and it explains itself.

Right-alignment for the `$fill` token needs a terminal width. On Unix, the statusline child process has no tty of its own, so the code walks up to an ancestor's controlling terminal and reads the window size from there. That is why the Unix-only dependency block adds `libc` and `terminal_size`, and why the comment insists on keeping it lean with no build-time toolchain dependencies.

Windows has no equivalent path, so on that platform the width falls back to the configured default of 80. Everything right-aligned will be laid out for an 80-column terminal regardless of how wide the actual window is.

That fallback is invisible in normal use, because it produces a plausible result rather than an error. It only becomes wrong when your terminal is narrower or wider than 80 columns and you have tuned right-aligned segments to sit flush against the edge.

It is also worth noting where the detail lives. A behavior difference between platforms is documented in a build manifest comment pointing at the source module, not in the configuration reference that a user tuning a layout would actually read.

The recommended setup needs a second tool installed and configured

The showcase entry presented as the personal end-to-end setup is built on two config files, not one. The top row is the `$starship_prompt` token, which renders Starship's Catppuccin Powerline preset, and the bottom row holds the native modules.

[cship]
lines = [
  "$starship_prompt",
  "$cship.model $cship.effort $cship.cost $cship.context_bar $cship.usage_limits $cship.peak_usage",
]

Reaching that look therefore requires Starship installed and a `~/.config/starship.toml` written to match, on top of the cship config. Starship is optional in the sense that the binary runs without it, but the recommended configuration cannot be reproduced without it.

The `lines` array is the whole layout model. Each element is a format string mixing `$cship.<module>` tokens with Starship module tokens such as `$git_branch`, so a statusline is assembled by string interpolation rather than by nesting blocks. Per-module sections follow, and each accepts its own symbol and style, with separate style keys where a value escalates, as the effort module does across `low` through `medium`, `high`, `xhigh` and `max`.

The context bar shows how thresholds work. It takes a width, separate filled and empty characters, a format string with a style slot, and numeric warn and critical thresholds, and the documented behavior is that states escalate from cool to warn to critical as budgets fill.

Cost, limits and account tokens read credentials, not just the session

Most modules are passive renderers of Claude Code's JSON feed. Three are not, and they are the ones that need a secret store.

`$cship.usage_limits` covers the five-hour and seven-day windows and picks up per-model and extra-usage detail where available. The window tokens exist separately as `.session` and `.weekly` with `.five_hour` and `.seven_day` as aliases, colored by their own utilization and accepting a `{bar}`. `$cship.usage_limits.per_model` gives a seven-day breakdown across opus, sonnet, cowork and oauth, and `$cship.usage_limits.extra_usage` adds an extra-credits section with an `{active}` indicator. `$cship.account` reports which Anthropic account is authenticated, work or personal, and supports mapping organization names through a `labels` key.

None of that comes from the session transcript. It comes from stored credentials, which is why the Linux optional dependency exists.

The remaining tokens stay local. `$cship.model`, `$cship.cost`, `$cship.context_window` and its `.used_tokens` variant that prints a real count with a percentage, `$cship.context_bar`, `$cship.cost.total_lines_added` and `.total_lines_removed`, `$cship.peak_usage` for US Pacific business hours, `$cship.agent`, `$cship.effort`, `$cship.session` and `$cship.workspace` all derive from the live feed.

The debugging entry point exists for exactly the split above:

cship explain

It prints what cship sees in the context JSON, which separates a module that resolved nothing from a module that has no data to show.

Two releases on one morning, and a manifest that matches the tag

The release cadence is quick. v1.8.3 and v1.8.2 both shipped on 2026-09-06, about forty-seven minutes apart, with v1.8.1 following on 2026-08-04. The last push landed on 2026-09-06 as well, minutes after the v1.8.3 tag, and the repository is not archived.

The manifest agrees with the tags. Cargo.toml reads version 1.8.3 under edition 2024, Apache-2.0, with the repository, homepage and documentation all pointing at cship.dev and github.com/stephenleo/cship. Dependencies are modest and deliberate: clap with derive, serde, serde_json with preserve_order so key order survives parsing, toml, ureq with its json feature, anyhow, thiserror, tracing with an env-filtered subscriber, nu-ansi-term, chrono with clock, unicode-width and schemars.

Two of those choices explain visible behavior. schemars is a schema generator, which is how a config this large gets a machine-readable reference. ureq is a blocking HTTP client, consistent with a statusline that has to answer within its render budget while reaching out for usage data.

Release profile settings are explicit about the performance claim: opt-level 3 with link-time optimization enabled. Development dependencies are rstest, assert_cmd, predicates, tempfile and filetime, with src/ and tests/ as the corresponding directories, plus a docs/ directory, install.sh, install.ps1, a cship.toml at the root for working on the project itself, and AGENTS.md, CLAUDE.md, CHANGELOG.md and CONTRIBUTING.md.

Editorial conclusion

Adopt it if you want a statusline you can tune per module with real thresholds rather than a fixed prompt. Install with the curl or PowerShell script, which wires the settings file for you, and skip cargo install unless you are willing to edit settings by hand. Before you rely on the account and usage-limit modules, confirm a secret store is available, and on Windows do not expect $fill right-alignment to know your real terminal width.

Frequently asked questions

Official sources

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