The status bar

Agents: claude, codex, opencode · On: phone, desktop

The facts about this tab right now: which branch, how much context, whether you are connected, and what is waiting. On a phone they are one line above the composer. On a wide window they are two: the branch, the context, the ping and the session's changes on a row at the top of the composer, and what is waiting in the composer's key row. Every segment is a button. The machine is not on it: the tab names it.

Why you would use it

It is the fastest read of whether the thread is healthy, and the fastest route to the things it names: the sessions sheet, the changed files, the reason it is paused.

How to use it

1. On a phone, look at the bar above the composer (#statusbar). Every segment is on it.
2. On a wide window, look at the top row of the composer (#composer-facts): the branch, the context and the ping on the left, the session's changes on the right. What is waiting is in the key row (#composer-status), in the gap between the effort dial and the mic. Both report the pane they are in rather than the tab in front.
3. Tap any segment but the branch. Each one either says more, or opens the thing it is about. The branch is text: a tap on it does nothing. In a pane you are not typing into the segments are text, not buttons: the tap focuses the pane, and the box arrives with the bar you can tap.

What you see

Segments appear only when they have something to say, left to right. On a wide window the first three and Changes are the composer's top row, and the rest its key row:

The branch is the one the agent last edited a file in. When it works in a git worktree, you see the worktree's branch, not the one checked out in the tab's folder. Before the tab's first edit, it is the tab's folder's branch. The * on the branch means the working tree is dirty; ↑2 means two commits ahead of upstream. The connection figure is the time a request takes to reach the box and come back, measured when the status refreshes: every 5 minutes and when you tap it. On the desktop app on the box's own computer it reads 1 to 2 ms. ● needs you shows while an approval is pending.

Limits and known gaps

• There is no shell segment. Shell mode opens from the composer's mode chips, and a second door to the same room was removed.
• No cost segment. The dollar total is still accumulated server-side but is not shown: on a subscription plan it reads as a warning about nothing.
• An agent that edits only through shell commands leaves no edits to follow, so the branch stays the tab's folder's until its first v-code proof.
• The git figures come from git and are best-effort: a folder that is not a repo, or a repo with no commits yet and no upstream, simply leaves the segment out rather than failing the request.
• ctx is this tab's context, not your plan usage. Plan usage is the meter row above the transcript.
• Inside the composer the live line has the key row's spare track. A paused thread that also has a queue and needs you can still run past it: the last segment is cut off at the mic, so ⏸ resumes 15:46 reads as ⏸ resumes. Drag the line to scroll to it. In a pane you are not typing into you cannot: the line is inside the stub's button there, and a drag focuses the pane. Focus it and read the line in the box.

Related

• retry-temporary-model-errors: what the retry segment counts down to
• auto-compact: what the ctx number is measured against
• usage-limit-pause-and-retry: the paused segment
• usage-meters: plan usage, which is a different number
• machine-name: where the machine is named instead
• floating-chrome: the band the bar sits in
• watch-pull-request: the ⟳ PR #12 segment