Claude Powerline: a statusline renderer for Claude Code

The gap between Claude Code's default statusline and a repo-aware one

Claude Code exposes a statusLine hook that runs a command and prints whatever that command returns. The default gives you very little context. Claude Powerline fills that hook with a renderer that assembles segments: current directory, git state, the active model, and usage tracking. The README describes it as a vim-style powerline statusline with real-time usage tracking, git integration and custom themes. The audience is narrow and identifiable: developers who already live inside Claude Code sessions, work in git repositories, and want branch and working-tree state visible at the bottom of the terminal instead of in a second pane. If you do not use Claude Code, nothing here applies to you. The project is TypeScript, MIT-licensed, and published to npm as @owloops/claude-powerline.

How the statusline is produced: a command, not a daemon

There is no background process. Claude Code invokes the configured command, the CLI reads its configuration, resolves the segments that are enabled, formats them with the chosen theme and style, and writes a single line to stdout. That is the whole data flow, and it explains most of the project's behaviour. Config files reload automatically, per the README, with no restart needed, which is consistent with a process that re-reads its inputs on every invocation. The priority chain is stated explicitly: CLI flags beat environment variables, which beat config files, which beat defaults. Config files themselves are ordered: ./.claude-powerline.json for the project, then ~/.claude/claude-powerline.json for the user, then ~/.config/claude-powerline/config.json following the XDG convention. Because each render is a fresh process, anything expensive you ask a segment to compute is paid on every statusline refresh, not once at startup. The README does not document the refresh interval or how Claude Code schedules the hook, so that cost is not quantified in the material.

Two install paths and what each one writes to disk

The recommended path runs inside Claude Code, one command at a time: /plugin marketplace add Owloops/claude-powerline, then /plugin install claude-powerline@claude-powerline, then /powerline. The wizard walks through theme, style, font, segment and budget selection, writes ~/.claude/claude-powerline.json, and updates settings.json. Running /powerline again reconfigures. The manual path is a single block in settings.json: a statusLine object with type set to command and command set to npx -y @owloops/claude-powerline@latest --style=powerline. Note the flags: the default style is minimal, so the powerline look only appears if you pass --style=powerline, and the manual example does. The npx form pulls the latest published version on each run, which means no manual upgrades but also no pinned version. If you want reproducibility, invoke the installed binary directly instead. Requirements are Node.js 18+, Claude Code, and Git 2.0+. For symbols, install a Nerd Font or pass --charset=text for ASCII-only output.

The git segment is where the configuration depth actually lives

Everything else in the config surface is a toggle; the git segment is a set of independent switches. showSha, showWorkingTree, showOperation, showTag, showTimeSinceCommit, showStashCount, showAheadBehind, showUpstream, showRepoName and showWorktree each control one piece of output. The README is unusually precise about two of them: showUpstream controls the branch name only, while showAheadBehind controls the arrows, and the defaults already give you arrows without the name, so setting showAheadBehind to false is how you remove them. showWorktree defaults to whatever showRepoName is, which means the worktree indicator appears as a side effect unless you set it explicitly. That is a small design wart worth knowing before you wonder why an extra symbol showed up. The directory segment has its own style option with three values: full for the complete path, fish for fish-shell abbreviation, and basename for just the folder name. In worktree sessions the directory segment shows the original repo path instead of the worktree folder, with no configuration required.

Symbol sets, fonts, and the cost of not having a Nerd Font

The statusline uses Unicode glyphs by default: a branch marker, a SHA marker, a tag marker, a stash marker, clean and dirty indicators, conflict and ahead/behind arrows, a worktree indicator, and a staged/unstaged/untracked triple in the form (+1 ~2 ?3). Without a Nerd Font these may not render as intended. The escape hatch is --charset=text, which substitutes ASCII equivalents: ~ for branch, # for SHA, T for tag, S for stash, = for clean, * for dirty, ! for conflicts, ^3 ahead, v2 behind, W for worktree. The triple stays the same. This is a real constraint rather than a footnote. If your terminal font is fixed by policy or habit, you are choosing between installing a font and accepting a visibly plainer bar. The README does not describe how the text charset interacts with each theme, so how legible the ASCII variant looks in, say, gruvbox is something you would have to check yourself.

Where the project is thin, and when it is the wrong tool

The README is a configuration reference, not a design document. It does not explain how usage tracking is collected, what it counts, or where those numbers come from, despite listing usage tracking as a headline feature. It does not state the refresh cadence of the statusline, so you cannot reason about the cost of an expensive segment from the documentation alone. It does not describe behaviour when git is absent or when the current directory is not a repository. The git segment is also the reason many people would install this, and it is the reason some should not: outside a repository, or in a repository where you rarely care about branch state, you are paying for a process launch and a config file to render a directory name and a model name. There is a second, quieter trade-off. The manual setup command uses npx with @latest, which means the code that renders your statusline can change between sessions without any action from you. That is convenient and also the opposite of reproducible.

Powerline Studio and the alternative it is meant to replace

powerline.owloops.com is a visual configurator. You click segments in a preview to toggle options, switch styles and themes live, reorder them, then copy or download the resulting JSON into ~/.claude/claude-powerline.json. It also accepts a pasted existing config for editing. The alternative approach is to write that statusLine command yourself: a small shell script that calls git rev-parse --abbrev-ref HEAD, reads the Claude Code JSON that the hook passes in, and prints a string. That script has no dependency beyond git and the shell, needs no config file, and cannot change version underneath you. What it will not give you is the segment set, the six built-in themes (dark, light, nord, tokyo-night, rose-pine, gruvbox), the four styles (minimal, powerline, capsule, tui), the worktree handling, or the visual configurator. The honest split is that claude-powerline is a packaged renderer with a schema, and a hand-written script is a few lines you fully control. If you want the bar to look a particular way and stay that way, the script wins on predictability; if you want to try themes and reorder segments without editing JSON by hand, the Studio and the CLI win on iteration speed.

Versioning, licence and what maintenance looks like

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the extent of what can be said here; anything beyond it is a question for your own legal review. On maintenance, the observable signal is release cadence: v1.30.1, v1.30.2 and v1.30.3, with the last two published minutes apart on the same day, and the most recent push to main dated 2026-09-06. Patch releases landing in pairs suggest quick follow-up fixes rather than a slow release train, though the material does not say what changed in any of them. The upgrade cost depends on which install path you chose. The wizard path writes a config file and edits settings.json, so upgrades are whatever the plugin mechanism does. The npx @latest path upgrades on every invocation by construction. The pinned-binary path upgrades when you choose to. Only the last one gives you a version you can name in a bug report.

Editorial conclusion

Adopt it if you already run Claude Code in a git repository and want branch, ahead/behind and working-tree state visible without leaving the session; the wizard path and the manual statusLine command in settings.json are both short. Skip it if you work mostly outside git repositories, since the git segment is the bulk of the added value, or if you cannot install a Nerd Font and do not want the reduced symbol set that --charset=text gives you. Before committing, verify three things: that Node.js is at least 18 and Git at least 2.0 on the machine, which of the three config paths wins in your setup (project .claude-powerline.json beats ~/.claude/claude-powerline.json beats the XDG path), and whether the npx -y @owloops/claude-powerline@latest command in settings.json is acceptable to you, because it fetches the latest published version on each invocation rather than a pinned one.

Official sources

1. License: MIT
2. Owloops/claude-powerline on GitHub
3. Project website
4. README
5. Releases