Claude Code & Codex Status Bar

Claude Code and OpenAI Codex, side by side in your VS Code status bar — per‑session context usage, model and effort, task‑complete beeps, and account limits (Claude.ai 5‑hour session & weekly, Codex 5‑hour & weekly usage), with a live activity panel for workflows, agents, background tasks and Codex runs, status‑bar dots for work still running, Remote‑SSH support, Telegram reset alerts, and a bilingual settings panel.

⭐ Star the repo, please

Plenty of people install this. Almost nobody stars it. A star is the only signal that tells me anyone actually uses this thing — and it's what decides whether I keep building it. It takes two seconds: github.com/comonetso/claudeStateBar

Windows desktop widget: claudeState

Just want to see your limits, even with VS Code closed? claudeState is a small widget next to the Windows taskbar that shows your Claude 5‑hour and weekly usage, plus Codex usage when the Codex CLI is installed. Hover it for reset times. It only shows limits — the session, workflow and Codex panels live in this extension. Windows x64 only. After installing, enter your claude.ai session cookie and organization ID in its settings window. Download for Windows (x64) · Release notes

🇰🇷 한국어 문서: README.ko.md

Two layers in one status bar

Claude Code & Codex Status Bar shows two complementary things, merged into a single hover tooltip with clearly separated sections:

🧠 claudeContext — Claude Code context monitor

Reads Claude Code's local session logs (~/.claude/projects/*.jsonl) and shows, per active session:

• Live context usage % (tokens used vs. the model's limit)
• Per‑session monitoring — each Claude Code session gets its own status‑bar item
• Model‑aware limits — Opus 4+, Fable/Mythos, Sonnet 4.6+/5+, or models with 1m in their ID → 1,000,000 tokens; others (Opus ≤3, Sonnet ≤4.5, Haiku, etc.) → 200,000 (configurable)
• Model + effort + speed — e.g. Opus 4.7 · xHigh⁺ · ⚡fast (see Effort display)
• Color‑coded warnings — normal / warning (≥50%) / danger (≥75%) backgrounds
• Two‑tier idle — sessions dim after idleTimeout (default 180s) and fully hide after hideAfter
• Ghost‑session detection — hides stale sessions after /clear or tab close; auto‑unhides on new activity
• Compact mode & custom short names — project names such as my-cool-project → MCP; Codex model names stay fully readable
• Live activity indicator — shows elapsed seconds while Claude is thinking (🤔) or responding
• Running‑work dots — coloured dots at the front of the status bar while a workflow, a background task or a Codex run is going (see Status‑bar dots)

📊 claudeState — Claude.ai plan usage

Fetches your account‑wide plan usage directly from claude.ai (no SDK, no extra service):

• 5‑hour session limit % with reset countdown (merged into the first session item)
• Weekly usage % right after the 5‑hour figure, without a countdown — 2% (4h 49m) - 24% in compact mode, Session 2% (in 4h 49m) · Weekly 24% otherwise — plus a per‑model breakdown in the tooltip (Fable / Opus / Sonnet — whichever models claude.ai currently reports)
• Session‑reset detection → optional Telegram notification when your 5‑hour window resets
• Credentials (Session Key, Bot Token) are stored encrypted via VS Code SecretStorage

Both layers describe Claude sessions, which are prefixed ✳ in the status bar. Codex sessions are prefixed ⬢ — see OpenAI Codex session monitoring.

⬢ OpenAI Codex session monitoring (Phase 1)

The status bar now shows Claude sessions and OpenAI Codex sessions at the same time. An icon prefix tells them apart:

• ✳ — Claude session
• ⬢ — Codex session

Codex context data comes from files only: ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl — on your local machine, or on the remote host in a Remote‑SSH window. No network calls. Account usage is a separate path: it is queried live from the Codex app‑server (see below).

With the default scope: workspace, Codex shows the conversation UUID last selected in this VS Code window. The extension first reads the stable URI of an active Codex editor tab; sidebar chats fall back to structural conversationId markers in this window's OpenAI Codex.log. Losing window focus or reloading VS Code does not erase that per-window UUID. Only that UUID's rollout is opened, even if the chat was created in another project or reopened in a Remote‑SSH window. It never substitutes another recent rollout. If no UUID can be resolved, only the account-usage item is shown. Set scope: all explicitly to restore the machine/host-wide list of up to five recent sessions.

Codex lists conversations per device, not per project. Reopening VS Code restores whatever chat you last viewed — often one created in a different repository — and the status bar honestly reports that chat, because it really is the one this window is showing. To keep that from reading as your current folder's context, a conversation whose cwd is not a folder open in this window is marked: the ⬢ glyph turns warning-coloured, an ↗ follows the project name, and the tooltip states the conversation's full path. Starting a new conversation clears the mark.

Within the context-bar group, Claude sessions are always on the left and Codex sessions are always on the right. Activity timestamps never reorder one provider across the other.

The provider glyph is the identity cue: Claude's ✳ is orange and Codex's ⬢ is blue. The original silhouettes are bundled as larger native-size product icons, and their separate colour slots are compactly joined to the usage text. Because the glyph owns its own colour slot, the text is free to signal the usage threshold without wasting status-bar space. The glyph changes colour for exactly one reason: a Codex conversation belonging to another project (above).

What a Codex item shows

• Context usage % — the latest last_token_usage.total_tokens ÷ model_context_window
• Model name — e.g. gpt-5.6-sol → gpt 5.6 sol; only separators are made readable, and Codex model names are never shortened by compact mode
• Effort — Low / Medium / High / xHigh, etc.
• Idle dimming & hideAfter hiding — exactly the same rules as Claude
• Completion beep — driven by Codex's task_complete event. It shares Claude's completion sound and threshold settings — there is no separate Codex sound setting.
• Tooltip — Codex 5‑hour and weekly limits (used percentage, reset times, plan type) + context token breakdown + the session's cumulative processed tokens

Codex account usage (rate limits)

Read live from Codex itself, not from log files, so the figure matches what Codex would tell you.

Codex reports how much you have consumed, and that is what the status bar and tooltip show — the same direction as the Claude plan block right next to it, so a bigger number always means "closer to the limit". Note that the ChatGPT usage screen states the complementary amount still available: what it calls 42% remaining appears here as 58% used.

The tooltip’s Session processed total comes from rollout total_token_usage.total_tokens. It is the cumulative token volume processed across model calls in this conversation (including cached input), not the current context size and not the account’s weekly-limit usage.

This is checked on a slower timer than the session refresh — at most once a minute — so it never runs on every poll.

Why live instead of the log? Codex limits use a 7‑day rolling window, so the real numbers go down on their own even when you aren't using Codex. Reading only a log snapshot would freeze the value whenever you don't touch Codex for a few days.

Fallback order:

1. A live query, shared across your VS Code windows
2. If no live/shared value has ever succeeded, the newest rate_limits snapshot available from the visible rollout logs
3. If a previous shared live value exists, keep it and mark it as a stale value when it ages out
4. If there is nothing at all, usage is not shown

The tooltip shows the source next to the observation time — live, or from session log.

The old "only refreshes while Codex is actually working" caveat now applies only to the fallback (step 2): a rollout snapshot is written while Codex works, so an idle session's snapshot goes stale.

With several VS Code windows open, only one of them queries Codex and the rest read the result. So every window shows the same number, and you don't pay for the same lookup many times over.

If the current window has no recorded Codex conversation UUID or its rollout is unavailable, account usage is still shown as a standalone ⬢ Codex item. This is intentionally account-only: the extension does not attach another window's model or context figures by guesswork. Once a UUID is resolved, the standalone item is replaced by that conversation's normal session item.

Codex account usage is a separate concept from Claude's 5‑hour / weekly plan usage. Each provider's usage is merged only into that provider's own first session item.

The status bar text follows the Claude one. An account with a 5‑hour limit shows it with its countdown and then the weekly figure (30% (2h 3m) - 49%); a weekly‑only account shows the weekly figure with its countdown (49% (2d 7h)). On the standalone ⬢ Codex item the text colour follows the first figure: yellow from 70%, red from 90%, and below that the same resting colour as a session item (baseColor), while the ⬢ glyph keeps the light blue of a Codex session item. A session item is coloured by its context usage, as before.

Codex settings

Everything else is shared between Claude and Codex — warning/danger thresholds, sounds, compactMode, idleTimeout, hideAfter, scope, and so on. There are no Codex‑specific threshold or sound settings.

Known limitations (Phase 1)

• Current-chat mode follows the Codex UI, not host ownership. A Remote‑SSH window can run the Codex webview on the local UI host, so the selected conversation may live in local CODEX_HOME; it can also refer to a rollout in the configured/remote Codex home. The exact selected UUID is tried against the configured host first and the local UI home only when no explicit codex.home override forbids fallback.
• No Codex workflow / sub‑agent viewer in this extension — clicking a Codex session does not open the Claude workflow menu. Explicit spawned-agent links are read only for the all-agents-complete sound; Codex's own background-agent panel remains the place to inspect or open individual threads.
• Codex sub‑agent sessions are not shown as status-bar items — spawned-agent rollouts are aggregated under their parent turn for the completion sound, while internal guardian rollouts remain excluded.
• No Codex question‑pause beep or stuck detection yet.
• The extension does not delete Codex rollout/session logs by itself. The codex-rescue plugin (1.17.3 or later) removes the logs of the conversations its live-steering runs started once they pass its run-record period, and the Codex progress tab's Clean up runs the same removal for one project when you ask; conversations you start yourself are never touched. See What it creates in your project.
• Account usage is queried from your local codex, even in a Remote‑SSH window — the live query runs the local codex executable, so the figures reflect your local account. With the same ChatGPT account the numbers are identical; with a different account they can differ. (Context monitoring is unaffected — it reads the remote files correctly.)
• If codex isn't available or the lookup fails, everything else keeps working — only the usage figure falls back to the last value found in the logs.
• Sidebar selection uses an internal OpenAI log marker as a compatibility fallback. Active Codex editor tabs use the stable VS Code tab URI. The newest active=true UUID is retained per window because active=false also means ordinary window focus loss. On Remote‑SSH, the local window is matched to its remote OpenAI extension-host log by process ID, with activation time as a bounded fallback. A future OpenAI log-format change can temporarily reduce a sidebar-only window to the account-only item. scope: all intentionally remains a recent-session list.

Privacy

Codex rollout logs contain the full text of your conversations, but the rollout parser extracts only structural fields — token/rate-limit counts, timestamps, model/effort, cwd, task lifecycle, and explicit spawned-agent parent/thread IDs. To identify a sidebar chat, the matching local or remote OpenAI Codex.log is scanned for the exact thread_stream_view_activity_changed marker, its boolean, and its UUID; all other log text is discarded immediately. Message bodies are never stored or written to this extension's log. Monitoring never opens auth.json; the only feature that reads it is the optional Codex auto-start, which checks it for a ChatGPT-plan login before firing (see Codex 5‑hour resets).

🌐 Remote‑SSH support

Working over Remote‑SSH? Claude Code & Codex Status Bar runs as a UI (local) extension so it can do both jobs at once:

• Plan usage is fetched from your local machine via Electron's network stack — this passes Cloudflare's bot challenge. (Plain Node https from a remote/headless host gets a Cloudflare 403, and cloud/datacenter IPs such as AWS EC2 are blocked regardless of TLS fingerprint.)
• Token counts are read from the remote host's ~/.claude/projects through vscode.workspace.fs, which VS Code transparently routes over the SSH connection. The remote home is auto‑detected (/root, else /home/*).

Install once locally — all your Remote‑SSH windows update automatically. Because this is a ui-kind extension, you never need to reinstall it on each server.

In a Remote‑SSH window you see remote session token usage and your plan usage together, in one place. If a host genuinely can't reach claude.ai, the bar shows an honest "plan usage unavailable here" notice instead of a misleading "expired" error.

Codex over Remote‑SSH

Codex is covered too. With scope: all, the extension reads the remote host's recent rollout files through vscode.workspace.fs; the remote home is found by probing /root and /home/* for a directory that actually contains .codex/sessions. With the default scope: workspace, it first resolves the exact conversation shown by this VS Code window and looks for that UUID on the remote host. If no explicit codex.home is set, it can then check the local UI host's Codex home because the Codex webview may own a local conversation even inside a Remote‑SSH window.

One read‑path difference (performance note): locally the extension reads only the byte range it needs, so even a 14.1 MB rollout takes a few milliseconds. Over Remote‑SSH the VS Code file API has no range read, so the whole file is read. This is the same thing Claude already does remotely (the largest Claude session file on this dev machine is 9.2 MB). For both, a file whose mtime and size are unchanged is not read again — for Claude conversations since 1.17.1. Before that, every refresh re-read every conversation touched in the last hideAfter (24 hours by default), so a window kept open while sessions were started and closed moved more data on each refresh: roughly 70–220 MB a minute was measured in one Remote‑SSH window. Only a conversation still being written is transferred again now.

The session menu and the panels open without waiting on these reads. Since 1.17.1 they appear at once with what the extension already knows and fill in as fresh numbers arrive: a count not read yet shows as checking…, and a panel opened before its first scan shows Loading… until the list lands. Over Remote‑SSH those reads could queue behind the status bar's own, and the menu took 16–21 seconds to appear right after a window started. As a safeguard, remote rollout files larger than 32 MB are skipped and logged.

Local and remote read paths were verified to produce identical parsed results — 5 sessions × 12 fields, all matching, on the same rollout data.

⚠️ An explicit codex.home remains authoritative and never falls back. In scope: all, a remote window lists only the remote host's recent Codex sessions; the local UI fallback applies only to the exact selected conversation in the default current-chat mode.

⚠️ Account usage is the one exception: the live rate‑limit query runs your local codex, so even in a remote window the usage figures come from your local account. Same ChatGPT account → identical numbers; a different account → possibly different. Context monitoring is unaffected.

🗂 Activity panel

Since 1.17.2 the views of work going on behind the conversation — workflows and sub-agents, background tasks, Codex progress and Codex chat — are tabs of one panel, Claude Activity, instead of four separate panels. The session menu has a single Activity entry where it used to list four.

• What is running shows on each tab — a tab with something running shows a spinning icon and a count, in the colour of its status-bar dot. A tab with nothing running shows its usual icon. The Workflows count is the number of agents running, sub-agents included, so three sub-agents launched together count as 3. Background counts running tasks, long ordinary commands included; Codex progress counts runs that have not finished; Codex chat counts conversations waiting on an answer
• The menu entry — sums up the same counts, for example Workflows 3 · Codex 1 running, and reads all done when nothing is running (none running when there is nothing to list at all). Choosing it opens the first tab with something running, or else the tab you last looked at in this workspace
• Other ways in — claudeStateBar: Show Claude Activity in the command palette does the same. The older commands (Show Claude Workflows, Show Claude Background Tasks, Show Codex Runs, Codex Chat Panel) still work and open their own tab, and clicking a status-bar dot opens its tab
• Ctrl+Tab — while the panel is in front, Ctrl+Tab and Ctrl+Shift+Tab move to the next and previous tab. With the focus in the panel's content (it moves there when the panel opens or a tab is clicked) this works even if your keybindings.json binds Ctrl+Tab to something else; with the focus elsewhere, such a binding of your own wins. Anywhere else Ctrl+Tab switches editors as usual; with the panel in front, Ctrl+PageUp/PageDown still does
• Codex tabs — shown only when codex_rescue is installed, as the menu entries they replace were
• Each tab keeps its own state — font size, scroll position and open cards. The tabs work as the sections below describe
• Only the tab on screen is re-read — to keep Remote-SSH windows light, the workflow, background and chat lists are refreshed only while their tab is showing and the panel is not behind another editor tab. Switching to a tab, or bringing the panel back into view, reads it at once, so its previous list can show for a moment. Codex progress stays current either way, since its completion beep needs that read. The counts on the tabs you are not looking at keep updating without reading their lists, though a background task that has just ended can count as running until its end notice reaches the conversation. Beeps do not depend on any of these reads

🎬 Workflow & Task Agent viewer panel

This is the first tab of the activity panel; claudeStateBar: Show Claude Workflows in the command palette opens the panel on it. It lists this project's Claude Code workflows and Task (Agent tool) sub‑agents — every session, not only the one you clicked — newest first, up to 20. Since 1.16.8 it looks and behaves like the Codex progress panel below:

• Cards — each workflow is a card with its name, start date and time, elapsed or total time, and a status badge. Everything starts folded. Finished workflows go into a single "N finished" row, itself folded, which also says how many were stopped; one you watched while it ran stays outside that row until you close the panel
• Earlier sessions too — a workflow from yesterday's conversation is still there. The card says which session it ran in, and whether that session is open right now. If a session has been idle past hideAfter, any agent it left marked as running is shown as stopped
• The last list while a new window reads — the first read in a new window goes through every sub-agent log of the project, which over Remote-SSH can take half a minute in a busy one. Until it finishes, the tab shows the list from the last window under a Last list · reading again… line, so an agent shown as running may have finished since. The tab badges, the session menu and the completion chime never use that saved list
• Agents grouped by phase — when a workflow declares more than one phase, its agents sit under the phase they ran in, drawn like a Codex turn header with a done/total counter. Click the header to fold it. Agents are listed in the order they were started, as the phone's remote-control view lists them
• What each agent did — open an agent to see its steps as rows: commands, file reads, edits, code searches, web lookups and what it said, each marked done or failed, with how long it took. Runs of successful commands, reads or searches fold into one line; a failure never does, and opening it shows the error output. The last row is the agent's final report. The rows are read only when you open the agent, which keeps the panel light over Remote‑SSH
• Model, tokens and time per agent — every agent shows which model ran it, how many tokens it used and its time, and the card carries the agent count and the workflow's total. A running agent's clock counts from its start and keeps going while it waits on a command or thinks; a finished one shows how long it took
• Role labels — each agent's role comes from the label its workflow script gave it, falling back to text extracted from the agent's prompt header, so you see "Lens A: Bug Detection" instead of "agent-1". Recent Claude Code versions record each agent's label and phase when they start it, and the panel reads those first, so a run whose script can't be found still shows its agents' names and phases
• Task (Agent tool) sub‑agents — sub‑agents spawned via Claude Code's Agent tool are shown as their own cards, grouped into batches by start time (5‑minute gap = new batch). They are handled the same way as workflows: 🗑 on a finished batch sends it to the same trash, and a sub‑agent the conversation reports as stopped, killed or failed is shown as stopped. If it has written more since that report, it was resumed and stays running
• Trash — 🗑 on a finished workflow or batch moves it aside instead of destroying it, with no confirmation to click through. Open 🗑 at the top of the panel to restore it or delete it for good; the trash covers every session of the project. Restoring is refused if a live workflow has since taken that id, or a sub‑agent log of the same name is back in place
• Font size control — A− / A+ buttons adjust the panel text size
• Bilingual UI — full EN / 한국어 toggle, same as the settings panel

⏳ Background task panel

This is the activity panel's second tab; claudeStateBar: Show Claude Background Tasks in the command palette opens the panel on it. It answers two questions about the sessions shown on the status bar (those active within hideAfter, 24 hours by default) — what Claude ran in the background, and which commands took long — as two groups:

• Background — commands Claude Code ran with run_in_background, and the monitors it started. An ordinary command that Claude Code moved to the background after its time limit is listed here too, from its start. A chip tells a command from a monitor
• Long commands — ordinary commands that ran for more than 2 minutes. On the machines checked that was about 1 command in 250

Each group folds under a header that shows how many are running and finished. The phone's remote-control view mixes workflows into its background list; here they keep their own tab, and commands started by a workflow's agents are left out. So is the background command Claude uses to hand a problem to Codex through codex_rescue — the Codex progress panel shows that run.

• Running tasks — each card shows the task's description, how long it has been running and the command. A background task also shows its output so far: the box follows new lines while you are scrolled to the bottom, and while this tab is showing the output is re-read every 2 seconds. An ordinary command appears once it passes 2 minutes and has no output to show yet — Claude Code only records it when the command ends — so its card says Claude is waiting for it
• Finished tasks — each group folds its finished tasks into one row, newest first, up to 10 per group. Each says whether it completed, failed (with the exit code) or was stopped; open one to see its command and output. A task you watched while it ran stays outside that row until you close the panel. 🗑 on a row clears that group's finished tasks from the list without touching any file; this is remembered per workspace
• When a task counts as finished — a background task, when Claude Code's notice that it ended is in the conversation, when Claude stopped it with TaskStop (which sends no such notice; the task then shows as completed, without the finish chime), or when its output file already ends with [exited with code N]; with none of these it stays "running", so one whose session ended before it did can read as running until that session drops off the status bar. An ordinary command, when its result is in the conversation
• Output that is gone — Claude Code keeps a background task's output in a temporary folder that is often cleared later, and the card then says so. A monitor still shows the events it reported. An ordinary command's output lives in the conversation itself, so it stays
• Sound — a background task that completes plays the workflow sound, under the same workflowCompleteBeep setting. A failed or stopped task is silent, as a failed workflow is, and so is one the extension never saw running — for instance one that had already finished when the extension started. A long ordinary command never sounds: Claude was waiting on it and answers the moment it ends
• View only — there is no stop button. Nothing on disk records a task's process, so the panel has no safe way to end one; ask Claude in the chat instead
• Remote‑SSH — the conversation file is the one the status bar already reads, so the list costs no extra transfer, and output files are read from the host that ran the task

🟠 Status-bar dots for running work

Up to three coloured dots at the front of this extension's status-bar items, just left of the first session, say what is running behind the conversation. Whether sub-agents, a background command or a Codex run is still going shows at a glance, without opening a panel.

• Orange — a workflow in one of the status bar's sessions has an agent running, or an Agent-tool sub-agent is running there. Sub-agents launched together count as one batch, as in the workflow panel
• Grey — a background task in those sessions is running: a run_in_background command or a monitor. Long ordinary commands don't light it, and neither does Claude's own background call to Codex — that run shows as blue
• Blue — a run in the Codex progress panel is running. One the panel shows as not responding, such as a run cut off when the window reloaded mid-run, doesn't light it
• Only while running — a dot appears when its kind starts and disappears when it ends. When all three run they sit side by side in that order, as close together as the status bar allows
• Hover and click — the tooltip lists what is running: each workflow's or sub-agent batch's name and how many of its agents are done, each command's description and start time, each Codex run's subject and mode. Clicking a dot opens its tab in the activity panel
• How quickly they follow — orange and grey follow the status-bar refresh (a changed conversation file, or every 30 seconds by default); blue follows the Codex scan, which runs every 2 seconds while a run is live
• Colours — each dot has a shade per theme kind (dark, light, high contrast) chosen to stand out on the status bar: all three measure at least 5:1 against the status bar on VS Code's six default themes. To change one, set claudeContextBar.workflowDot, claudeContextBar.backgroundDot or claudeContextBar.codexDot under workbench.colorCustomizations, for example "workbench.colorCustomizations": { "claudeContextBar.workflowDot": "#FF8800" }

🔶 Codex progress panel (optional)

When Claude Code hands a problem to Codex for a second opinion, Codex runs for minutes with nothing on screen. You only see the result at the end, and until then you can't tell whether it's working or stuck. This panel looks inside that gap.

It needs the codex_rescue skill for Claude Code, which is not bundled with this extension — the skill runs codex exec with write access to your workspace, and that shouldn't arrive as a side effect of installing a status-bar extension. Installation and usage are in the guide (한국어).

Since 1.16.0 the skill is also a Claude Code plugin, and that is the recommended way to install it: run /plugin marketplace add comonetso/claudeStateBar, then /plugin install codex-rescue@comonetso inside Claude Code. The extension finds either kind of install. If you copied the skill into ~/.claude/skills/codex_rescue/ earlier, that copy keeps working but no longer updates by itself, so each new window shows a notice recommending the switch until you pick "Don't show again". Once the plugin is installed, the same notice offers to move the old copy to the trash. Marketplaces outside Anthropic's own don't auto-update by default, so the extension checks whether auto-update is on for comonetso on the machine a window points at — this PC in a local window, the server in a Remote-SSH window. If it is off, a notice offers Turn on, which adds "autoUpdate": true to that machine's ~/.claude/settings.json (creating the marketplace entry if needed) after backing the file up; Don't show again here is remembered per machine. While it stays off, the session menu has an entry that does the same, right below Activity. The change takes effect when Claude Code restarts. The setting belongs to the marketplace, so the notice also appears when only peer_req, browser_check or android_check (below) is installed, and it keeps all four plugins current.

With the skill installed, it is the Codex progress tab of the activity panel; claudeStateBar: Show Codex Runs opens the panel on it. Each run is one card:

• What Codex just said — its own narration of what it's about to do, far more useful than a spinner
• Commands, searches, file changes, MCP calls — colour-coded by kind, commands with their exit code. Runs of consecutive successful commands or searches fold into one line you can expand; failures never fold, so they stay visible
• Clipped rows open in place — a row too wide for the panel expands where it is, wrapped, when you click it. One row stays open at a time. What you get is what the panel kept: messages up to 4,000 characters, a command's wrapped form up to 600. Past that, read the raw event log
• Runs with documents but no log still show — marked documents only, with no activity list but the request/response links intact. That covers a run whose raw logs you purged, and documents a teammate committed and you pulled in
• The newest 20 runs per working tree, the rest on request — those 20 are re-read every two seconds while a run is going, and a Remote-SSH window pays a round trip for each. Older runs wait behind a Show N earlier runs row at the bottom of the list; clicking it reads them once, opens the finished group, and keeps them on the list until the window reloads
• Runs from the repository's other worktrees — the skill writes its records under the working tree it ran in, so a run started in a linked worktree (git worktree add) used to be missing from a window opened on the main folder, and the other way round. The panel now lists runs from every working tree of the repository the window's folder belongs to, whichever of them the window has open. A card from a tree other than the window's own carries a ⎇ <folder name> chip; hover it for the full path. The Codex chat panel does the same, and the status bar's Codex dot and the finish chime follow those runs too. A project that commits its request documents hands copies of them to every worktree created later, so the same run can sit in several trees. It is listed once: from the tree holding its records, or failing that from the tree this window has open, and a run you trashed there stays hidden in the other trees as well
• Runs this window's conversations started in another folder — when a Claude conversation of this window runs codex_rescue in a folder the window doesn't have open, such as another repository or a folder outside any repository, the run is listed here too. From codex-rescue 1.17.3 the plugin records which conversation started each run, and where, under ~/.claude/codex_rescue/runs/ on the machine it ran on, and the panel reads that record on the machine the window points at: this PC in a local window, the server in a Remote-SSH window. This window's conversations are those of the window's project that were active within hideAfter (24 hours by default), including ones hidden from the status bar, cleared, or replaced by a newer one; runs another conversation started elsewhere stay out. The card carries the same ⎇ <folder name> chip, chimes when it finishes like any other card, and 🗑 sends it to that folder's own trash. These runs are always listed in full, outside the newest-20 limit. One drops off when its conversation leaves that window or when the plugin clears the record, after the run-record retention period (7 days by default)
• A title you can read — the request's subject heads the card, not the English slug. Runs recorded by an older skill show the slug instead
• Model, effort and tokens under the title — a small line under each card's title, visible with the card folded, shows the model and reasoning effort Codex actually ran with and the tokens the run used, as in gpt-6.1-sol - max · 7.1M; hover it for the exact figure. The count is the thread's running total with cached input included, which is why it reaches millions: every model call re-reads the conversation, mostly from cache. After a follow-up the model is the latest turn's and the count covers every turn. A running card updates its count after each model call when the plugin is 1.17.3 or later and the run is on the live-steering route (the default); otherwise the count appears when the run ends. A review run the old way (Codex's dedicated review command) may not record the model, and then only the count is shown
• Runs started together share one card — when Claude starts two or more runs at once it gives them the same batch name (plugin 1.17.3 or later), and the panel puts them inside one group card. Its head shows the batch name, how many are done out of how many, any failures, the time from the first start to the last end and the state of the worst one, with the tokens of all of them together in small print below. It is open while anything in it runs and folds once all are over; click its head to open or fold it, and it stays the way you set it. A finished group moves into the finished list as a whole. Runs from another Claude conversation never join a group, even under the same name
• Plan — shown as 2/5, but only when Codex actually produced one
• Elapsed time and activity count — no percentage. Codex never declares how many tool calls remain, so a progress bar would be fiction
• Completion chime — for runs the extension watched while they were live, using the same claudeContextBar.workflowCompleteBeep setting as workflow completion. A run that finished before the extension started appears silently

States run starting → running → finalizing → done / failed / stopped / unresponsive. finalizing is separate because Codex's turn ending isn't the run ending — the skill still has change detection and response recovery to do, and calling that window "done" would report a finish that hasn't happened. A killed run stays unresponsive instead of being promoted to done.

Cutting in while it works (1.14.0)

Codex can spend several minutes going the wrong way, and until now the only option was to watch it finish and ask again from the top. You can now add to a turn already in progress. It keeps the work it has done and folds the new instruction in rather than starting over.

An interruption stays in the activity list under a Claude chip, in the same orange the chat panel uses for Claude, with a rail down the left of the row. That is to keep it distinct from the advisories Codex prints at the start of every turn (clamping SessionEnd hook timeout to 3s) — they used to look the same, and the confusion was real.

You do not turn this on. It rides on one environment variable:

CR_LIVE_STEER=1

and the skill sets it on every consultation. Asking for it up front does not work — nobody knows at the start of a run whether they will need to cut in, and codex exec cannot change transport once it is going, so by the time you have something to say the choice is already behind you. Ask for the old path explicitly and the skill drops the flag.

With it set, the first turn of a consultation, an edit or a review runs through the app-server bridge and accepts interruptions. It started with consultations only; the skill has since extended it to edits and reviews. Request validation, the lock, change detection, the edit gate and response recovery all stay where they were. Since the skill's 1.16.1 copy, follow-ups take this path too: the bridge resumes the existing conversation and opens a new turn in it. The short back-and-forth mode still cannot be interrupted.

On this path a review gets a request written for it by the skill and runs as an ordinary turn against Codex's official review rubric, because Codex's dedicated review command does not accept anything mid-turn. The result is therefore a _response_ document, and you can ask follow-ups on it. Ask for the old way and the dedicated review command runs instead, without interruptions or follow-ups.

The bridge ships with the skill under scripts/. The plugin includes it, and so does the manual file list in the install instructions. Without it the flag refuses to start rather than falling back quietly, so you always know which path you are on.

🔴 Steering needs Node 20 or newer. The bridge uses Node's global WebSocket: 22 and 24 have it, 20 gets it once the skill adds --experimental-websocket (which it does for you), and 18 has no such flag. On 18 the consultation still runs — you just cannot cut into it, and the skill says so rather than leaving you to find out when your message goes nowhere.

The turn display below needs nothing from you, because it reads only what the skill already writes.

Follow-up turns are split apart (1.14.0)

Asking a second question stacks turns into one card. Turn boundaries now get a Turn 1 / Turn 2 header, and the turn that is still running keeps its own narration box — the sentence where Codex says what it is doing. If the last thing said in that turn was Claude cutting in, that is what the box shows, with the border in Claude's orange.

A turn stops narrating the moment it ends. The last thing a finished turn said is its entire answer document, and leaving that pinned under the header buried the rest of the run in one enormous block of text. The answer is not lost — it is one click away on the header itself.

Each header carries its own Open result and Open request pair. The request really is a separate file per turn: turn 1 has the original request, turn 2 onward the rebuttal that opened it. The result is not — every turn appends to the same response document — so a turn's result link opens that document and jumps to that turn's section rather than dropping you at the top.

Each header also shows when that turn started and how long it took. The card's own clock runs from the first turn to the end of the last, with the time Codex actually spent working beside it — took 43:11 (work 12:47). The difference is the time between turns, while Claude read the answer and wrote the next question. Before 1.17.1 the card clock restarted with every follow-up, so a six-turn run that took 43 minutes showed only its last turn's 1:20. From turn 2 on, a turn's start is when the rebuttal that opened it was saved, so it can be a few seconds early. The number of turns also sits in a chip beside the mode (FOLLOWUP 6 turns), so it can be read with the card folded.

Clicking a turn header collapses it. A long consultation can put fifty activities in one card, and folding the turns you have already read leaves the one you care about on screen. The state survives the refresh, and turns start open: you opened the card to read it.

Single-turn runs look exactly as they did. Headers, per-turn links and times, and folding appear only on cards that actually have a follow-up.

One bug went with it. codex exec resume numbers each turn's activities from item_0 again, and the panel keyed activities by that number alone, so turn 2 overwrote turn 1. A real two-turn run showed twelve activities out of twenty — and the missing ones were scattered, not the last eight, because only colliding numbers were replaced. A row that had been a file change in turn 1 came back as a command in turn 2 and kept its place: the activity had not vanished, it had become a different one.

What it creates in your project

The first run creates docs/codex_rescue/ inside your project. The panel reads only this directory — no network calls.

• <stamp>_request_*.md · <stamp>_response_*.md — what was asked and what Codex answered. These are meant to be committed; the next session picks up the thread from them
• .log/ — raw run records. Full command output lands here, so size varies a lot by run (a few hundred KB per run is typical, and a run that allows cutting in also keeps its full app-server transcript, often several MB); the skill drops its own .gitignore in this directory to keep it out of git
• .scratch/ — Codex's workbench: scripts, dumps and intermediate data it made while investigating. Responses often point at files here as evidence. Also kept out of git

The plugin cleans up after itself each time codex_rescue runs. With codex-rescue 1.17.3 or later, in that project it removes the app-server transcript of every run that finished successfully, anything in .scratch/ not touched for more than a day, and a run's files in .log/ once the newest of them is more than 7 days old. It no longer skips .scratch/ while another run in the same project is going: a running run's own folder there is left alone, and anything else past the day goes. On the machine it also removes its note of which conversation started each run (~/.claude/codex_rescue/runs/) after the same 7 days. The request/response documents, the trash, a run that is still running and the run that is just starting are never touched. Up to 1.17.2, .log/ and .scratch/ were both kept for 7 days and .scratch/ was skipped while another run was going.

From codex-rescue 1.17.3 the plugin also removes Codex's own session logs for the conversations it started, once they are older than the run-record period. Those are the rollouts under ~/.codex/sessions (or $CODEX_HOME/sessions) that Codex marks as started by codex_rescue; conversations you start yourself in the Codex app, CLI or IDE extension are never touched. Only runs on the live-steering route carry that mark: conversations from the chat tab, and runs that took the old codex exec route, are recorded like any other codex exec conversation and cannot be told apart from your own, so they are neither removed nor counted. It uses Codex's official codex delete --force, one conversation at a time, so Codex's internal database stays in step with the files, and a sub-agent's log goes with its parent. This pass covers every project on the machine, runs in the background and is not waited for by the Codex run. Each conversation takes a few seconds, so a first pass over a long history can take a while; one that gives no answer within two minutes is skipped until the next pass. Only one pass runs at a time on a machine, and it writes what it did to ~/.claude/codex_rescue/codex-prune.log. The conversation a follow-up is about to continue is left out. A run whose Codex conversation has been removed can no longer take a follow-up question. Codex's database files do not shrink when entries are removed.

With codex-rescue 1.17.3 or later, the two periods, 1 day for work folders and 7 days for run records, are set in the settings panel's Codex — Run History Retention section. It is not a VS Code setting: it edits the plugin's own file, ~/.claude/codex_rescue/settings.json, on the machine the window points at (the server, in a Remote-SSH window), and the plugin reads it on its next run. Earlier versions ignore the file. Without the extension, edit that file directly, as in {"scratchDays": 1, "logDays": 7}. 0 turns that cleanup off, and a logDays of 0 leaves Codex's session logs alone as well. While the file is not valid the plugin skips cleanup altogether, and the settings panel says so. The CR_KEEP_DAYS environment variable still works and, when set, replaces both periods (0 turns all of it off), though a broken file stops cleanup even then; to apply it to every session, put it in the env block of ~/.claude/settings.json. All of this happens in the plugin, not the extension, so it works the same without VS Code. For anything sooner, the 🗑 button on a card takes the whole run, documents included, straight to the trash.

After each cleanup the plugin writes how much is left to .log/_usage.json, and with plugin 1.17.3 or later the Codex progress tab shows it in a line under its toolbar, for the window's first folder: work folders, run records, trash, and the Codex conversations codex_rescue started in this project, with the time they were measured. The figures date from the last Codex run in the project; they are not live. Clean up beside them lets you tick any of the four, shows how much will go, and asks once more. It then opens a terminal in the project and runs the plugin's own cleanup command there, where you can follow it. A ticked item goes in full whatever its age, and nothing passes through the trash. Ticking the trash empties it documents and all, without the logs-or-documents question Empty trash asks. What a run still in progress is using stays, and so does a run Codex has finished but whose result Claude has not picked up yet. Codex conversations are removed with the same official command, one by one, and are skipped if the background pass happens to be running. The button only runs a cleanup program the plugin recorded under ~/.claude for this very project; a record copied from another folder, or a path the terminal would read differently, is refused before anything runs.

Trash

Deleting from a card doesn't destroy anything. The run — logs and documents together — moves into a trash you open with 🗑 at the top of the panel, and it stays there until you empty it. Nothing expires on a timer.

The choice comes at the far end. Delete for good asks whether to take the raw logs only or the documents as well, and the button tells you what is at stake before you click: red when documents are all that's left, amber when the logs can still be given up first, neutral when only logs remain. Keeping the documents leaves them in the trash on their own — deliberately, since the logs are bulk and the documents are the record of what was asked and answered.

Three more things worth knowing:

• The plugin's automatic cleanup never touches the trash. It exists to reclaim disk, and a trash filling as fast as cleanup empties would defeat that. Clean up can empty it when you tick it.
• Restoring never overwrites. codex_rescue re-runs a dead request under the same stamp, so a name a trashed file wants can belong to newer work. Those files stay in the trash and are reported.
• A run still in the trash is not trashed again. If a restore left files of a run behind and you press 🗑 on its card again, nothing is moved and those files are kept; a notice asks you to restore or delete that trash entry first. The Codex chat panel works the same way.
• A run still holding its lock is refused — send.sh may be mid-write, and moving a file out from under it would corrupt the record rather than preserve it.

Files move rather than copy, so this costs nothing extra on a Remote-SSH workspace. The trash writes its own .gitignore, the way the skill does for .log/, so trashed documents never show up as something to commit.

Works over Remote-SSH. Run records are read from the remote workspace through vscode.workspace.fs — the same path the extension already uses for Claude and Codex session files — so the extension itself doesn't go on the server. Starting a run there is a separate matter: that needs Codex CLI and the codex_rescue skill installed on the server. One difference: the VS Code file API has no range read, so a live run's event file is transferred whole instead of by delta. Status and the completion chime still refresh every 2 seconds; the activity list refreshes at most every 5 seconds, which keeps a few hundred KB off the wire on most of those ticks.

💬 Codex chat panel (optional)

codex_rescue also has a short back-and-forth mode. Unlike the one above — write a request, wait a few minutes — you throw a line at Codex mid-conversation and get an answer in about ten seconds. That answer lands straight in the Claude Code chat window, but once a conversation runs a few turns those turns end up scattered between everything else that was said. This panel puts one conversation back on one screen.

It is the activity panel's tab next to Codex progress. One conversation is one card, and the newest of this session opens expanded — re-reading almost always means the one that just happened.

• Earlier conversations fold away — a conversation with no turn since this session began folds into one "N from earlier sessions" row, closed each time the panel opens. This session starts when the earliest Claude conversation the status bar shows for this workspace started, since a chat document does not record which conversation wrote it. With no such conversation on the status bar, every chat counts as an earlier one
• Who spoke reads as colour first — Claude in orange, Codex in blue, matching the provider glyphs in the status bar
• Turn count and the machine it started on — conversation documents travel through git; Codex sessions do not. A conversation started on another PC cannot be resumed here, so the card names that machine
• Breaks stay visible — where a run died and the thread was discarded, or where a new conversation replaced the old one. Without those markers there is no way to tell why the context suddenly changed
• The question shows first — during the 7–13 seconds a turn is in flight, the line just thrown appears on the card immediately and Codex's side reads as waiting for an answer. The answer fills that slot when it lands. A card is created even on a conversation's first turn, before the document exists
• It follows new turns down — if you are at the bottom, the view keeps up on its own. If you have scrolled up to reread an older turn it does not move the page; a New reply ↓ button appears instead, so you keep your place and still know something arrived
• One turn reads as the current one — the rest fold down to the first line of their question. Which turn that is depends on why you are looking: the first time the tab shows, or a conversation you have not looked at this session, opens its first turn, because you read a past conversation from the top. A turn arriving in a conversation you are already watching opens that last turn instead. Turns you opened or folded by hand are left exactly as you set them
• Click the document name to open the original in an editor

Ping-pong turns never appear in the progress panel. That one is for watching work that takes minutes, and ten-second exchanges piling up there would only get in the way.

Its trash is separate

This panel uses a completely separate directory from the progress panel's trash. Neither panel can surface or destroy the other's items, and a conversation and a run can share a stamp without colliding.

Deleting from a card goes straight to the trash without a prompt — it is reversible, so a question there only stands between you and something you can undo. The confirmation lives at delete-for-good and empty, which is the one point of no return.

There is no automatic cleanup. Run logs are bulk, so there is a reason to drop old ones; a conversation is the record itself. Age is not a reason to destroy it.

🤝 peer_req — open sessions asking each other (plugin)

A separate Claude Code plugin from this repository, not part of the extension. It lets your open sessions ask and notify each other directly — two repositories on the same PC, your PC and a server, or two servers — with a request ID, an acknowledgement and a record on both sides, so nothing is confused between "sent" and "read" and nothing runs twice. When the other session isn't open, it can run the request unattended in that repository after asking you.

It requires Remote Control to be on in every session you pair. Sessions on other machines are reachable only through it. Install with /plugin marketplace add comonetso/claudeStateBar and /plugin install peer-req@comonetso; setup, the address book and the Remote Control steps are in the peer_req README (한국어). The extension's auto-update notice (see codex_rescue above) covers this plugin too.

🔍 browser_check — Claude checks your real browser (plugin)

A third plugin from this repository, also separate from the extension. Instead of reporting "tests pass" from server logs and source alone, Claude Code opens the page in ego lite, a Chromium browser on your Windows PC kept for agents, and checks it itself: the screen, console errors, failed requests, CSS, responsive and dark layouts, accessibility and performance. You sign in to your sites in ego once; Claude's checks then open them signed in, in a task space of their own that never touches your tabs. It runs locally on the PC, or from a server session through a small relay on the PC, and starts from plain Korean requests such as "화면 확인해 봐" (check the screen) or "콘솔 에러 봐" (look at console errors). Most checks are one command, browser-check look <url>, which returns the page text, a capture, the errors and every request other than GET the page sent; clicks and typing can be added as steps.

A policy layer sits between Claude and the browser. It works only in its own task space, changes data only with your approval for that exact change, lists what a click sent, and does not read or store secrets. Captures work while ego is minimized or closed. Install ego lite on the PC and sign in there, then /plugin install browser-check@comonetso, and on the PC run browser-check relay install so servers can use it. On first use it looks the machine over, writes its private settings file and shows you what it put in; the relay and the full safety rules are in the browser_check README (한국어). Up to 0.1.x it drove Aside; from 0.2.0 it uses ego lite only. Measured on a Windows PC and from three Linux servers through the relay. The extension's auto-update notice covers this plugin too.

📱 android_check — Claude taps and debugs your real Android device (plugin)

A fourth plugin from this repository, also separate from the extension. It ends debugging by pasted screenshots: Claude Code finds an element on a real Android device or emulator by name and taps it, captures the screen at the same moment, cuts that moment's logcat down to the app's own lines (errors, frame-skip warnings, and whether the touch reached the app at all) and measures the response time. After a fix it re-runs the app itself — Flutter hot reload, or a Gradle reinstall for a native app — and repeats the same tap. Multi-step flows that need judgement can go to the ARTEMIS MCP if you have it. It works with Flutter apps and native (View, Compose) apps, and starts from plain Korean requests such as "폰 화면 봐" (look at the phone screen) or "눌러 봐" (tap it).

It needs adb; response timing also needs Python with Pillow. Install with /plugin install android-check@comonetso. On first use it looks the machine over and writes a private settings file (adb path, device and app details never go into the repository); a doctor check reports what blocks it, such as a locked phone or a screen-mirroring app whose black overlay window swallows every tap. Details and measured numbers are in the android_check README (한국어). This is an early version, measured on one Galaxy phone over wireless adb with debug builds of a Flutter app and a native app. The extension's auto-update notice covers this plugin too.

🎚️ Effort level display

The status bar and tooltip show Claude Code's current effort level:

Additional speed indicators:

• ⚡ — /fast mode is active

🔔 Sound alerts

Claude Code & Codex Status Bar plays configurable WAV sounds for key events:

All sound paths can be overridden with your own WAV file. Gain is adjustable from 50% to 300% (high gains can distort). Use claudeStateBar: Test Beep Sound from the Command Palette to preview.

Codex shares these sounds. An ordinary Codex turn's completion beep (fired from task_complete) uses soundCompletion. When that parent turn spawned agents, its final all-agents completion is routed to soundWorkflow instead, so the ordinary and workflow sounds do not both fire. There are no Codex-specific sound settings. Codex question-pause and stuck-detection beeps are not implemented yet.

Workflow‑complete beep gate — the beep fires only when the extension watched a workflow go running → done in the current session. For Claude workflows (wf_*) it waits for the run's completion record (workflows/<wfId>.json, status: "completed"). For Codex it follows explicit source.subagent.thread_spawn.parent_thread_id links (including nested descendants) from the latest parent task_started, then requires both every linked spawned-agent rollout to finish and the parent task_complete — the same terminal boundary as agent-turn-complete. Sequential batches therefore beep once at the very end, not during a gap between batches. Failed/aborted runs do not fire the workflow-success sound, and stale work already complete when VS Code starts is baselined silently.

Conversations started from Paseo — Paseo is a desktop and mobile front end for Claude Code and Codex. Where this repository's Paseo plugin claude-state-bar is installed and enabled, it plays the completion, question, warning and danger sounds for Paseo's conversations inside the Paseo app, so the extension skips those four for them; otherwise each would sound twice. The workflow sound still plays here for every conversation; the plugin plays it too, so with the plugin installed it can sound twice. A conversation counts as Paseo's when its session id is in one of Paseo's records under ~/.paseo/agents/, and the plugin as enabled when ~/.paseo/config.json says so, both on the machine the window points at. Both are read only at the moment a sound is due. Without Paseo, or without the plugin, nothing changes.

🖱️ Merged tooltip

Hovering any session item shows one tooltip split into two clearly labelled, colour‑divided sections:

my-project (a1b2c3d4)
──────── claudeState ────────
📊 Session: 30% — 5:40 PM (in 3h 27m)
📅 Weekly: 20% — 3:00 PM (Sat)
Fable: 12%  Opus: 4%
──────── claudeContext ────────
🤖 Model: claude-opus-4-7
🎚️ Effort: xHigh⁺
📊 Context 37K / 1.0M (4%)
| Cache Read | 8K |  | Cache Creation | 28K |
🕐 Last updated: 2:10:58 PM
Click for menu (hide / restore / settings)

📈 Claude Status panel

Claude Status sits in the session menu directly above Settings, and opens a panel with two tabs. It only ever reads.

Usage opens with a card for each conversation currently on the status bar: how long it has been going, how much of that it spent working, how many lines of code it changed, how many API requests it made, and its token split. It is the summary the CLI prints when a session ends, except live. Where a session has already ended, Claude Code leaves its own record behind and the card shows that instead — real API time rather than an estimate.

It also puts a price on it. Cost (API rate) shows what the conversation's tokens would have cost on the Anthropic API. It is an estimate, not your bill. Hover the figure for the rates and the per-model split. A model whose rate the extension doesn't know is left out of the total and flagged. The Stats tab carries the same conversion for your whole history.

Rates used are the official price list, per 1M tokens in/out: Opus 5.5 $4/$20, Opus 4.5 to 5 $5/$25, Opus 4 and 4.1 $15/$75, Sonnet 5 and 5.5 $2/$10, Sonnet 4 to 4.6 $3/$15, Haiku 4.5 $1/$5, Haiku 3.5 $0.80/$4, Fable and Mythos 5 and 5.1 $10/$50. A cache write costs 1.25× the input rate on the 5-minute cache and 2× on the 1-hour cache, which is the one Claude Code nearly always uses; a conversation's log says which one each request used. The Stats tab reads Claude Code's own totals, which don't make that split, so it prices every cache write at the 1-hour rate. A cache read costs 0.1× the input rate, except on Opus 5.5 (0.05×) and on Fable and Mythos 5.1 (0.025×). A model that isn't on the list, including one released after this version, is left out of the total rather than priced by guess.

Each token figure shows its share of the amount beside it.

Under that is how much of the plan is left — the 5‑hour window, the weekly cap, and each per‑model weekly cap — each with the clock time it resets and how far off that is. Then what has actually been consuming the limit over the last 24 hours: the share of usage that happened in contexts above 150k tokens, and a breakdown by skill. Those figures are worked out from the session logs on this machine, so work done on other devices or on claude.ai is not in them.

Stats reads the statistics file Claude Code keeps as you use it, and shows an activity heatmap, total tokens with the input / output / cache split, session count, longest session, active days, streaks, and each model's share. That file only runs to yesterday, so today is counted separately and added on.

⚙️ Settings panel (webview, EN/KO)

Open claudeStateBar: Open Settings Panel from the Command Palette for a single panel with a runtime English / 한국어 toggle. It collects Org ID, Session Key, refresh interval, Telegram Bot Token (auto‑detects your Chat ID), sound settings (with preview), and context‑monitor options. Sensitive values go to encrypted SecretStorage; everything else syncs with VS Code settings. The one exception is the Codex — Run History Retention section, which edits the codex-rescue plugin's own retention file on the machine the window points at (see What it creates in your project).

Refresh now is in the session menu directly below Settings, and the settings panel has the same button. Both re-read Claude and Codex usage at once. Codex normally reuses a reading another VS Code window has just taken; a manual refresh asks Codex directly instead. Since a fresh number is one click away, the refresh interval can stay long.

How to get your credentials

• Org ID — claude.ai → DevTools → Network → any /api/organizations/{UUID}/… request
• Session Key — claude.ai → DevTools → Application → Cookies → sessionKey

🔔 Telegram session‑reset alerts (optional)

Add a Telegram Bot Token in settings, send your bot any message, click "Link my Telegram" (Chat ID auto‑detected), and you'll get a notification every time your Claude 5‑hour session window resets. The switch is claudeState.telegramNotifyOnReset, on by default once a token and chat ID are in place.

The alert carries the weekly figure together with how long that weekly window still has to last — Weekly usage: 42% (in 3d 9h). The calendar date is left out on purpose: on a phone notification the remaining time is what you act on, and the exact turnover timestamp is a tooltip away.

🚀 Auto‑start the next block once a reset is detected (optional, off by default)

A 5‑hour block is an anchor model: it starts from your first message and resets exactly 5 hours later — it does not auto‑cycle on a fixed schedule. So if a block resets while you're away, nothing opens until you next type.

Turn on claudeState.autoStartBlockOnReset and the extension fires a throwaway claude -p prompt the moment it detects the block has closed (session usage drops to 0%), opening the next block for you. The primer runs in its own temp directory, and those dummy sessions are filtered out of the status bar.

• Fires once per reset — even across multiple VS Code windows or a wake‑from‑sleep burst — via an atomic 10‑minute event lock.
• Wake‑from‑sleep: if the machine slept through a reset, the primer fires on the first poll after you wake, so you wake up to an already‑started block. While awake it fires on the first successful plan‑usage poll after the block closes — every 5 minutes by default (claudeState.refreshIntervalSec), so the new block anchors at detection, not at the reset instant.
• ⚠️ The new window starts counting down immediately — including while you sleep. That's the point, but know it.
• Requires the claude CLI on your PATH and VS Code running. While the machine is fully asleep, polling is paused — so the primer fires on wake, not at the exact reset instant. For reset‑instant firing you'd need an OS scheduler.

Toggle this and the Telegram reset alert from the settings panel (Telegram section).

Billing safety

The primer only makes sense while headless claude -p runs draw on your subscription. Anthropic has floated billing them to the API instead, so:

• It refuses to fire when ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN is set in the environment (that call would bill API credit, not your plan), and turns the setting off with a warning.
• It verifies afterwards that a block actually opened by checking sessionResetAt moved to ~5 hours out — the tiny dummy prompt doesn't move session %, so resetAt is the real signal. With no API key there is no billing hazard, so a failed verification is logged but does not disable the feature.

⏱️ Codex 5‑hour resets

Codex's 5-hour window follows the same anchor model, so it has the same gap: when the window closes while you're away, nothing opens until you next run Codex. The extension already polls the Codex account limits for the status bar, and now watches that reading for the moment the window closes.

Only accounts that actually have a 5-hour limit get this. Plus does; Pro is weekly-only today. The check reads whether a 300-minute window arrives in the account data rather than looking at the plan name or at which slot a window comes in (a Pro Lite account sends its weekly window in the slot Plus uses for the 5-hour one) — OpenAI has said Pro will get one eventually, and this way that day needs no code change. An account without the limit is excluded from reset alerts and auto-start entirely, and its status bar leads with the weekly figure instead of leaving a blank.

Two things can happen at that moment, each with its own setting so that running only one of the two CLIs never forces the other's behaviour on you:

• claudeState.codexTelegramNotifyOnReset (on by default) sends a Telegram alert titled Codex session reset, with the weekly figure and weekly turnover worded exactly as the Claude one.
• claudeState.codexAutoStartBlockOnReset (off by default) fires a throwaway codex exec to anchor the next window to the reset.

The Codex primer runs with --ephemeral, so it writes no session file at all and nothing from it can surface in the status bar. It runs read‑only, in its own temp directory, outside any git repo.

How the close is detected differs from the Claude side, and it has to. Codex reports the window like this:

• open — resetsAt is a fixed timestamp (open time + 5 hours), identical on every poll
• closed — resetsAt is always "now + 5 hours", so it advances with the clock

Usage is not used to decide this. A window you simply aren't using also reads 0%, and reading it that way announced a reset every time the machine woke from sleep. The alert now fires only when the window genuinely goes from open to closed.

If that moment passes without anything happening — the setting was off at the time, or the attempt failed — a window left closed for ten minutes gets opened anyway, and that repeats while it stays shut. No Telegram message is sent for those: it isn't a reset.

Billing safety

codex exec draws on API credit rather than your 5‑hour window when Codex is signed in with an API key, and it would exit 0 either way. So the primer reads auth.json before firing and refuses unless it finds a ChatGPT‑plan login (auth_mode: "chatgpt") and no OPENAI_API_KEY — neither in the file nor in the environment. The check exists precisely so it never has to guess about spending money.

Two different refusals, and they are not treated the same. An API key that is actually there turns the setting off and tells you why — that one is a real billing hazard. A file it could not read only skips that one reset and leaves the setting alone; not being able to read a file is an absence of evidence, not evidence of a key. The primer always reads the local home directory, so a Remote‑SSH window can't send it looking at a server path.

Afterwards it verifies a window actually opened by watching resetsAt come to a stop across two readings. Checking that it sits ~5 hours out would prove nothing — a closed window reports exactly that on every poll, so such a test passes whether or not anything happened. Once the plan login is confirmed there is no billing hazard, so a failed verification is logged and left alone rather than disabling the feature.

🧹 Zombie status‑bar cleanup

When VS Code updates the extension while a window is open, the old instance's status‑bar items can remain as unresponsive "zombie" pixels. Claude Code & Codex Status Bar handles this two ways:

1. Version‑change detection — on activation, if the version changed since last run, a one‑time "Reload window to clear stale items?" notice appears.
2. QuickPick cleanup — the session menu always ends with a 🗑 Clean up stale/zombie items (Reload Window) option.

Configuration

All keys are prefixed claudeContextBar.* or claudeState.*.

Core display

Sound alerts

Plan usage

(Session Key, Bot Token and Chat ID are stored in SecretStorage, not in settings.json.)

Codex

Codex run logs (codex_rescue)

There are no extension settings for these any more. Since 1.16.7 the codex_rescue plugin removes old records itself each time it runs (see What it creates in your project). From plugin 1.17.3 its retention periods live in its own file, ~/.claude/codex_rescue/settings.json on the machine it runs on: 1 day for work folders and 7 days for run records by default, 0 to turn one off. The settings panel's Codex — Run History Retention section edits that file for the machine the window points at. The CR_KEEP_DAYS environment variable, when set, replaces both. The codexRunAutoCleanup, codexRunRetentionDays and codexRunDeleteDocs settings were removed; if you had set them, VS Code will show them as unknown and they can be deleted.

Deleting a run from the panel (🗑) takes the whole run — documents included — to the trash without asking, and the button only appears on finished runs. The prompts sit at the irreversible end instead: purging one run, or emptying the trash.

All other settings — thresholds, sounds, compactMode, idleTimeout, hideAfter, scope — are shared by Claude and Codex.

Requirements

• VS Code 1.74.0+
• Claude Code running and writing session logs to ~/.claude/projects/
• For plan usage: a claude.ai account (Org ID + Session Key)
• For Codex sessions (optional): OpenAI Codex writing rollout logs to ~/.codex/sessions/ — on the local machine, or on the remote host in a Remote‑SSH window

How it works

Context monitoring makes no network calls at all. It reads the log files Claude Code and Codex leave on disk, nothing more — local or remote. The workflow viewer is the same.

Only three things touch the network, and all three are optional.

• claude.ai plan usage — calls the usage endpoint and nothing else
• Telegram — only when enabled, and only to send an alert
• Codex account usage — asks your locally installed codex; falls back to the value left in the logs if that fails

All three are lookups. No code and no conversation content leaves your machine.

⭐ Found this useful?

Star the repo. That's it — that's the whole ask.

Downloads tell me a number. A star tells me a person. If this has saved you from blowing through a context window or a weekly limit even once, please spend the two seconds:

→ github.com/comonetso/claudeStateBar

Bug reports and feature requests are welcome in Issues.

Credits

Original context‑monitoring core by Ed Zisk — Claude Context Bar. This extension builds on that foundation, adding Claude.ai plan usage, Remote‑SSH support, Telegram notifications, a webview settings panel, workflow/agent viewer, sound alerts, and more — maintained by Blueming.

License

MIT © 2026 Blueming. Original core © 2024 Ed Zisk.