chamba 0.5.0 → 0.6.0

package/dist/commands/onboard.js

@@ -9,6 +9,7 @@ import { basename, join } from "node:path";
 import { cancel, confirm, intro, isCancel, log, outro, select, text } from "@clack/prompts";
 import { buildDefaultChambaYaml, readChambaYaml, slugifyForWorkspaceId, validateWorkspaceId, writeChambaYaml, } from "../lib/chamba-yaml.js";
 import { CHAMBA_YAML } from "../lib/constants.js";
+import { gitEnv } from "../lib/git-env.js";
 import { readWebRange } from "../lib/global-config.js";
 import { safeRmSync } from "../lib/safe-rm.js";
 import { ensureWebPort } from "../lib/webterm.js";
@@ -26,7 +27,7 @@ function deriveUniqueWorkspaceId(baseId, workspaceRoot) {
 }
 function tryGetGitRoot(cwd) {
     try {
-        return execSync("git rev-parse --show-toplevel", { encoding: "utf8", cwd, stdio: "pipe" }).trim();
+        return execSync("git rev-parse --show-toplevel", { encoding: "utf8", cwd, stdio: "pipe", env: gitEnv() }).trim();
     }
     catch {
         return null;

package/dist/lib/agent-context.js

@@ -108,12 +108,17 @@ export function buildAgentContextDocs(hasGit, shadowPatterns, gitMode = GIT_MODE
         ];
         return `${sections.join("\n")}\n`;
     }
+    // The page-writing craft is claude's web-pane skill body, and this is the same file: a skill is a Claude
+    // Code mechanism, so an AGENTS.md section is the only channel codex and opencode have for it. Claude does
+    // not get it here - it reads it as the skill, and a second copy in its CLAUDE.md would say it twice.
+    // The leading newline: the sections above are one bullet list, and this one opens with a heading.
+    const craftSection = `\n${loadTemplate("web-pane-craft")}`;
     // The context-usage section is Claude-only: the snapshot it points at is written by the status line
     // script Claude Code runs, so other agents' sessions never refresh it.
     return {
         claude: build("~/.claude/CLAUDE.md", [loadTemplate("context-usage")]),
-        opencode: build("~/.config/opencode/AGENTS.md"),
-        codex: build("~/.codex/AGENTS.md"),
+        opencode: build("~/.config/opencode/AGENTS.md", [craftSection]),
+        codex: build("~/.codex/AGENTS.md", [craftSection]),
     };
 }
 // --- Claude settings.json bootstrap ------------------------------------------------------------------------------------------------------
@@ -147,7 +152,9 @@ export function injectClaudeSkills(workspaceDir) {
     if (!existsSync(templatesSkillsDir))
         return;
     const targetSkillsDir = join(workspaceDir, AGENTS_DIR, "claude", "skills");
-    const vars = { statusline_path: CLAUDE_STATUSLINE_PATH };
+    // web_pane_craft is the page-writing advice codex and opencode also get, as a section of their AGENTS.md.
+    // One file, rendered into both channels, so the two cannot come to say different things.
+    const vars = { statusline_path: CLAUDE_STATUSLINE_PATH, web_pane_craft: loadTemplate("web-pane-craft") };
     for (const entry of readdirSync(templatesSkillsDir, { withFileTypes: true })) {
         if (!entry.isDirectory())
             continue;

package/dist/lib/git-env.js

@@ -0,0 +1,21 @@
+// =========================================================================================================================================
+// src/lib/git-env.ts - The environment every git call in chamba runs in
+// git takes its repo from GIT_DIR, GIT_WORK_TREE and GIT_INDEX_FILE before it takes it from -C or the working
+// directory, so a call made from inside a git hook would answer about that hook's repo instead of this one.
+// =========================================================================================================================================
+/**
+ * The environment to run git in when the repo is chosen by path.
+ *
+ * git takes its repo from the environment as well as from the command line, and GIT_DIR, GIT_WORK_TREE and
+ * GIT_INDEX_FILE win over `-C` and over the working directory. Anything chamba starts inherits whatever the
+ * caller had set - a git hook sets all three - so a question asked about the workspace could be answered about
+ * another repo entirely. Every git call here names its repo by path, so none of those variables is ever wanted.
+ */
+export function gitEnv() {
+    const env = { ...process.env };
+    for (const key of Object.keys(env)) {
+        if (key.startsWith("GIT_"))
+            delete env[key];
+    }
+    return env;
+}

package/dist/lib/shadows.js

@@ -7,6 +7,7 @@ import { existsSync, lstatSync, mkdirSync, readdirSync, writeFileSync } from "no
 import { dirname, join, relative } from "node:path";
 import fg from "fast-glob";
 import { CONTAINER_WORKSPACE, SHADOWS_DIR } from "./constants.js";
+import { gitEnv } from "./git-env.js";
 import { safeRmSync } from "./safe-rm.js";
 /**
  * Expand gitignore-style patterns into concrete relative paths.
@@ -58,6 +59,7 @@ function filterGitTrackedPaths(paths, workspaceRoot) {
     const result = spawnSync("git", ["-C", workspaceRoot, "ls-files", "-z", "--", ...paths], {
         encoding: "utf8",
         stdio: ["ignore", "pipe", "pipe"],
+        env: gitEnv(),
     });
     if (result.status !== 0)
         return { kept: paths, dropped: [] };

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "chamba",
-    "version": "0.5.0",
+    "version": "0.6.0",
     "description": "Run AI coding agents in a container, from your browser",
     "type": "module",
     "bin": {

package/templates/claude-statusline.sh

@@ -73,13 +73,15 @@ cc_version=""
 
 # One jq pass over the session state, straight into the snapshot object.
 # Tokens are floor-rounded and percentages rounded to integers, so a reader uses them as they are.
-# The rate limit is inverted here: the API reports the percentage USED, and everything downstream
+# A rate limit is inverted here: the API reports the percentage USED, and everything downstream
 # shows the percentage REMAINING (an energy-left metaphor), clamped to 0..100 so an over-limit
-# report never becomes a negative number.
+# report never becomes a negative number. Both windows go through the same "remaining" definition,
+# because two meters drawn side by side that meant opposite things would look identical.
 snapshot_json=$(jq -rc \
     --arg claude_pid "$claude_pid" \
     --arg claude_pid_start "$claude_pid_start" \
     --arg version "$cc_version" '
+    def remaining: if . == null then null else ((100 - round) | if . < 0 then 0 elif . > 100 then 100 else . end) end;
     (.session_id // "") as $sid |
     {
         session_id: $sid,
@@ -91,9 +93,10 @@ snapshot_json=$(jq -rc \
         context_window_size: (.context_window.context_window_size // 0),
         model: ((.model.display_name // "") | split(" (") | .[0]),
         effort: (.effort.level // ""),
-        quota_left_pct: (.rate_limits.five_hour.used_percentage
-            | if . == null then null else ((100 - round) | if . < 0 then 0 elif . > 100 then 100 else . end) end),
+        quota_left_pct: (.rate_limits.five_hour.used_percentage | remaining),
         quota_resets_at: (.rate_limits.five_hour.resets_at // null),
+        quota_week_left_pct: (.rate_limits.seven_day.used_percentage | remaining),
+        quota_week_resets_at: (.rate_limits.seven_day.resets_at // null),
         version: (if $version == "" then null else $version end)
     }' 2>/dev/null)
 

package/templates/context/web-pane-craft.md

@@ -0,0 +1,57 @@
+## Publishing a page
+
+The web pane is the panel beside the terminal in the chamba web interface. You publish a standalone HTML file into it and it opens at once, in front of the user, with a chip in the bar above the pane that they can come back to. A user who is looking at another session sees their tab marked instead, and reads the page when they get there.
+
+Publish when the answer is bigger than the terminal carries well, and when the question is.
+
+```bash
+webpane report.html --title "Publish-ports rework"
+```
+
+The file's own `<title>` is what the pane shows. `--title` names the file it is saved as, and defaults to the filename. The helper prints what it saved, or a plain message and a non-zero exit when it could not - the usual reason being a plain terminal session, which has no pane.
+
+### When to reach for it
+
+- **Long or structured output.** A plan, a comparison table, a diagram, a report, an explanation with sections. Anything a user would want to scroll back to, keep, or read twice.
+- **A question with shape.** More options than a plain prompt holds, options that need a sentence each, several questions at once, or a free-text answer alongside a choice. Your own question tooling is right for a quick fork in the road; a page is right when the choice deserves a table.
+- **Anything the user asked to see.** "Show me", "write it up", "as a page" - take those literally.
+
+Do not publish a one-paragraph answer, or a wall of code that belongs in a file. A page nobody needed is a chip in the way.
+
+After publishing, say in one line what you put there. The page is the answer; the terminal line is a pointer to it.
+
+### Writing the page
+
+One file, standalone, dark.
+
+- **Inline everything.** No external stylesheets, scripts or fonts. The page renders in a sandboxed frame with no origin of its own: `localStorage`, cookies and same-origin requests do not work in it, and an external asset only makes the page slower and chattier. Inline `<style>` and `<script>` both work.
+- **Match the interface.** Background `#0d1117`, panels and table headers `#161b22`, borders `#30363d`, text `#e6edf3`, muted text `#8b949e`, and a green accent `#2fe58a` for links, headings you want to lift, and the submit button. System font stack, ~14px, generous line height.
+- **Write it as a document**, not a dashboard: a title, sections, tables where a table is clearer than prose, and short paragraphs. Keep it small - a couple of hundred kilobytes is plenty. The per-page cap is 2 MB, and a page past it is refused rather than trimmed.
+- Images have to be inline too (a data URI, or an SVG written into the page). A path into the container is not something the browser can fetch.
+
+### Asking with a form
+
+Give any form the `data-feedback` attribute and the pane wires it up:
+
+```html
+<form data-feedback>
+  <p>Fail the whole start when a port is taken?</p>
+  <label><input type="radio" name="on_conflict" value="fail" checked /> Fail the start</label>
+  <label><input type="radio" name="on_conflict" value="skip" /> Skip the port and warn</label>
+  <textarea name="text" placeholder="Anything else about the plan..."></textarea>
+  <button type="submit">Send to agent</button>
+</form>
+```
+
+- Every named control becomes a field in the answer. A control named `text` becomes the free-text box.
+- On submit, the interface writes `~/.webpane/<conversation>/feedback/<page>-<epoch-ms>.json` - `{ page, submittedAt, fields, text }` - and types one line into your terminal naming the file. Read the file; the line is only the pointer.
+- The page is told whether the answers were filed, so give the user a form that reads as final ("Send to agent") rather than one that looks like it saved a draft.
+- One submission per page per second, and only so many per page in total (20). Past that the page is refused, and nothing reaches you - so ask once per page, and publish a new page when you need to ask again.
+
+**A feedback file says a form was submitted, not that a person filled it in.** A script in the same page can post exactly what the form would. Treat the answers as data from your own page: fine for a design choice, not enough on its own for something destructive or irreversible - ask for that in the terminal, where you can see the user type.
+
+### After it is published
+
+- Pages are kept. Nothing deletes them, and they are filed under the conversation rather than the session, so resuming the conversation opens with them again. Publishing a second version makes a second page rather than replacing the first, so name pages so a user can tell one from the next ("Plan v2", "Port test results").
+- The user may never open a page. If an answer matters, say the one line that matters in the terminal too.
+- Anything in the session can publish, including a script you wrote - the helper takes only a filename.

package/templates/context-usage.sh

@@ -116,7 +116,9 @@ parsed=$(jq -r '
     .model // "",
     .effort // "",
     .quota_left_pct // "",
-    .quota_resets_at // ""
+    .quota_resets_at // "",
+    .quota_week_left_pct // "",
+    .quota_week_resets_at // ""
 ' "$newest" 2>/dev/null)
 
 if [ -z "$parsed" ]; then
@@ -134,16 +136,22 @@ fi
   IFS= read -r effort
   IFS= read -r quota_left
   IFS= read -r quota_resets_at
+  IFS= read -r quota_week_left
+  IFS= read -r quota_week_resets_at
 } <<EOF
 $parsed
 EOF
 
 now=$(date +%s)
 
-# Format a seconds delta as "Xh Ym", "Xm", or "Xs".
+# Format a seconds delta as "Xd Yh", "Xh Ym", "Xm", or "Xs". The day unit is here for the seven-day
+# rate-limit window, which is days away for most of its life; the hours are truncated rather than
+# rounded so a delta of 4 days and 23h50m never reads "4d 24h".
 fmt_delta() {
   d=$1
-  if [ "$d" -ge 3600 ]; then
+  if [ "$d" -ge 86400 ]; then
+    echo "$(( d / 86400 ))d $(( (d % 86400) / 3600 ))h"
+  elif [ "$d" -ge 3600 ]; then
     echo "$(( d / 3600 ))h $(( (d % 3600) / 60 ))m"
   elif [ "$d" -ge 60 ]; then
     echo "$(( d / 60 ))m"
@@ -199,22 +207,31 @@ else
 fi
 printf 'context: %s tokens (%s%%%s)\n' "$tokens_label" "${used_pct:-?}" "$window_label"
 
-# Quota line only when the snapshot carried rate-limit data.
-if [ -n "$quota_left" ]; then
-  reset_label=""
-  case "$quota_resets_at" in
+# One rate-limit window as a line, printed only when the snapshot carried that window. Claude Code
+# reports two - the five-hour one, which "quota" has always meant here, and the seven-day one - and an
+# account may have both, one, or neither. The label is padded to the width the other lines use.
+quota_line() {
+  ql_label=$1
+  ql_left=$2
+  ql_resets=$3
+  [ -n "$ql_left" ] || return 0
+  ql_reset_label=""
+  case "$ql_resets" in
     '' | *[!0-9]*) ;;
     *)
-      delta=$(( quota_resets_at - now ))
-      if [ "$delta" -gt 0 ]; then
-        reset_label=", resets in $(fmt_delta "$delta")"
+      ql_delta=$(( ql_resets - now ))
+      if [ "$ql_delta" -gt 0 ]; then
+        ql_reset_label=", resets in $(fmt_delta "$ql_delta")"
       else
-        reset_label=", resets now"
+        ql_reset_label=", resets now"
       fi
       ;;
   esac
-  printf 'quota:   %s%% remaining%s\n' "$quota_left" "$reset_label"
-fi
+  printf '%-8s %s%% remaining%s\n' "$ql_label" "$ql_left" "$ql_reset_label"
+}
+
+quota_line 'quota:' "$quota_left" "$quota_resets_at"
+quota_line 'weekly:' "$quota_week_left" "$quota_week_resets_at"
 
 if [ -n "$model" ]; then
   effort_label=""

package/templates/skills/chamba-statusline/SKILL.md

@@ -16,24 +16,34 @@ That is the answer to most questions this skill gets. The rest of it is the deta
 
 ## Step 1 - The strip, which is where the numbers are
 
-The web interface shows the attached session's status in one line between the terminal and the composer. Four segments, left to right, separated by a mid-dot:
+The web interface shows the attached session's status in one line between the terminal and the composer. Its segments, left to right, separated by a mid-dot:
 
 1. **Model** - the display name Claude Code reports, with any trailing parenthetical (such as "(1M context)") trimmed, and the reasoning effort beside it.
 2. **Context** - tokens held, then the size of the window they sit in, a bar, and the percentage. The size half is dropped when Claude Code does not report a window size. The bar turns yellow as the window fills and red near the top.
-3. **Quota** - what is LEFT of the five-hour rate-limit window, as a bar and a percentage, with the time until it recharges beside it. It is an energy meter: full and green when fresh, yellow at half, red near empty. Absent on free accounts and before the first API response.
+3. **Quota** - one meter per rate-limit window Claude Code reports, tagged `5h` and `7d`: what is LEFT of that window, as a bar and a percentage, with the time until it recharges beside it. It is an energy meter: full and green when fresh, yellow at half, red near empty. A window the account does not have takes its whole meter off the strip, so free accounts and sessions before their first API response show none.
 4. **Claude Code** - the installed CLI version.
 
 The strip belongs to the session it is drawn for, and only a claude session has one - the snapshot is a Claude Code feature, so a codex or opencode tab has no strip at all.
 
 ## Step 2 - The snapshot behind it, and the helper
 
-The script at `{{statusline_path}}` is what makes any of this exist. Claude Code runs it on every prompt render and hands it the session's state on stdin; the script parses it, resolves the pid of the claude process it was run by, and writes a small JSON file. Fields: `session_id`, `claude_pid`, `claude_pid_start`, `updated_at`, `context_tokens`, `context_used_pct`, `context_window_size`, `model`, `effort`, `quota_left_pct`, `quota_resets_at`, `version`.
+The script at `{{statusline_path}}` is what makes any of this exist. Claude Code runs it on every prompt render and hands it the session's state on stdin; the script parses it, resolves the pid of the claude process it was run by, and writes a small JSON file. Fields: `session_id`, `claude_pid`, `claude_pid_start`, `updated_at`, `context_tokens`, `context_used_pct`, `context_window_size`, `model`, `effort`, `quota_left_pct`, `quota_resets_at`, `quota_week_left_pct`, `quota_week_resets_at`, `version`. The two `quota_*` pairs are the five-hour and seven-day rate-limit windows; both percentages are what is LEFT, inverted from the percentage used that Claude Code reports.
 
 Two things read those files:
 - The web interface, which matches a snapshot to a session by that pid and draws the strip from it.
-- The `context-usage` command, which is how an agent inspects its own context and quota from the terminal. Run it rather than reading the files by hand; the `context-usage` skill covers the output.
+- The `context-usage` command, which is how an agent inspects its own context and quota from the terminal. Run it rather than reading the files by hand.
 
-If the user wants the numbers without the browser, `context-usage` is the answer.
+If the user wants the numbers without the browser, `context-usage` is the answer. It prints one labelled line per thing the snapshot carried:
+
+```
+session: 78b4025b-... (this session, updated 3s ago)
+context: 70.8k tokens (7% of 1M window)
+quota:   84% remaining, resets in 21m
+weekly:  59% remaining, resets in 4d 6h
+model:   Fable 5 (effort high)
+```
+
+`quota` is the five-hour window and `weekly` the seven-day one; a window the account does not have prints no line at all, and neither does a field the snapshot is missing. The `(this session, ...)` marker means the snapshot was matched to the asking session by pid and is certainly its own; without it the newest file was used instead, and a `warning:` line says why that may mislead. The numbers are as of the moment the current prompt was submitted, so the turn in flight is not in them yet.
 
 ## Step 3 - When the user wants a status line of their own
 

package/templates/skills/web-pane/SKILL.md

@@ -5,58 +5,4 @@ description: Publish an HTML page into the web pane beside the terminal - and as
 
 # web-pane: publish a page, and ask with it
 
-The web pane is the panel beside the terminal in the chamba web interface. You publish a standalone HTML file into it and it appears at once, as a chip in the bar above the pane; the user clicks the chip to read it.
-
-Publish when the answer is bigger than the terminal carries well, and when the question is.
-
-```bash
-webpane report.html --title "Publish-ports rework"
-```
-
-The file's own `<title>` is what the pane shows. `--title` names the file it is saved as, and defaults to the filename. The helper prints what it saved, or a plain message and a non-zero exit when it could not - the usual reason being a plain terminal session, which has no pane.
-
-## When to reach for it
-
-- **Long or structured output.** A plan, a comparison table, a diagram, a report, an explanation with sections. Anything a user would want to scroll back to, keep, or read twice.
-- **A question with shape.** More options than a plain prompt holds, options that need a sentence each, several questions at once, or a free-text answer alongside a choice. Your own question tooling is right for a quick fork in the road; a page is right when the choice deserves a table.
-- **Anything the user asked to see.** "Show me", "write it up", "as a page" - take those literally.
-
-Do not publish a one-paragraph answer, or a wall of code that belongs in a file. A page nobody needed is a chip in the way.
-
-After publishing, say in one line what you put there. The page is the answer; the terminal line is a pointer to it.
-
-## Writing the page
-
-One file, standalone, dark.
-
-- **Inline everything.** No external stylesheets, scripts or fonts. The page renders in a sandboxed frame with no origin of its own: `localStorage`, cookies and same-origin requests do not work in it, and an external asset only makes the page slower and chattier. Inline `<style>` and `<script>` both work.
-- **Match the interface.** Background `#0d1117`, panels and table headers `#161b22`, borders `#30363d`, text `#e6edf3`, muted text `#8b949e`, and a green accent `#2fe58a` for links, headings you want to lift, and the submit button. System font stack, ~14px, generous line height.
-- **Write it as a document**, not a dashboard: a title, sections, tables where a table is clearer than prose, and short paragraphs. Keep it small - a couple of hundred kilobytes is plenty. The per-page cap is 2 MB, and a page past it is refused rather than trimmed.
-- Images have to be inline too (a data URI, or an SVG written into the page). A path into the container is not something the browser can fetch.
-
-## Asking with a form
-
-Give any form the `data-feedback` attribute and the pane wires it up:
-
-```html
-<form data-feedback>
-  <p>Fail the whole start when a port is taken?</p>
-  <label><input type="radio" name="on_conflict" value="fail" checked /> Fail the start</label>
-  <label><input type="radio" name="on_conflict" value="skip" /> Skip the port and warn</label>
-  <textarea name="text" placeholder="Anything else about the plan..."></textarea>
-  <button type="submit">Send to agent</button>
-</form>
-```
-
-- Every named control becomes a field in the answer. A control named `text` becomes the free-text box.
-- On submit, the interface writes `~/.webpane/<conversation>/feedback/<page>-<epoch-ms>.json` - `{ page, submittedAt, fields, text }` - and types one line into your terminal naming the file. Read the file; the line is only the pointer.
-- The page is told whether the answers were filed, so give the user a form that reads as final ("Send to agent") rather than one that looks like it saved a draft.
-- One submission per page per second, and only so many per page in total (20). Past that the page is refused, and nothing reaches you - so ask once per page, and publish a new page when you need to ask again.
-
-**A feedback file says a form was submitted, not that a person filled it in.** A script in the same page can post exactly what the form would. Treat the answers as data from your own page: fine for a design choice, not enough on its own for something destructive or irreversible - ask for that in the terminal, where you can see the user type.
-
-## After it is published
-
-- Pages are kept. Nothing deletes them, and they are filed under the conversation rather than the session, so resuming the conversation opens with them again. Publishing a second version makes a second page rather than replacing the first, so name pages so a user can tell one from the next ("Plan v2", "Port test results").
-- The user may never open a page. If an answer matters, say the one line that matters in the terminal too.
-- Anything in the session can publish, including a script you wrote - the helper takes only a filename.
+{{web_pane_craft}}

package/templates/webterm/README.md

@@ -34,6 +34,7 @@ The page is mission control for the container: the tab bar at the top is every a
 - **A tab is named after what it runs** - `claude 3`, `codex 4` - so a bar with two agents in it reads without a legend. **Rename** by double-clicking the name, so a long-lived conversation reads by what it is about instead; the name shows in every window and clearing it brings the default back. Names last as long as the session; nothing is saved to disk.
 - **Drag a tab to reorder the bar.** The order is the registry's, not the window's, so it moves in every window at once, and the number in `claude 3` stays with the session rather than with the position. Mouse and trackpad only - this is the browser's own drag and drop, which touch does not fire.
 - **The composer belongs to the session you are in.** A half-written message stays with its conversation: switch tabs and the box holds the next session's draft, switch back and yours is as you left it, image attachments included. Ending a session throws its draft away with it. Drafts are per browser window - they survive a switch, a reload and a sleep, but they do not follow a session into another window, and nothing is saved to disk.
+- **One button asks for a page.** The fourth button in the composer, above Send, sends `Put your last answer in the web pane as a page.` in one click - the one message that would otherwise be typed again every day. It goes through the same paste path as anything typed, so the agent cannot tell the two apart, and it does nothing else: a half-written message stays in the box, the draft is kept, the caret does not move, and the sentence is not added to the Up-arrow history, which is what *you* typed. It is in every session whatever agent it runs, and it is unavailable exactly when Send is - with no connection, or with no session attached.
 - **Shift+Enter is a newline in both boxes.** It always was in the composer; in the terminal above it, Shift+Enter now sends the same ESC-then-Return that Alt+Enter does, which is what the agents read as "a newline, not send". A terminal has no Shift+Enter of its own - Enter is a carriage return whatever else is held - so this is a second key onto a sequence the agent already understands. Alt+Enter still works.
 - **Up recalls what you already sent.** From an empty composer, Up brings back the last message sent to that session and keeps stepping back; Down comes forward, and past the newest is the empty box you started from. Once a message is showing the arrows only step on from its first and last line, so they still move the caret around a long one, and typing anything ends the walk. What is stored is what the agent actually received, image tokens already expanded, so sending a recalled message again means the same thing. History is per session and per browser window, it holds what went through the composer rather than what was typed straight into the terminal, and it goes when the session does.
 - **One window drives a session at a time**, because a PTY has one size and two drivers would fight over it. Opening a session another window is watching offers to switch it to this one; the window that loses it can take it back.
@@ -58,6 +59,7 @@ That is why a session showing as working never also shows as waiting for you.
 
 - **A light travels round a tab** while that session's agent is working.
 - **A tab flashes and then stays lit** when its agent finishes. Every ending, whoever is watching: it costs nothing to say a thing twice on screen, and one rule for every session is easier to trust than one for the tab you have open and another for the rest. Touching the session, or arriving at it, is what puts it out.
+- **A tab takes its session's colour and grows a small page** beside its age when a page is published into that session's pane while you are looking at another one, and flashes once as it arrives. It holds until you get to that session, where the newest page opens itself; anything older that piled up behind it keeps its chip badge, so the tab marks itself again - without a second flash - once you leave. Its own state, not the one above: that one is an agent finishing, and this one is a page waiting to be read.
 - **The browser tab speaks too**, because that is all a window behind something else can do. The title counts the sessions waiting for you, and the favicon carries one mark: a white bar across its bottom edge, with a lit segment sweeping along it, while an agent is working, and a green dot in its top corner - pulsing until you go and look - when one is waiting. Two shapes at opposite ends of the icon rather than two colours in one place, because at 16px a hue is the first thing to go. White for working because every hue here belongs to a workspace or a session, and the frame around the icon is one of them.
 - **And ten seconds later it says so out loud** - one soft chime, once, for an ending nobody came back to. A sound cannot be taken back and it reaches you in the next room, so it is the one thing here that asks whether you were there. Several sessions finishing together are one chime, and so are two windows open on the same container. The bell beside the power button mutes it, and remembers.
 
@@ -111,13 +113,14 @@ Beside the terminal, each session has a pane of pages the agent published - a pl
 - **The files.** `~/.webpane/<conversation-id>/<NN>-<slug>.html`, bind-mounted from the host workspace cache. A page is a plain standalone HTML file, and a file copied into the directory by hand shows up in the pane within a second or two, exactly like a published one.
 - **Per conversation, not per session.** The directory is named after the agent's own conversation id, so resuming a conversation - after a container restart, or by hand with `claude --resume <id>` - opens with its pages again. A session whose agent has not written its id down yet publishes into a `pending-...` directory, which is renamed the moment the id appears. Two live sessions never share a directory: a conversation already open elsewhere is refused, and the second session gets its own empty pane with a notice.
 - **Feedback.** A page may carry `<form data-feedback>`. Submitting it writes `~/.webpane/<conversation-id>/feedback/<page>-<epoch-ms>.json` - `{ page, submittedAt, fields, text }`, where a field named `text` becomes the free-text box - and types one line into the agent's terminal saying where to read it. An agent that has already exited still gets the file; only the line is skipped.
-- **What you see.** The pane is beside the terminal from the start, as the vertical "Web pane" spine in a session that has published nothing - a pane that only appeared once an agent had used it was one nobody knew to ask for. Opening that empty pane says what it is for and gives three things to say to get a page. Once there are pages, the history is the chips bar above them: one chip per page with its title and age, newest at the end. A page that arrives never takes the screen - its chip gets a `new` badge and waits for a click - except in a pane that is still empty, where the first page opens on arrival - which is also what opens a pane nobody has touched yet, since collapsed has three answers (yes, no, and nobody has said) and only a click or a drag makes it one of the first two. Drag the divider to set the width. The button at the end of the chips bar puts the pane away into the vertical "Web pane" spine, which carries the unread count and reopens on a click, and dragging the divider past the collapse threshold does the same. Reopening gives back the width the pane had, but never less than a third of the window - a pane that comes back as a sliver may as well have stayed shut. The width and the collapse belong to the window and survive switching tabs; the pages, the selection and the badges belong to the session and switch with it.
-- **How an agent comes to use it.** Two layers, so it happens without being asked each time. Every agent's injected context carries the standing rule - prefer a page when the answer is longer or more structured than a terminal reply carries well, and when a question has more options or structure than the agent's own question tooling holds - plus the palette to match and the form contract. claude also gets a `web-pane` skill whose description is the phrases a user actually says ("show me", "as a page", "in the pane", "publish"), and whose body is the craft: a standalone dark page, inline everything, how to ask with a form, and what a submitted form does and does not prove. The session greeting names the pane too, so a user who has never heard of it learns it exists in the first sentence.
+- **What you see.** The pane is beside the terminal from the start, as the vertical "Web pane" spine in a session that has published nothing - a pane that only appeared once an agent had used it was one nobody knew to ask for. Opening that empty pane says what it is for and gives three things to say to get a page. Once there are pages, the history is the chips bar above them: one chip per page with its title and age, newest at the end. A page that arrives opens itself and pulses the pane's edge once, and takes nothing else: the caret stays where it was mid-sentence, so you keep typing and click into the page when you want it. "Arrives" is the server's own unread flag rather than "new to this window", so a reload opens nothing that was already read, and a page waiting in a session you have not visited still opens when you get there. A pane you put away comes back for it, at no less than a readable width - the one place this interface overrides a choice you made. A pane nobody has touched yet opens the same way, since collapsed has three answers (yes, no, and nobody has said) and only a click or a drag makes it one of the first two. A page published in a session you are *not* looking at changes nothing where you are: its tab takes that session's colour and a small page beside its age, flashes once, and holds until you get there. Drag the divider to set the width. The minus and plus beside the counter step the shown page through five text sizes, 80% to 150% with 100% the default, and nothing reloads on a press, so a scroll position and a half-filled form both survive it. That control is the browser's own furniture: the size is applied from outside the frame, no page has to account for it, and nothing an agent reads mentions it. The button at the end of the chips bar puts the pane away into the vertical "Web pane" spine, which carries the unread count and reopens on a click, and dragging the divider past the collapse threshold does the same. Reopening gives back the width the pane had, but never less than a third of the window - a pane that comes back as a sliver may as well have stayed shut. The width, the collapse and the text size belong to the window and survive switching tabs; the pages, the selection and the badges belong to the session and switch with it.
+- **How an agent comes to use it.** Two layers, so it happens without being asked each time. Every agent's injected context carries the standing rule - prefer a page when the answer is longer or more structured than a terminal reply carries well, and when a question has more options or structure than the agent's own question tooling holds - plus the palette to match and the form contract. Every agent also gets the craft in full - a standalone dark page, inline everything, how to ask with a form, and what a submitted form does and does not prove - from one file, `templates/context/web-pane-craft.md`: claude reads it as the body of a `web-pane` skill, whose description is the phrases a user actually says ("show me", "as a page", "in the pane", "publish"), and codex and opencode read it as a section of the `AGENTS.md` chamba writes them, since a skill is a Claude Code mechanism and neither has one. The frontmatter and the title are claude's alone; the advice is written once. The session greeting names the pane too, so a user who has never heard of it learns it exists in the first sentence.
 - **Nothing is deleted.** No age sweep, nothing removed when a session closes. Growth is bounded instead: a page over the per-page cap is refused, and once the whole directory reaches its total - in bytes or in number of files - new publishes are refused and what is there stays. Advanced > Clear agent memory in chamba is what clears it.
 
 ## The status strip
 
-Between the terminal and the composer, a claude session shows its own numbers, live: the model and its effort, the context it is holding against the window it fits in, what is left of the five-hour quota with the time until it recharges, and the installed Claude Code version.
+Between the terminal and the composer, a claude session shows its own numbers, live: the model and its effort, the context it is holding against the window it fits in, what is left of each rate-limit window - the five-hour one and the seven-day one, tagged `5h` and `7d` - with the time until each recharges, and the installed Claude Code version.
+A window the account does not have takes its whole meter off the strip rather than showing an empty one.
 
 - **Where the numbers come from.** The status line script chamba installs (`claude-statusline.sh`, baked into the image) prints nothing at all - in a browser a status line would scroll away with the output and cost a terminal row every prompt. What it does instead is write `~/.claude/context-usage/<session-id>.json` on every prompt render, and the strip is drawn from that file. The same file is what the `context-usage` helper reads, so an agent asking about its own context and the strip above it always agree.
 - **Whose numbers they are.** A snapshot records the pid of the claude process that wrote it, and the server matches it to a session by walking up the process tree from that pid to the session's PTY leader - not by assuming the two are equal, since a wrapper or a shell may sit between them. The start time recorded beside the pid is the tiebreak: the snapshot directory is a chamba mount, so it holds files written by containers that are gone, and their pids can be live again as something else.

package/templates/webterm/artifacts.js

@@ -332,6 +332,19 @@ export function createPaneStore({ root, maxPageBytes, maxTotalBytes, maxTotalFil
         return changed;
     }
 
+    /**
+     * How many of a key's pages nobody has opened. Answered from the last scan rather than from the directory:
+     * this rides on the session bar, which is broadcast to every window far more often than a pane changes,
+     * and reading the head of every page file to answer it would be paying a listing's price for a number.
+     */
+    function unreadCount(key) {
+        let count = 0;
+        for (const entry of scanned.get(key)?.values() ?? []) {
+            if (entry.unread) count += 1;
+        }
+        return count;
+    }
+
     /** The window opened this page, so it is no longer new. True when that actually changed something. */
     function markRead(key, id) {
         const entry = scanned.get(key)?.get(id);
@@ -559,7 +572,7 @@ export function createPaneStore({ root, maxPageBytes, maxTotalBytes, maxTotalFil
         }
     }
 
-    return { adopt, ensureDir, keyDir, list, markRead, publish, read, refresh, totalBytes, writeFeedback };
+    return { adopt, ensureDir, keyDir, list, markRead, publish, read, refresh, totalBytes, unreadCount, writeFeedback };
 }
 
 /**

package/templates/webterm/conversation.js

@@ -35,11 +35,15 @@ const MAX_JSON_BYTES = 1024 * 1024;
 const MAX_STORE_DEPTH = 5;
 
 /**
- * Files under `dir` matching `pattern`, newest first, capped. Depth-limited; unreadable dirs contribute nothing.
- * Exported for resume.js, which reads the same stores to answer a different question.
+ * Every matching file under `dir`, in no particular order, each handed to `onFile`. Returning true from
+ * `onFile` stops the walk, which is what lets a caller that only needs to know whether there is one at all
+ * stop at the first instead of listing a whole store.
+ *
+ * Depth-limited, and unreadable dirs contribute nothing. Symlinks are skipped rather than followed: these
+ * stores are the agents' own, and a link in one of them would only ever lead somewhere this has no business
+ * reading - readdir reports one as neither a file nor a directory, which is what leaves it out.
  */
-export function filesNewestFirst(dir, pattern, depth = MAX_STORE_DEPTH) {
-    const found = [];
+function walkStore(dir, pattern, depth, onFile) {
     const queue = [{ dir, depth }];
     while (queue.length > 0) {
         const current = queue.shift();
@@ -51,25 +55,52 @@ export function filesNewestFirst(dir, pattern, depth = MAX_STORE_DEPTH) {
         }
         for (const entry of entries) {
             const full = join(current.dir, entry.name);
-            // Symlinks are skipped rather than followed: these stores are the agents' own, and a link in one
-            // of them would only ever lead somewhere this lookup has no business reading.
             if (entry.isDirectory() && current.depth > 0) {
                 queue.push({ dir: full, depth: current.depth - 1 });
-            } else if (entry.isFile() && pattern.test(entry.name)) {
-                try {
-                    found.push({ path: full, mtime: statSync(full).mtimeMs });
-                } catch {
-                    // Vanished between the listing and the stat.
-                }
+            } else if (entry.isFile() && pattern.test(entry.name) && onFile(full)) {
+                return;
             }
         }
     }
+}
+
+/**
+ * Files under `dir` matching `pattern`, newest first, capped.
+ * Exported for resume.js, which reads the same stores to answer a different question.
+ */
+export function filesNewestFirst(dir, pattern, depth = MAX_STORE_DEPTH) {
+    const found = [];
+    walkStore(dir, pattern, depth, (path) => {
+        try {
+            found.push({ path, mtime: statSync(path).mtimeMs });
+        } catch {
+            // Vanished between the listing and the stat.
+        }
+        return false;
+    });
     return found
         .sort((a, b) => b.mtime - a.mtime)
         .slice(0, MAX_CANDIDATES)
         .map((entry) => entry.path);
 }
 
+/**
+ * Whether the store holds anything matching at all, stopping at the first one it finds.
+ *
+ * The cheap half of the question above, and the only half resume.js asks of codex and opencode: they are
+ * reopened by their own flag rather than by id, so all that is wanted is whether there is a conversation
+ * there. Answering that by listing and stat-ing everything first is what would make a heavy opencode store -
+ * one file per message part - a pause on the way to a new session.
+ */
+export function hasAnyFile(dir, pattern, depth = MAX_STORE_DEPTH) {
+    let found = false;
+    walkStore(dir, pattern, depth, () => {
+        found = true;
+        return true;
+    });
+    return found;
+}
+
 /**
  * The head of a file as text, or "" when it cannot be read.
  *
@@ -196,6 +227,12 @@ export function claudeConversationId(session, stores) {
 // rollout-<timestamp>-<uuid>.jsonl - the uuid is the conversation id codex resumes by.
 export const CODEX_ROLLOUT = /^rollout-.*-([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\.jsonl$/;
 
+// The same rollout once codex has compressed it. Rollouts are compressed when they go cold, so a store whose
+// history has all gone cold holds nothing matching the pattern above - which is why resume.js asks with this
+// one instead. It is deliberately not what a live session is matched against below: compressing a rollout
+// rewrites it, and the fresh mtime that leaves behind looks exactly like a session writing to it.
+export const CODEX_ANY_ROLLOUT = /^rollout-.*-([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\.jsonl(\.zst)?$/;
+
 /** Codex's conversation id for a session: the newest rollout file that could be this session's. */
 export function codexConversationId(session, stores) {
     for (const path of filesNewestFirst(stores.codexSessions, CODEX_ROLLOUT)) {
@@ -208,13 +245,20 @@ export function codexConversationId(session, stores) {
 
 // --- OpenCode ----------------------------------------------------------------------------------------------------------------------------
 
+// How far under opencode's store a session record sits. It nests everything under
+// storage/session/{info,message,part}/, and only info/ holds one file per session - message/ and part/ hold
+// one per message and one per message part, deeper down and far newer. So the bound is not a cost saving
+// here but the whole of the answer: without it the newest .json in the store is a message part, and the pane
+// would file a conversation's pages under an id that changes with every message.
+const OPENCODE_SESSION_DEPTH = 1;
+
 /**
  * OpenCode's conversation id for a session: the newest session record in its local store that could be this
  * session's. The id comes from the record when it carries one and from the filename otherwise, which is the
  * same value - opencode names the file after the session.
  */
 export function opencodeConversationId(session, stores) {
-    for (const path of filesNewestFirst(stores.opencodeSessions, /\.json$/)) {
+    for (const path of filesNewestFirst(stores.opencodeSessions, /\.json$/, OPENCODE_SESSION_DEPTH)) {
         if (mtimeOf(path) < session.since) continue;
         const record = readJson(path);
         const recorded = firstPathField(record);

package/templates/webterm/pane.js

@@ -127,6 +127,14 @@ export function createPane({ store, stores, sessions, onChange }) {
         return { pages: store.list(keyFor(sid)), notice: noticeFor(sid) };
     }
 
+    /**
+     * How many pages of this session's pane nobody has opened. This is what a window hears about a session it
+     * is not driving: the pages themselves only ever reach the window that session belongs to.
+     */
+    function unreadCount(sid) {
+        return store.unreadCount(keyFor(sid));
+    }
+
     /** Publish into this session's pane. The page is new, so whoever is watching hears about it at once. */
     function publish(sid, page) {
         const result = store.publish(keyFor(sid), page);
@@ -152,5 +160,5 @@ export function createPane({ store, stores, sessions, onChange }) {
         return bySession.has(sid);
     }
 
-    return { discover, feedback, keyFor, knows, noticeFor, pages, publish, read, sweep };
+    return { discover, feedback, keyFor, knows, noticeFor, pages, publish, read, sweep, unreadCount };
 }