Changelog

September 16, 2026 · View on GitHub

All notable changes to claude-statusbar are documented here. The format loosely follows Keep a Changelog and the project uses Semantic Versioning.

For a quick overview of the latest release, see the GitHub releases page.

v3.43.2 — 2026-09-16

Two Claude Code profiles no longer share one usage bucket.

A second profile launched with CLAUDE_CONFIG_DIR has its own login, but the account uuid was always read from ~/.claude.json, so both profiles resolved to the default account and shared one rate_latest bucket — whichever session rendered last set the 5h/7d figures for both bars. The config dir now comes from the session's transcript_path (which is also correct inside the daemon, where one process renders many sessions), and is carried through the reconcile, forecast and projection stores plus the 1s result cache. Thanks @kossolax for the report and the fix (#54, #55).
Follow-up: the default profile keeps its transcripts in ~/.claude/ but its login beside that dir at ~/.claude.json, unlike a CLAUDE_CONFIG_DIR profile which keeps both inside. The login is now looked up in both places, so ordinary single-profile users keep their per-account store instead of falling back to the legacy shared one.

v3.43.1 — 2026-09-13

The ocs address gets its own line.

ocs boss · claude-7d5a5d07 (show_ocs) now always renders on its own line instead of trailing the branch line — it's an address other agents copy, not branch info, and it no longer crowds the project/branch line.
Verified with the real ocs 0.5.0: after ocs rename, the new name reached the status line within ~17s (cache TTL 30s).

v3.43.0 — 2026-09-13

ocs address on the branch line, so other agents can find this session.

New segment ocs boss · claude-7d5a5d07 (show_ocs, on by default): this session's open-cross-session name (from ocs rename) and stable id — both work with ocs dm / @. Without a name it shows just the id; when ocs reports no id it falls back to the session address.
Appears only when ocs ≥ 0.5.0 is installed (PATH or ~/.local/bin/ocs) and knows the session; otherwise hidden with no cost beyond a PATH lookup.
Uses only ocs whoami --json --session <id>, run in the background (daemon thread pool / detached subprocess) and cached per session for 30s — the render never waits on ocs, and a rename shows up within half a minute. Output is sanitized (printable, ≤64 chars) before it reaches the terminal.
Turn it off with cs config set show_ocs false.

v3.40.1 — 2026-08-26

A binary install asks GitHub whether it's current, not PyPI.

The standalone binary is downloaded from GitHub Releases, but the version check queried PyPI — the wrong service, and a slow one: PyPI's JSON index updates asynchronously after an upload, so for a minute or two after every release cs upgrade answered with the version it had just replaced. That happened five times in one afternoon, twice sending a maintainer looking for a bug that wasn't there. The v3.35.x cache-buster only defeated the CDN edge, not PyPI's own indexing delay.

Frozen installs now read releases/latest from the GitHub API and fall back to PyPI if that fails; pip / uv / pipx installs still ask PyPI, which is correctly their channel.

v3.40.0 — 2026-08-26

⑂ is the default glyph now — the one that can actually take your theme color.

v3.38.0 made the marker 🌲 because a worktree is a tree. v3.39.0 found the flaw: an emoji is drawn by the emoji font in the font's own colors, so the theme's worktree hue (and color_worktree) reached only the text beside it, never the glyph — in a marker whose entire premise was "the worktree needs a color". The default is now ⑂ (OCR fork): one cell instead of two, VCS-native, and it takes the hue like everything else on the line.

The tree is still one cs config set worktree_glyph 🌲 away, along with ⋔, ├, ⧉, or anything else that fits in two terminal cells.

Anyone who had already set worktree_glyph keeps their choice — the config stores only what you changed, so this new default reaches exactly the people who never expressed a preference.

v3.39.0 — 2026-08-26

Pick your own worktree glyph — because 🌲 can't take your theme's color.

An emoji is drawn by the emoji font in the font's own colors. theme.wt (and color_worktree) therefore reach only the text beside 🌲, never the glyph — which sits awkwardly with the reason the marker exists: the very first request for this feature was "the worktree needs a color". On the light themes (linen, sakura) the fixed emoji green is the wrong note entirely.

worktree_glyph (default 🌲) takes any 1-2 cell symbol:

cs config set worktree_glyph ⑂     # OCR fork — VCS-native, takes the theme color
cs config set worktree_glyph ⋔     # pitchfork
cs config set worktree_glyph ├     # file-tree feel
cs config set worktree_glyph ⧉     # the pre-3.38 overlapping squares
cs config set worktree_glyph 🌳    # a different tree

Anything wider than two terminal cells is refused at set time rather than quietly breaking the line's width budget.

v3.38.0 — 2026-08-26

A tree, for the thing called a worktree.

The marker was ⧉ (overlapping squares) in a worktree and ⌂ (a house) in the main checkout — two glyphs, neither of which says "tree", for a feature whose whole subject is git work trees. Both are now 🌲, and the name after it says which tree you're standing in:

🌲 wt-party-slot (3)  ⤷ repo  ⎇ feature-branch    ← inside that worktree
🌲 trunk (3)          ⤷ repo  ⎇ main              ← the main checkout, 3 worktrees exist
🌲 trunk (0)          ⤷ repo  ⎇ main              ← no worktrees at all

trunk rather than main, so it never reads as a duplicate of a branch also called main. The worktree form keeps the full worktree hue; the trunk form stays dimmed, because standing in the trunk is the ordinary case.

The glyph is two terminal cells wide, like the ⏰ the bar already uses; the width-aware clipping accounts for it.

v3.37.1 — 2026-08-26

⌂ (0) — a repo with no worktrees says zero instead of saying nothing.

v3.37.0 showed the count only when there was one, which recreated the exact ambiguity it set out to remove: an absent marker and a count of zero look identical, so "is this broken or is it just zero?" is unanswerable from the bar. Every git checkout now carries the marker; only a non-git directory has none (it already says (no git)).

v3.37.0 — 2026-08-26

The main checkout says how many worktrees are waiting, instead of saying nothing.

v3.33.0 put a ⧉ marker on linked worktrees and left the main checkout bare, on the reasoning that "you are in the main tree" is not news. But silence is also what a broken feature looks like: the same user asked three times why they couldn't see the worktree segment — each time from a main checkout, each time with the feature working exactly as designed.

The main checkout of a repo that has linked worktrees now opens with a dimmed ⌂ (3): you are in the main tree, and three parallel checkouts exist. A repo with no worktrees still shows nothing, because there is nothing to say.

⧉ wt-party-slot (3)  ⤷ repo  ⎇ feature-branch      ← inside a worktree
⌂ (3)                ⤷ repo  ⎇ main                ← the main checkout
                     ⤷ repo  ⎇ main                ← a repo with no worktrees

Dimmed on purpose: being in the main tree is the ordinary case, and only the ⧉ form is a warning worth the full-hue treatment.

v3.36.0 — 2026-08-25

The standalone binary keeps itself up to date now, like every other install.

Binary installs were the one channel excluded from the daily background upgrade: the rule was "never pipe curl|sh behind the user's back". Two things changed that calculus — the upgrade is now pinned to a specific release tag and verifies what actually landed (v3.35.4), so an unattended run can no longer leave a different build behind; and being excluded meant binary users sat on stale versions indefinitely, which is its own kind of harm.

Auto-upgrade runs once a day in a detached process, on every channel.
It still refuses when this copy doesn't own the cs on PATH — upgrading a duplicate would hijack someone else's install (v3.35.2).
New auto_upgrade config key (default true) turns it off without an env var: cs config set auto_upgrade false. CLAUDE_STATUSBAR_NO_UPDATE=1 still overrides everything.

The installer no longer deletes the bundle the upgrade is running from. prune_old_bundles removed every previous onedir version on the assumption that nothing could still be inside one. An unattended upgrade is inside one, and a PyInstaller onedir binary dlopens its libraries lazily — pruning it mid-run could kill the upgrade in progress. The updater passes its own bundle in CS_KEEP_BUNDLE_DIR; the next upgrade collects it once it is empty.

v3.35.4 — 2026-08-25

The upgrade now checks what it installed instead of announcing what it meant to.

v3.35.3 made cs upgrade run the installer. On its first real run the installer fetched from releases/latest/download — a pointer that lags for a while after publishing — and re-installed the version being upgraded away from, while cs upgrade reported "Upgraded to v3.35.3." Exit code 0, wrong binary, confident message.

The upgrade pins the download to the tag it decided on (releases/download/v<version>), so it can't be handed a stale asset.
Afterwards it asks the installed cs for its version and compares. A mismatch is reported as a failure that says which version actually landed, not as success.
install.sh prints the version it just linked, so the same mistake is visible from the outside too.

v3.35.3 — 2026-08-25

cs upgrade now upgrades a standalone binary instead of describing how.

On a binary install the command printed the curl … install.sh | bash line and exited — a command named after an action it did not perform. Run it, check cs --version, and nothing had changed. The rule it was honoring ("never pipe curl|sh behind the user's back") is about unattended upgrades; typing cs upgrade is the consent that rule exists to protect. auto_upgrade still refuses to touch a frozen install, which is the case that actually runs unattended.

Up to date → says so and exits 0, without printing an install command you don't need.
Newer release → runs the installer, streaming its output so you watch it work, then tells you to restart Claude Code.
Version check failed → refuses to reinstall on the strength of an answer it never got, and hands you the manual command.

v3.35.2 — 2026-08-25

A leftover uv install can take over your binary install, silently.

Every installation channel puts its entry point at the same place — ~/.local/bin/cs. A uv tool install claude-statusbar from months ago sits harmlessly behind a standalone binary until the day it auto-upgrades: uv then rewrites that symlink to its own copy, and cs is a different install than it was yesterday. Nothing announces it. Seen live on one machine — twice in ten minutes, the second time re-creating a copy that had just been uninstalled, because a still-running daemon from the old copy ran the upgrade.

A copy that doesn't own cs no longer auto-upgrades. It would be upgrading itself into someone else's install. An explicit cs upgrade still does what you ask.
cs doctor lists duplicate installs when it finds more than one, naming each, because "whichever upgrades last wins" is not something you can debug without being told it's happening.
install.sh warns when a uv/pipx copy is present and prints the exact uninstall command. It does not remove another package manager's package on its own.

v3.35.1 — 2026-08-25

v3.35.0 handed the daemon to launchd; a render tick took it straight back.

cs --setup now kickstarts the service's own job — but one second later a status-line tick found the pidfile briefly free and lazy-spawned a competing daemon, which won it. launchd's instance exited 0 "already running" and stood down again, leaving the same unsupervised daemon v3.35.0 set out to fix. The lazy-spawn path now asks the service manager to start its job instead of racing it (falling back to a direct spawn only if the service manager refuses — an unsupervised daemon still beats no status bar).

Both shipped docs had a second copy that drifted. skills/ and commands/ at the repo root (what GitHub and npx skills add serve) are separate files from src/claude_statusbar/skills|commands/ (what the wheel and the binary install), with no sync step. The packaged SKILL.md had a dozen toggles the GitHub copy never mentioned; the packaged statusbar-doctor.md was still telling agents to fix a broken install with pip install -U claude-statusbar, which does nothing for a binary install. Both are back in sync, and a test now fails if they drift again.

Seven config keys were documented nowhere. show_cwd, show_ip_risk, show_fp_risk, show_balance, balance_bar, show_projection and color_worktree existed only in the code and docs/; the skill an agent actually reads never mentioned them. Added.

v3.35.0 — 2026-08-25

Three things that had been quietly wrong, all the same shape: the code couldn't tell your intent from its own staleness, so it froze — and blamed you.

Slash commands and the skill were frozen at whatever version you installed first. install_skills compared the file on disk to the currently bundled copy: shipping a newer SKILL.md looked exactly like a user edit, so it was kept — and the installer announced, every single upgrade, that it was preserving "your edited skill". One install sat at v3.5.0 for 29 releases, missing 13 config keys that had shipped since; the agent reading that skill had no idea show_project_branch, show_ip_risk, api_mode or color_worktree existed. The installer now records a checksum of everything it writes, so an upgrade can tell "we wrote this and you never touched it" (replace it) from "you edited this" (keep it). Files predating the manifest have unknown provenance: they are still kept, but the message says that plainly instead of asserting an edit you never made. cs --setup --force takes the shipped version.

A daemon with a LaunchAgent installed was running unsupervised. Setup spawned its own detached daemon, which took the pidfile; launchd's own job then exited 0 and stood down — correct behavior for KeepAlive: {SuccessfulExit: false}, which exists to stop a restart loop. The result was a live daemon nothing would restart, while cs daemon install had promised exactly that. Setup now hands the process to the service manager (launchctl kickstart -k / systemctl --user restart) whenever one is installed, instead of racing it.

cs doctor printed a green ✓ next to "launchd state: not running". It had two states, ✓ and ✗, so "working, but not the way it claims" had nowhere to go. There is now a third: a yellow ! for exactly that case, naming the fix.

Also: the PyPI version check appends a cache-buster. pypi.org/pypi/<pkg>/json sits behind a CDN that can serve a stale info.version for minutes after a release — long enough for cs upgrade, run right after publishing, to report the version it just replaced.

v3.34.0 — 2026-08-25

Your config now stores only what you changed — so improved defaults actually reach you.

Every save used to dump all ~35 keys to JSON. One cs config set style capsule froze whatever the defaults happened to be that day, and every later change to a default was invisible to you forever. show_project_branch shipped default off and flipped to on hours later: anyone who wrote a config in that window kept the project/branch line hidden for months, with nothing in the file or the UI to explain why.

Sparse storage. Only values that differ from the default are written. A key you never touched stays out of the file and keeps following the code, so it moves when the default moves. Your existing file is rewritten on the next cs config set — values are preserved exactly; only the redundant ones disappear.
cs config unset <key>. The counterpart to set: drops a key so it follows the default again. With sparse storage "no opinion" is finally a state the file can express.
cs config show says which is which. Values that merely follow the default are marked (default); anything unmarked is a choice you stored. A stale value can no longer masquerade as a default.

Old full-dump config files keep working unchanged. Their stored values still win — a deliberate false and a frozen old default are indistinguishable, so nothing is guessed on your behalf; cs config show now makes them visible and cs config unset clears the ones you didn't mean.

v3.33.1 — 2026-08-25

The standalone binary could not make a single HTTPS request — and said so nowhere.

PyInstaller bundles OpenSSL but not a certificate store, so the frozen cs looked for CAs at the build runner's compile-time path, which does not exist on any user machine. Every HTTPS call failed certificate verification, and since each call site swallows network errors, the failures were invisible:

cs upgrade answered "is up to date (per PyPI)" no matter how many releases had shipped since.
The ↑<newver> update hint never appeared for binary users.
The IP-risk probe cached nothing but {"ok": false}; relay-balance lookups had the same fate.

Fixed at the one place every invocation passes through — the frozen entry point now points SSL_CERT_FILE at a CA store that exists: certifi's bundle (now shipped inside the binary), falling back to the platform's system store. The -m self-spawns inherit it. An explicit SSL_CERT_FILE / SSL_CERT_DIR from the user is never overridden.

And cs upgrade no longer reports an unreachable PyPI as good news — a check that never completed now says so, instead of claiming you are up to date.

If you are on a binary at v3.33.0 or older, cs upgrade cannot tell you about this release — that is the bug. Re-run the installer once:

curl -fsSL https://raw.githubusercontent.com/leeguooooo/claude-code-usage-bar/main/install.sh | bash

pip / uv / pipx installs were never affected.

v3.33.0 — 2026-08-25

The identity line now opens with the git worktree you're actually in.

A linked worktree used to render as a mute [worktree] tag tucked in after the branch — the same grey as the separators around it, i.e. invisible exactly when it mattered. It now leads the line, in a hue of its own, carrying the worktree's name and how many worktrees the repo has in total:

⧉ wt-party-slot (3)  ⤷ claude-code-usage-bar  ⎇ codex/party-status-slot-isolation ●

Its own color. Theme gained a wt field, set per theme (violet on graphite/dracula/catppuccin/tokyo-night, cyan on the already-purple twilight, deep violet on the light linen/sakura, grey on mono). "This is not the main checkout" is a different kind of fact from ok/warn/hot and must not be read as a severity. Override with cs config set color_worktree "#bd93f9".
The name is read from disk, not from stdin. Claude Code only sends workspace.git_worktree for worktrees it created itself, so hand-made git worktree add checkouts showed nothing. The name now comes from the gitdir: path in the checkout's .git file, which is always there.
(3) is the repo's worktree total, counted from .git/worktrees/. Entries whose checkout has been deleted but never pruned are excluded — a number you can't trust is worse on a status line than no number.
Less repetition. A redundant repo prefix is trimmed (repo-wt-x → wt-x), and a name that would only repeat the branch or the repo collapses to a bare ⧉ worktree.
The repo stays the anchor. Inside a worktree without a repo name on stdin, the project used to render as the worktree's own directory name; it now resolves to the main repo's name.

Pure filesystem work — no git subprocess, ~0.3 ms per render.

v3.32.5 — 2026-08-20

Fresh legacy _MEI* leftovers now age out automatically after upgrade.

The v3.32.4 installer safely skipped runtime directories younger than ten minutes, but its cleanup ran only once. The onedir daemon now retries the same fail-closed cleanup at startup and every 30 minutes, so directories that were too fresh during installation are removed after they become eligible.

v3.32.4 — 2026-08-20

Standalone installs no longer leak PyInstaller _MEI* runtimes on every status refresh.

The macOS release binary included Python and PyObjC in PyInstaller onefile mode. cs render runs once per second, so each tick first extracted roughly 11 MB into the user temp directory. A status-line timeout could kill the bootloader before its exit cleanup, leaving thousands of _MEI* directories and tens of gigabytes behind.

Release assets now contain a self-contained PyInstaller onedir bundle. The CLI still needs no system Python, but the 1 Hz render path reuses the installed runtime instead of extracting a new copy.
install.sh installs content-addressed versions below ~/.local/lib/claude-statusbar, atomically switches ~/.local/bin/cs, starts the new daemon, and removes superseded bundles only after setup succeeds.
After an onedir upgrade, the installer removes legacy cs _MEI* orphans. Cleanup is macOS-only and fail-closed: it requires the old Python/PyObjC signature, a ten-minute age, a leak cohort, current-user ownership, and an lsof snapshot proving that no process has the directory open.

Windows: statusLine no longer written (or daily-reverted) to a shell-dead backslash path (#42).

Claude Code executes the statusLine command through a POSIX shell (Git Bash on Windows), where \ is an escape character — C:\Users\me\cs.EXE execs as C:Usersmecs.EXE and dies with exit 127 even though the file exists. _resolve_cs_command() returned shutil.which()'s backslash path verbatim, so on Windows the bar was broken from the very first write, and the daily self-heal reverted any hand-fix within 24h because it compared command strings for equality against that same poisoned path.

Paths are now written with forward slashes (valid in sh and cmd.exe), double-quoted when they contain spaces (double because cmd.exe has no single-quote semantics).
The daily self-heal now repairs only broken entries instead of anything that differs from today's canonical form: a working hand-fix, the fast/inline choice, and user-added CLI flags all survive. Repairs replace only the executable token — the argument tail is preserved verbatim (the old pass silently stripped flags like --no-auto-update). Bare cs is still upgraded to an absolute path once (GUI-launched Claude Code PATH gaps), and dead paths are still re-resolved.
Already-poisoned installs heal themselves on the next daily pass: a backslash executable is rewritten in place to forward slashes.
cs doctor gained a statusLine shell test: it runs the configured settings.json command string through sh — the render smoke test builds its own argv, which is exactly why this class of breakage stayed invisible. On Windows a backslash command is flagged statically.

v3.32.3 — 2026-07-27

Installer polish — three papercuts visible on every re-install.

install.sh ended with bash: line 1: tmp: unbound variable. The cleanup trap referenced a variable declared local inside the download function, so by the time the EXIT trap fired it was out of scope — which under set -u errored and meant the downloaded tarball's temp dir was never cleaned up. The scratch dir is now a global with a proper cleanup trap.
cs --setup reported an issue was printed on every re-install even when everything succeeded. Setup lumped "this file exists with your edits, so we kept it" — a benign, expected outcome when re-running the installer — into the same bucket as genuine copy failures. Skipped and failed are now separate, and only real failures affect the exit code. The status was also computed inside an if verbose: block, so the same run returned 0 quietly and 1 verbosely; it no longer depends on verbosity.
cs hud printed its install/uninstall/stop messages and errors in Chinese inside an otherwise English installer — leftovers from the v3.31.0 HUD English-ification.

v3.32.2 — 2026-07-27

Fixes a crash that broke the status line for every standalone-binary user (#36).

Once the daemon had run at least once, cs render died on every tick with ValueError: max() iterable argument is empty — the bar flashed and vanished in Claude Code. _pkg_mtime() scanned the package dir for .py files to detect a daemon running stale code, but a PyInstaller onefile build has none (modules live in the PYZ archive), so max() got an empty iterable and raised ValueError, which the except OSError guard did not catch. Affected every binary release (v3.30.0–v3.32.1); pip/uv installs were never affected.

Frozen builds now use the executable's own mtime, so the stale-daemon detection keeps working there — re-running install.sh replaces the binary, which is exactly the "installed code is newer than the daemon" signal it needs.

cs doctor now actually renders. It reported all-green while the status line was dead, because every check inspected state and none exercised the render path. It now runs a real cs render with your cached payload and prints the traceback when it crashes — this class of bug can't hide behind a green report again.

Thanks to @gasbasd for a report that pinpointed the root cause, the trigger condition, and the fix.

v3.32.1 — 2026-07-22

Patch: cs --version program name + test determinism. cs --version now derives its program name from basename(argv[0]) rather than argparse's %(prog)s — Python 3.14 rewrites %(prog)s to python3.x -m module under -m, which mangled the prefix. The three aliases (cs / cstatus / claude-statusbar) now each show their real name on every Python version. Also made test_preview deterministic by forcing the demo dataset instead of depending on the machine's cached stdin (which can legitimately have no warm cache or cost).

v3.32.0 — 2026-07-22

One command installs everything. The curl … install.sh | bash one-liner now sets up both surfaces on macOS: the terminal statusLine and the floating desktop HUD. The macOS binary bundles the HUD (PyObjC) — no pip install 'claude-statusbar[hud]', no venv, no extra steps. When the installer detects the Claude desktop app it registers the HUD to auto-start on login, and it rides the binary's own auto-update like everything else. Linux binaries are unchanged (the HUD is macOS-only).

v3.31.0 — 2026-07-22

Desktop HUD: channel jump + English UI. Single-click an AgentParty channel in the cs hud panel to open a menu — Open session in Claude (claude://resume?session= deep link to the matching CLI session), Open in AgentParty (agentparty://channel/… deep link the AgentParty client handles), or Pin to bar (keep that channel on the collapsed pill). The HUD UI is now fully English.

v3.30.0 — 2026-07-22

Zero-dependency standalone binary — install with no Python or pip

claude-statusbar now ships as a self-contained cs binary attached to each GitHub Release, so people without Python can install in one line:

curl -fsSL https://raw.githubusercontent.com/leeguooooo/claude-code-usage-bar/main/install.sh | bash

The installer detects the platform (macOS arm64/x86_64, Linux x86_64), verifies a SHA-256 checksum, drops the binary in ~/.local/bin, and runs cs --setup. Platforms without a prebuilt binary fall back to the pip installer. The pip / uv / pipx package is still fully supported and remains required for the desktop HUD (cs hud), which needs PyObjC.

Under the hood the frozen binary emulates python -m <module> for its own background self-spawns (daemon, git / balance / IP-risk refresh), so daemon fast-mode behaves identically to a pip install. The updater is frozen-aware: a binary can't pip-upgrade itself, so cs upgrade points at the installer instead, and the background auto-update check is skipped.

Documentation

The README was reorganized into a concise landing page with a Features overview and per-topic guides under docs/, and a Simplified Chinese translation (README.zh-CN.md) was added.

v3.29.12 — 2026-07-15

AgentParty sessions now read their complete matching status slot

v3.29.11 made the displayed AgentParty identity session-specific, but the channel, unread count, last-message preview, and listener state still came from the workspace's shared last-writer mirror. Two sessions in the same repository could therefore render a mixed line, such as one session's agent name beside another session's channel or stale-listener warning.

The status bar now reproduces AgentParty's config-slot fingerprint and reads the complete cache entry owned by the session's explicit AGENTPARTY_CONFIG. It falls back to the legacy workspace mirror when no matching slot exists, preserving compatibility with older AgentParty clients.

v3.29.11 — 2026-07-11

AgentParty identity is isolated per session, not per project directory

Two Claude Code sessions in the same repository can use different AGENTPARTY_CONFIG files. The AgentParty cache itself is workspace-scoped, so the last writer previously made both status bars show the same agent name. The status bar now resolves the config used by each session's actual shell tool calls and overlays only that config's cached identity.

Transcript parsing accepts real tool_use command records only. A later user or assistant message that merely quotes another valid config path cannot change the displayed identity. The bridge remains local-only: config tokens are never rendered, logged, or sent over the network.

v3.29.10 — 2026-07-10

The legacy ⚠ chip is silenced by ANY projection, not just one with an ETA

v3.29.8's dedup gate only hid the legacy average-pace countdown when the projection chip carried a depletion ETA. That left the contradictory case live: →98% ⚠~25m — the better model saying "you'll end under the cap" right next to the cruder one screaming "empty in 25 minutes". Whenever a usable projection exists it now wins outright; the ⚠ chip renders only when there is no projection to disagree with (projection disabled, or the early-window →-- placeholder).

v3.29.9 — 2026-07-10

Projection algorithm review — four fixes

Snapshot throttling. Every compute appended a backtest snapshot (0.4s average gap live), so the 1000-entry cap covered 8.5 minutes of history — useless for backtesting — while ~150KB of snapshots were re-parsed and re-written by the daemon every second, its single largest CPU line. Now one snapshot per window per 60s (~8h of history), and the store shrinks ~10x.
Sample decimation. Fractional-percent ticks stored a sample each (2032 live); rate math reads the first/last of a ≥5-minute span, so sub-0.5pp/sub-60s granularity was pure file weight. Skipped now.
Burst rates clamp instead of vanishing. A recent rate above the sanity cap (60%/h for 5h) was discarded entirely, dropping the blend back to the much slower window average at exactly the hottest moments — the projection went LOW when it most needed to go high. It now pins at the cap.
The →100%·ETA warning arrives minutes earlier. The display smoother eased toward a depleting raw projection over its full 8-minute tau, delaying the warning. When the raw says ≥100% the approach is fast (τ=2min); downward moves keep the slow tau, so cooldowns still don't flap.

Known approximation, documented in code: the 7d depletion ETA inverts a bucket-integrated projection linearly and can overestimate time-left when near-term buckets are hotter than the tail.

v3.29.8 — 2026-07-10

One countdown, not two

v3.29.7's depletion ETA (→100%·33m, blended-rate) and the legacy average-pace forecast (⚠~25m) answer the same question with different estimators, and both rendered side by side — two disagreeing countdowns on one line. The legacy chip now yields whenever the projection carries an ETA, and remains the fallback for windows whose projection doesn't.

v3.29.7 — 2026-07-10

A maxed projection now says WHEN the quota runs out

→100% alone buried the useful half of the prediction. When the pace overshoots the cap, the chip now carries the estimated time until usage actually hits 100%: 5h[▓ 27%] 🕐4h19m →100%·1h12m reads "headed to the cap, empty in about an hour". Computed from the same blended-rate projection (unclamped twin), only shown when depletion lands before the window reset.

Quiet channels no longer read as "listener down"

AgentParty CLIs older than 0.2.80 heartbeat only when traffic arrives, so a listener on a quiet channel went heartbeat-stale after 10 minutes and the bar showed ⊘ listener down while the process sat healthily connected (seen live: a serve alive with a 32-minute-old heartbeat). The process is the better witness: alive and verifiably a party process → ◉ watching/serving, whatever the heartbeat age. A recycled PID (alive but not a party process) still reads as down. Upstream, AgentParty 0.2.83 also heartbeats on a 60s timer and an exiting watch --once no longer wipes another live listener's record.

v3.29.6 — 2026-07-10

Documentation

Clarified Claude Code vs Codex support. The README now has an explicit support matrix: Claude Code remains the full native statusLine integration for quota/session/context/cache/activity data, while Codex support is the local AgentParty bridge that shows channel, identity, listener state, unread count, and last-message preview from ~/.agentparty/state/<workspaceId>/statusline.json.
Updated the latest-release summary. The top of the README now points to v3.29.6 and summarizes the v3.29.5 daemon/session fixes instead of leaving an older v3.28.x entry first.

v3.29.5 — 2026-07-09

launchd/systemd daemons were unkillable — and immune to upgrades

_process_is_our_daemon matched the module path claude_statusbar (underscore), which only appears in lazy-spawned daemons (python -m claude_statusbar.cli …). A service-managed daemon's cmdline is <venv python3> /path/to/cs daemon _run — no underscore form anywhere. So for every launchd/systemd instance:

cs daemon stop refused with a false "PID reused. Refusing to SIGTERM".
The upgrade drift-kill (guarded since v3.29.1) also refused — the stale daemon kept serving old code after every upgrade.

The matcher now recognizes all spawn shapes, keyed on the shared daemon _run invocation.

The AgentParty line showed in sessions that never joined

The AgentParty cache is cwd-scoped by contract, but Claude Code sessions are not: several windows share one project directory and only some of them join a channel (typically with a per-session AGENTPARTY_CONFIG). Every window in the directory rendered whichever session's channel/identity wrote the cache last — dead listeners and all.

The env var never reaches the Claude Code process (agents export it inside individual Bash calls), so the line is now gated on the only session-scoped evidence there is: the session's own transcript. A window shows the party block only after its transcript contains a party command (party init/send/watch/… or AGENTPARTY_CONFIG). Scans are incremental (byte offset per session, sticky verdict), so a large transcript is read once and each later render reads only the appended tail. Sessions without a transcript (preview, tests, bare cs) keep the old always-show behavior.

An exiting daemon could delete the current owner's pidfile

flock locks an inode, not a path: after an unlink+recreate cycle, two daemons each hold "the" lock on different inodes. _release_pidfile unlinked by path unconditionally, so the exiting daemon deleted the pidfile the current owner had just written — making it invisible to stop/status/spawn_if_dead, so the next render spawned a duplicate. Observed live twice in one day (a pidfile-less daemon looping for 15+ minutes beside a fresh one). Release now unlinks the locked file only while it still points at the exiting daemon's own inode.

v3.29.4 — 2026-07-09

The daemon's auto-upgrade silently failed under launchd/systemd

launchd and systemd run the daemon with the bare system PATH, which lacks ~/.local/bin — where uv and pipx actually live. shutil.which("uv") failed there, so the upgrade fell through to python -m pip install --upgrade — and a uv tool venv ships without pip. Net effect: for uv installs whose daemon runs as an OS service, the daily auto-upgrade has never worked. Tool discovery now searches well-known directories (~/.local/bin, ~/.cargo/bin, Homebrew) after PATH.

`cs upgrade` is now the one documented upgrade path

Users kept being told (by READMEs and by agents guessing) to run uv tool install … — and many of them don't have uv, because they installed via pip. cs upgrade has picked the right channel since 3.28.1; now every surface says so: the README's Upgrading section, the claude-statusbar skill's decision tree (with an explicit "never guess a package-manager command" note), its trigger words (upgrade/update/升级), and /statusbar-doctor's follow-up suggestions.

v3.29.3 — 2026-07-09

The systemd unit had the same respawn loop v3.29.2 fixed on launchd

v3.29.2 changed the launchd plist to KeepAlive: {SuccessfulExit: false} but left the systemd user unit at Restart=always — which relaunches even a clean exit. On Linux, whenever a lazy-spawned daemon held the pidfile, systemd's own instance exited 0 and was rerun every RestartSec=5, forever (and v3.29.2's exit-0 change made the loop silent). cs daemon stop also never stuck: clean exit, immediate relaunch. Now Restart=on-failure — crashes still bounce. Linux installs need cs daemon install re-run.

`mentions_only` now comes from the AgentParty contract, not `ps`

AgentParty 0.2.79 writes listener.mentions_only into statusline.json (contract change shipped alongside this release). The statusbar reads it verbatim; the ps argv probe remains only as a fallback for older CLIs. This removes the last per-render fork on up-to-date installs and closes the pid-recycling staleness the memoised probe could serve.

v3.29.2 — 2026-07-09

launchd was respawning a redundant daemon every 10 seconds

The LaunchAgent shipped KeepAlive: true, which restarts the job on any exit. Whenever the thin client's lazy-spawn already owned the pidfile, launchd's own cs daemon _run found it taken, printed daemon already running, exited 1, and was relaunched ThrottleInterval seconds later — forever. A live daemon.stderr.log had 47429 such lines.

run_forever now exits 0 when another daemon holds the pidfile (a daemon is running; this process's purpose is served), and the plist uses KeepAlive: {SuccessfulExit: false} so a clean exit ends the respawn while a real crash still bounces the daemon.

Existing installs need cs daemon install re-run to pick up the new plist.

The test suite was writing into the user's real daemon log

test_render_payload_signal_alarm_aborts_slow_render sets RENDER_TIMEOUT_S to 1 and lets a render time out, but _log() writes to the real ~/.cache/claude-statusbar/daemon.log. Every pytest run appended a render timed out after 1s line there; 260 had accumulated, and they masked the daemon's genuine timeouts (logged as after 12s, none since 2026-06-03). Diagnosing a "slow render" from that log meant reading test output as production signal. The test now stubs _log.

Warm renders are ~2.5x faster

v3.29.0's --mentions-only probe forked ps on every render — about 4ms of a 6ms warm render. A process's argv never changes, so it is memoised per pid. Warm render: ~6.1ms → ~2.4ms.

v3.29.1 — 2026-07-09

The daemon was crash-looping on slow renders

run_forever's sleep loop read the clock twice:

end = time.time() + sleep_for
while _running and time.time() < end:
    time.sleep(min(0.2, end - time.time()))   # <- second read

If the process was descheduled between the guard and the subtraction, the remainder had already elapsed, time.sleep() got a negative number and raised ValueError: sleep length must be non-negative. The daemon died. Any render slower than the tick interval — the render timed out after 1s lines in daemon.log — made the window wide enough to hit routinely.

This is the root cause behind v3.29.0's third fix. The orphan-.tmp sweep and the auto-update check were not merely starved by sharing a 30-minute timer; the daemon was being killed long before it could reach 30 minutes, then restarted by launchd. The remainder is now clamped at zero.

v3.29.0 — 2026-07-09

AgentParty block redesign

The AgentParty line answered none of the questions it existed to answer.

watch down was a lie. The statusline contract writes the listener heartbeat as heartbeat_ts; party.py read heartbeat_at. It always got None, so the heartbeat never looked fresh and every live listener rendered as down. Two test fixtures wrote heartbeat_at too, so the bug was pinned in place by its own tests.
It was unreadable. The whole line stacked the FAINT attribute on top of the theme's dimmest grey. Colour is now assigned by meaning: channel in ink, identity in mute, listening state green/red/grey, unread count amber.
The message no longer crowds the header. It gets its own line, clipped to 54 display columns with wide CJK glyphs counted as two, so a long preview cannot push the header off screen.
The listening state is stated outright — ◉ watching / ◉ serving (green), ⊘ listener down (red), ◌ not listening (grey, no listener attached). @mentions is appended when the live listener runs with --mentions-only, detected from its argv.
The message carries its own state: ● unread / ○ read, followed by @ when the preview mentions your identity. Mention matching is exact, so @leo-zego-im does not mark leo-zego. (The writer clips previews at 48 chars, so a mention past that cut is missed — it under-reports, never over-reports.)
Emoji gave way to monochrome geometry (⬡ agent, ⬢ human). Glyphs now inherit the theme colour and hold a single column.

Daemon restart fixes

Found while investigating "I upgraded but nothing changed".

The code-drift tick burned its own spawn debounce. On detecting drift the thin client SIGTERMed the old daemon and immediately called _spawn_daemon_async(). The old daemon was still alive handling the signal, so spawn_if_dead found a valid pidfile and refused — after the 30s debounce marker had already been stamped. Every session then inline-rendered for 30 seconds. The drift tick no longer spawns; the next tick (~1s) does.
_signal_outdated_daemon could SIGTERM an unrelated process. A session's meta outlives the daemon that wrote it, so meta["pid"] may have been recycled. It now verifies _process_is_our_daemon(pid) first — the guard that the function's own docstring already claimed to apply.
The orphan-.tmp sweep and the auto-update check were starved. Both hung off the session-GC timer, which is seeded to daemon start and fires after 30 minutes. Since the thin client restarts the daemon on every code drift, it rarely lived that long and neither ever ran. Observed live: 15 orphaned .tmp files, the oldest 99 minutes old, against a 60-minute cutoff. Maintenance now runs on the first tick; session GC keeps its deferral.