agentbox-app 0.1.13 → 0.1.16

package/README.md

@@ -6,11 +6,12 @@
 
 <p align="center">
   <strong>Give your agents an inbox.</strong><br>
-  Run dozens of coding agents at once and only hear from the ones that need you.
+  Run dozens of Claude Code and Codex agents in parallel, each in its own git worktree,<br>
+  and only hear from the ones that need you.
 </p>
 
 <p align="center">
-  <a href="#get-it">Get it</a> ·
+  <a href="#install">Get it</a> ·
   <a href="#how-it-works">How it works</a> ·
   <a href="#what-matters-most-goes-first">Priorities</a> ·
   <a href="#built-for-the-keyboard">Keys</a> ·
@@ -23,8 +24,8 @@
 </p>
 
 <p align="center">
-  Free and open source. Runs in your browser or as a Mac app, on the Claude Code or Codex plan you already have.<br>
-  No server, no account, no extra subscription.
+  Free and open source. A Mac app, or in your browser on any platform with <code>npx agentbox-app</code>,<br>
+  on the Claude Code or Codex plan you already have. No server, no account, no extra subscription.
 </p>
 
 ---
@@ -41,7 +42,7 @@ npx agentbox-app
 
 It starts on your machine and opens a tab. On Linux that open goes through `xdg-open`. Nothing is hosted: it listens only on `127.0.0.1`, and the address carries a key that is new every run. Add `--help` to see the options. `--no-open` prints the address and leaves the browser to you.
 
-From a checkout, build the screen once, then start it the same way:
+From a checkout, build the screen once, then start it the same way. The install links the checkout's own command, so `npx` runs this copy rather than looking for `agentbox` on your PATH:
 
 ```
 npm install
@@ -58,7 +59,9 @@ npm install
 npm start
 ```
 
-On Linux, `npm install` puts `agentbox` on `~/.local/bin` and adds the app to the launcher. The entry is `$XDG_DATA_HOME/applications/agentbox.desktop` (`~/.local/share/applications` when that variable is unset), and it runs `agentbox`. That command starts this checkout. Open the app from the launcher.
+On Linux, `npm install` puts `agentbox` on `~/.local/bin` and adds the app to the launcher. The entry is `$XDG_DATA_HOME/applications/agentbox.desktop` (`~/.local/share/applications` when that variable is unset), and it runs `agentbox`. That command starts this checkout, and it is written before Electron has downloaded its binary, so the first launch off the launcher does that download. Open the app from the launcher.
+
+Two of this repo's dependencies need an install script to work: `node-pty`, which is the terminal, and `esbuild`. `package.json` names them in `allowScripts`, by name rather than pinned to a version, so a dependency bump does not need re-approving. `electron-winstaller` is denied there: it is only for packing a Windows installer, which this repo does not do. npm 11 and newer print anything in neither list on every install, and `npm approve-scripts --allow-scripts-pending` lists them.
 
 `npm start` builds the app and opens it. On first run it walks you through connecting Claude Code or Codex and choosing a folder to work in.
 
@@ -84,7 +87,8 @@ than you could ever watch and only deal with one when it actually needs you.
 ### 1. File the work
 
 Paste a list, send over a board of issues, or type one task. Each item becomes
-its own row, and each row is its own agent, already working.
+its own row, and each row is its own agent, already working in its own git
+worktree and on its own branch, so no two agents touch the same files.
 
 <img src="docs/readme/file.webp" alt="Twelve issues from a project board go over in one message and appear as twelve agents working" width="100%">
 
@@ -231,7 +235,7 @@ Nothing, unless you are running a build that was signed and released with a
 PostHog key baked into it. A build made from this repo has no key, so a clone
 and a fork are silent, and with no key the whole path is off at every send.
 
-A released build counts twelve things, and they are counts:
+A released build counts eighteen things, and they are counts:
 
 - the app was opened
 - the app was used today, once a day
@@ -245,6 +249,12 @@ A released build counts twelve things, and they are counts:
 - a task finished
 - an agent started work
 - an agent stopped work
+- the app was quit
+- the corner tag was hidden
+- the corner tag was turned off
+- setup offered agents to import
+- setup imported agents
+- counts were turned off
 
 Each carries a random install id, the app and platform version, and at most
 seven other things: how long something took, how many of a thing there were,
@@ -262,6 +272,11 @@ accident. Crash reports travel the same way and are scrubbed first
 - In the app: Settings, then the "Counts and crash reports" switch.
 - In `zero.config.json`: `"diagnostics": false`.
 
+Either way nothing is sent from that moment, with one exception: turning the
+switch off in the app sends one last count saying counts were turned off, so
+you are not read as someone who stopped using Agentbox. Editing the file sends
+nothing at all.
+
 The update check is separate and is not routed through any of this. It is a
 request to github.com for the latest release, it carries no identity and no
 key, and it only happens in a packaged build.
@@ -320,7 +335,7 @@ or `?engines=codex` give two.
 
 To open the app as somebody who has never seen it, with its own throwaway home
 and nothing of yours inside it, press `⌘K` or `Ctrl+K` and choose "Open Agentbox as a new
-user". `npm run fresh` does the same from a terminal. `ZERO_NO_SUPERVISOR=1` applies to `npm start` and to `npx agentbox-app`.
+user". `npm run fresh` does the same from a terminal: a packaged app when there is one, this checkout through Electron when there is not, which is the way in on Linux. `ZERO_NO_SUPERVISOR=1` applies to `npm start` and to `npx agentbox-app`.
 
 The app is named in exactly one place, `shared/product-name.mjs`. Change it
 there and run `node scripts/product-name.mjs --write`, and everything else

package/bin/agentbox.mjs

@@ -15,8 +15,11 @@ import fs from 'node:fs';
 import { spawn } from 'node:child_process';
 import { fileURLToPath } from 'node:url';
 
-import { bootHeadless, createServer, newToken } from '../main/serve.mjs';
+import { bootHeadless, createServer, newToken, picturesTheAppOwns } from '../main/serve.mjs';
 import { appHome } from '../main/store/home.mjs';
+import { learnShellDataDirs } from '../main/shell-path.mjs';
+import { startFreezeRecorder } from '../main/freeze-recorder.mjs';
+import { watchNewChatsFor } from '../main/new-chats-watch.mjs';
 
 const here = path.dirname(fileURLToPath(import.meta.url));
 const appDir = path.dirname(here);
@@ -59,10 +62,22 @@ if (!fs.existsSync(path.join(dist, 'index.html'))) {
   process.exit(1);
 }
 
+// The login folders the shell profile names, read before the first worker can
+// start, as main/main.mjs does. The worker scrub keeps CLAUDE_CONFIG_DIR and
+// CODEX_HOME from reaching a worker by inheritance, so without this a copy's
+// workers signed in to ~/.claude and ~/.codex (w-6d8c543a43).
+await learnShellDataDirs();
 const booted = await bootHeadless({ dataDir, appDir, userDir: dataDir });
+// What held the thread each time it froze, as the desktop records it.
+startFreezeRecorder({
+  dir: path.join(dataDir, 'memory-log'),
+  appDir,
+  onFreeze: (f) => console.warn(`zero: the app froze for ${f.ms} ms in ${f.where}`),
+});
 // ZERO_NO_SUPERVISOR: the desktop already honors this (main/main.mjs). This
 // entry is the same inbox, so a launch that asks for no agents must not start
 // them here either.
+let newChatsWatch = null;
 if (!process.env.ZERO_NO_SUPERVISOR) {
   // Whoever was signed in to the team last time is signed in again.
   booted.team?.start().then(() => booted.supervisor.wake?.()).catch((err) => console.warn(`team: ${err.message}`));
@@ -70,6 +85,8 @@ if (!process.env.ZERO_NO_SUPERVISOR) {
   // tab only moved work when something woke the supervisor: a queued thread sat
   // queued and a scheduled one never fired (found 2026-10-01 on a test copy).
   booted.supervisor.start();
+  // The chats setup's "Keep bringing in new chats" tick asks for.
+  newChatsWatch = watchNewChatsFor({ store: booted.store, config: booted.config, supervisor: booted.supervisor });
 }
 const token = newToken();
 const server = createServer({
@@ -77,6 +94,10 @@ const server = createServer({
   token,
   listeners: booted.window.listeners,
   dist,
+  // The pictures in a thread: a tab cannot open `agentbox-img://`, which only
+  // the desktop window answers, so without this door every local picture is
+  // drawn as missing.
+  files: picturesTheAppOwns(booted),
 });
 
 const wanted = Number(flag('port', 0)) || 0;
@@ -99,6 +120,7 @@ server.on('error', (err) => {
 for (const signal of ['SIGINT', 'SIGTERM']) {
   process.on(signal, () => {
     console.log('\n  Stopping.');
+    newChatsWatch?.stop();
     booted.host.app.quit();
     server.close(() => process.exit(0));
     setTimeout(() => process.exit(0), 3000).unref();

package/briefs/message-rules.md

@@ -1,3 +1,23 @@
+<!-- autonomy-rules:start -->
+These rules format a final answer; they do not tell you when to stop working.
+Explicit autonomy applies to the agreed objective, not to unrelated work.
+When the person delegates a plan and asks you to keep going, carry out its
+authorized steps without asking for another go-ahead. A completed step is a checkpoint, not a reason to end the run.
+Give progress updates while continuing. Earlier autonomy remains in force until they change it;
+a status question during that work gets a brief update, then work continues.
+Do not ask them to approve a step they already authorized.
+
+If one step is blocked, continue other independent authorized work first.
+Stop when the objective is complete, they ask you to stop,
+you need a decision or resource only they can supply, or repeated attempts produce no progress.
+Follow narrower instructions immediately.
+Autonomy does not bypass permission checks or specific approval requirements.
+An approval covers only the thing it approved.
+Without explicit delegation, finish the requested task and return; a question
+does not authorize a project, and "continue" alone does not authorize unrelated work.
+Authorized work continues until a real stopping point, even if older defaults ask for proposals or options.
+<!-- autonomy-rules:end -->
+
 This is about the LAST message you send, the one that ends your run. Whoever
 asked for it reads it in a list beside twenty others and usually decides what to
 do next without opening anything. Ten seconds is the real budget.
@@ -73,7 +93,10 @@ WHAT THE APP CAN SHOW, so you can lay out what you made the way it reads best:
 - A sound or a film plays where it is named; a localhost address opens beside
   the message. Headings, lists, tables and bold all draw.
 The arrangement is yours. The 200 words are for your report, not for the words
-that help them read what you show.
+that help them read what you show. A suggestion when they choose between
+designs: show each one stacked one under the next, in the order of your options,
+with its option's number and a line over or under it saying what differs, so
+each is big enough to judge without opening it.
 
 Steps they must take are a numbered list, five at most, the first one doable now.
 
@@ -91,19 +114,24 @@ ended up with, and read them back together: if someone said option one
 out loud, it has to answer line one. When it does not, they have two questions
 stacked on each other and must open the message to see which is which.
 
+OFFER CHOICES WHENEVER THEIR NEXT REPLY IS CLEAR. A number pressed is quicker
+than a reply typed, and options are drawn as numbered choices. So when you end
+with steps for them to take, offer the reply they would send once the steps are
+done, such as "Done, check it again", and when a decision has two or three
+sensible answers, offer them. Leave options out only when there is truly
+nothing to pick.
+
 Offer one to four options; two or three is usual, and one is fine. Mark exactly
 one recommended. Every option has to be something you would start on without asking
 another question first. Name each choice in your prose too, because the list is
 often drawn elsewhere on the screen and a sentence pointing at "option two"
 then points at nothing.
 
-IF YOUR RUN CHANGED ANYTHING, THERE IS SOMETHING TO DECIDE. Edited files, a
-branch, a draft, a page you built: none of it is finished until the person
-reading you says what happens to it. So the options are what to do with the
-thing, in their words: ship it, change this part first, throw it away. Do not
-call the run settled to save yourself the asking, or make them type "merge it"
-because you did not offer it. The only run that ends with no options
-is one that changed nothing.
+IF YOUR RUN LEAVES AN UNAPPROVED CHANGE, THERE IS SOMETHING TO DECIDE. Edited
+files, a branch, a draft, a page you built: offer what still needs their decision,
+in their words: ship it, change this part first, throw it away. Already authorized actions do not create another decision.
+Do not manufacture a pick to continue an agreed plan. When an approval is
+still required, offer it explicitly so they can choose it.
 
 NEVER OFFER WHAT YOUR RUN ALREADY DID. Shipped, merged or sent: line one says
 so, and no option offers it again. When only closing is left, offer the one

package/briefs/worker.md

@@ -46,7 +46,9 @@ sentences, 45 words at most, that bring the thread back to someone who has
 forgotten it, what was asked, what was found and the facts needed to decide.
 `progress` is shown as DONE: the steps taken so far, one per line, oldest first
 and newest last, six lines at most of 15 words each; send the whole list each
-time. A longer one is refused. Leave `solution` out; it is no longer shown. If
+time. A longer one is refused. EVERY LINE IS A STEP THAT FINISHED: one you are
+about to take goes on after it happens, never before, because a DONE list
+claiming a commit that never ran is how the work gets thrown away. Leave `solution` out; it is no longer shown. If
 it waits on another thread, pass that thread's id in `blockedBy`. The person may have edited the summary; read it
 before you rewrite it, and keep what they said unless it is no longer true.
 <!-- store-tools:end -->
@@ -91,6 +93,8 @@ are a good general assistant first and this brief is scaffolding around that.
 If following a rule here would make your answer worse than a plain Claude Code
 session's, you are misapplying it. Answer well, then apply what actually fits.
 
+Finish the authorized objective, not merely the current step.
+
 ## Doing the work
 
 <!-- store-tools:start -->
@@ -101,14 +105,13 @@ session's, you are misapplying it. Answer well, then apply what actually fits.
   the only one that changes it.
 - Actions outside your standing grants do not silently fail any more: the
   permission system asks the founder LIVE (an approval card in their inbox app)
-  and blocks you until they answer, up to 15 minutes. Spend these asks like
-  interruptions, because they are: exhaust what your grants already allow,
-  batch the gated part into as few commands as possible, and if they deny
-  or the ask times out, do not retry it; finish what you can and file the
+  and blocks you until they answer, with no deadline on it: you may wait hours.
+  Spend these asks like interruptions, because they are: exhaust what your
+  grants already allow, batch the gated part into as few commands as possible,
+  and if they deny, do not retry it; finish what you can and file the
   remainder as a review with the exact commands.
-- EVERYTHING YOU FILE IS A PROPOSAL: nothing you create runs until the founder
-  approves it from the inbox, so write it for them to decide rather than as a
-  note to another agent.
+- EVERYTHING YOU FILE IS A PROPOSAL: nothing you file runs until they approve
+  it from the inbox; do already authorized work in this run instead of filing it.
 - Code changes happen in the product's repo (your cwd), on a branch, committed
   as you go. Name the branch the way this repo already names branches; read a
   few with `git branch` and follow them. Never commit to main; the founder
@@ -157,14 +160,14 @@ session's, you are misapplying it. Answer well, then apply what actually fits.
   you alone before it started you, and it takes it back when you exit.
 - Actions outside your standing grants do not silently fail any more: the
   permission system asks the founder LIVE (an approval card in their inbox app)
-  and blocks you until they answer, up to 15 minutes. Spend these asks like
-  interruptions, because they are: exhaust what your grants already allow,
-  batch the gated part into as few commands as possible, and if they deny
-  or the ask times out, do not retry it; finish what you can and say what is
+  and blocks you until they answer, with no deadline on it: you may wait hours.
+  Spend these asks like interruptions, because they are: exhaust what your
+  grants already allow, batch the gated part into as few commands as possible,
+  and if they deny, do not retry it; finish what you can and say what is
   left in your last message, with the exact commands.
-- You cannot file work, so nothing you find becomes a task by itself. Anything
-  worth doing next goes in your last message, in one sentence, as something they
-  can say yes to. Their attention is the gate here on purpose.
+- You cannot file work, so nothing you find becomes a task by itself. Work
+  outside their authorization goes in your last message as something they can
+  say yes to. Continue work they already authorized.
 - Code changes happen in the product's repo (your cwd), on a branch, committed
   as you go. Name the branch the way this repo already names branches; read a
   few with `git branch` and follow them. Never commit to main; the founder
@@ -191,15 +194,15 @@ session's, you are misapplying it. Answer well, then apply what actually fits.
 <!-- no-store-tools:end -->
 
 <!-- subagent-rule:start -->
-## One row, or several
-
-Split work into separate work items when each piece needs its own answer from
-the founder or its own session. Keep helpers inside one item when their work
-combines into a single result.
+## One job is one thread
 
-Twenty issues off one call are twenty rows. A research task fanned across ten
-subagents that merge into one document is one row, however many subagents it
-takes. Spawning a subagent is not by itself a reason to file anything.
+DEFAULT TO ONE THREAD; one PR is one thread. A second costs them one more thing
+to read, rank and start or close. Ask how many ANSWERS you need, not how many
+THINGS you found: twenty issues off one call are ONE thread when the answer is
+"yes, fix them". Never hand work to another thread that you could do here, and
+run parallel work as subagents in this one: subagents are not threads. File a
+second only for a separate job, UNDER this one (`parent`), which keeps it out of
+their inbox.
 <!-- subagent-rule:end -->
 
 ## Honesty
@@ -242,3 +245,23 @@ whatever it says. On a run with nothing in it, say that in one line and stop.
 One line costs them a second to read and tells them the job is still alive.
 <!-- no-store-tools:end -->
 <!-- repeat-rules:end -->
+<!-- teammate-rules:start -->
+
+## If this item is one run of a teammate
+
+Its labels carry `teammate:<id>`, and the system prompt tells you which
+teammate you are. This run is your own work, not something the person asked
+for, so the rules above about leaving their rows open do not apply to it. The
+team chat is where you talk; their inbox is only for what needs them.
+
+Finish one of two ways.
+
+Nothing needs them: post a one-line summary with team_post, then update this
+item with `status: "done"` and its labels plus `"clean"`, all in one call
+(labels replace the array, so send every one). This is the ordinary finish. A
+report they did not ask a question about belongs in the chat, not their inbox.
+
+They need to decide, approve or sign in: end with that question as your last
+message, short: a bold first line, two or three sentences, numbered options
+with your recommendation first. Leave the item open. It reaches their inbox.
+<!-- teammate-rules:end -->

package/main/account-discovery.mjs

@@ -1,31 +1,33 @@
-// THE ACCOUNTS AGENTBOX RUNS ON ARE THE ONES ON THE DISK, not the ones somebody
-// remembered to type into a config file.
+// THE ACCOUNTS AGENTBOX KNOWS ABOUT ARE THE ONES ON THE DISK, not the ones
+// somebody remembered to type into a config file.
 //
-// Picture someone with two subscriptions: a second account signed in through
-// its own CLAUDE_CONFIG_DIR, and a first one that has hit its WEEKLY limit.
-// The fleet stops for days, with a rested account on the same disk the whole
-// time. The register of accounts was the
-// hand-written `authProfiles` key in zero.config.json, which nothing in the app
-// writes and nothing in the app checks against reality, so an account set up
-// the ordinary way (a new CLAUDE_CONFIG_DIR, a /login) was invisible BY
-// CONSTRUCTION. There was no symptom: the page drew two healthy rows and every
-// word on them was true.
+// The register of accounts was the hand-written `authProfiles` key in
+// zero.config.json, which nothing in the app writes and nothing in the app
+// checks against reality, so an account set up the ordinary way (a new
+// CLAUDE_CONFIG_DIR, a /login) was invisible BY CONSTRUCTION: it could not be
+// seen on the Accounts page and could not be picked.
 // tests/an-account-she-signed-into-is-not-invisible.test.mjs has the folders,
 // the ids and the CLI's own sentence.
 //
+// KNOWING ABOUT AN ACCOUNT IS NOT SENDING WORK TO IT (w-dac993a554). This list
+// is what the Accounts page draws and what somebody picks from; the work goes
+// to one account, `Supervisor#_theOneAccount`. A second subscription found here
+// sits idle until it is picked or a project is tied to it.
+//
 // THE RULE, and it is four lines because each one was a way to get this wrong:
 //
 //   - A folder under the home directory named `.claude` or `.claude-<anything>`
 //     that holds a login is an account.
 //   - IT ONLY COUNTS IF ITS SUBSCRIPTION IS NEW. Two folders holding one
 //     account is a real setup (~/.claude and ~/.claude-second both signed in
-//     as the same person), and counting it twice sends two thirds of every
-//     spawn round to an account that is already at its limit. The test is on
-//     `accountUuid`, the id Claude Code stores for the subscription itself,
-//     never on the email, because one email can hold more than one subscription.
-//   - NOTHING THE USER CONFIGURED IS EVER DROPPED OR REORDERED. The config is a
-//     decision; this is only a discovery. Discovered accounts go after the
-//     configured ones.
+//     as the same person), and counting it twice draws one subscription as two
+//     rows to choose between. The test is on `accountUuid`, the id Claude Code
+//     stores for the subscription itself, never on the email, because one
+//     email can hold more than one subscription.
+//   - NOTHING THE USER CONFIGURED IS REORDERED, and nothing is dropped except
+//     a home-directory folder that fails the two rules above and below: one
+//     with no login, or a second one holding a subscription already listed.
+//     Discovered accounts go after the configured ones.
 //   - A folder with no login is not an account. Folders such as
 //     ~/.claude-swap-backup or ~/.claude-worktrees are exactly that, and
 //     neither is a place to send work.
@@ -47,6 +49,7 @@ import fs from 'node:fs';
 import os from 'node:os';
 import path from 'node:path';
 import { accountIdentity, defaultClaudeHome } from './account-tooling.mjs';
+import { shellDataDirsNow } from './shell-path.mjs';
 
 // The listing, held against the home folder's mtime. Creating or deleting a
 // folder there moves it; signing IN does not, which is why only the listing is
@@ -98,35 +101,87 @@ export function discoverProfiles({ home = os.homedir() } = {}) {
     out.push({ dir, email: id.email, accountUuid: id.accountUuid });
   }
   // The default login leads, because it is the one every other account is a
-  // second of, and the rest keep the disk's alphabetical order so the fleet's
-  // round-robin does not reshuffle itself between ticks.
+  // second of and the one work runs on until somebody picks another
+  // (`_theOneAccount` takes the first of this list). The rest keep the disk's
+  // alphabetical order, so the order does not change between ticks.
   return out.sort((a, b) => (a.dir === dflt ? -1 : b.dir === dflt ? 1 : 0));
 }
 
+/** A `.claude-<anything>` folder directly in the home directory: the shape
+ *  discovery looks for and Add account makes. */
+function isHomeFolder(dir, home) {
+  const full = path.resolve(dir);
+  return path.dirname(full) === path.resolve(home) && path.basename(full).startsWith('.claude-');
+}
+
 /**
- * THE PROFILES THE FLEET ACTUALLY RUNS ON: the configured ones first, exactly
- *  as written, then any subscription found on the disk that none of the
- *  configured ones is already running on.
+ * THE PROFILES THE FLEET ACTUALLY RUNS ON: the configured ones first, in her
+ *  order, then any subscription found on the disk that none of the configured
+ *  ones is already running on.
  *
  *  Profiles are the strings the rest of the app has always used: the literal
  *  'default' for ~/.claude (which is what spawning with no CLAUDE_CONFIG_DIR
  *  means), and an absolute folder path for anything else. It always answers
  *  with at least ['default'], because somewhere has to be spawnable. */
-export function effectiveProfiles(configured, { home = os.homedir() } = {}) {
+export function effectiveProfiles(configured, { home = os.homedir(), shellDir = shellDataDirsNow().CLAUDE_CONFIG_DIR } = {}) {
   const mine = (Array.isArray(configured) ? configured : []).map((p) => p || 'default');
-  const list = mine.length ? [...mine] : ['default'];
   const dflt = defaultClaudeHome(home);
   const dirOf = (p) => (p === 'default' ? dflt : p);
+  const isDefault = (p) => p === 'default' || dirOf(p) === dflt;
+  const idOf = (p) => accountIdentity(isDefault(p) ? null : dirOf(p), { home });
 
-  // Which subscriptions her own list already covers. A configured folder with
-  // no readable login covers nothing, which is right: it cannot run anything,
-  // so it cannot be the reason a working account is left out.
+  // Which subscriptions her own list already covers, the default login's first
+  // so that it is the one kept when a second folder holds the same account.
   const have = new Set();
-  for (const p of list) {
-    const id = accountIdentity(p === 'default' ? null : dirOf(p), { home });
+  for (const p of mine) {
+    const id = isDefault(p) ? idOf(p) : null;
     if (id?.accountUuid) have.add(id.accountUuid);
   }
+
+  // A `.claude-<n>` FOLDER IN THE HOME DIRECTORY IS AN ACCOUNT ONLY WHEN IT IS
+  // SIGNED IN, AND ONLY ONCE PER SUBSCRIPTION, whether discovery found it or
+  // the config names it. Add account used to write its folder into the config
+  // before the sign-in, so an abandoned one sat in Settings as "Not signed in"
+  // and was handed every other task; and one account signed into two folders
+  // was listed twice (tests/an-account-shows-once-and-only-once-it-is-signed-in).
+  // The default login is never judged, and a folder anywhere else is a
+  // hand-written setting and stays exactly as written.
+  const list = [];
+  for (const p of mine) {
+    if (isDefault(p)) { list.push(p); continue; }
+    const id = idOf(p);
+    if (isHomeFolder(dirOf(p), home)) {
+      if (!id?.accountUuid || have.has(id.accountUuid)) continue;
+    }
+    if (id?.accountUuid) have.add(id.accountUuid);
+    list.push(p);
+  }
+  if (!list.length) list.push('default');
+
+  // THE LOGIN THE PERSON'S SHELL PROFILE POINTS AT (w-6d8c543a43). Their
+  // terminal's `claude` reads the folder `CLAUDE_CONFIG_DIR` names in .zshrc,
+  // which an app opened from the Dock never sees. When the default holds no
+  // login, or the same account, the shell's folder takes its place; a
+  // different account at ~/.claude keeps running beside it. It is always a
+  // folder, never 'default', even when it IS ~/.claude: Claude Code names its
+  // keychain entry after the variable, so naming the folder out loud is a
+  // different sign-in from naming nothing.
+  const shell = typeof shellDir === 'string' && path.isAbsolute(shellDir) ? shellDir : null;
+  const shellId = shell ? accountIdentity(shell, { home }) : null;
+  if (shellId?.accountUuid && !list.includes(shell)) {
+    const dfltId = idOf('default');
+    const takesDefault = !dfltId?.accountUuid || dfltId.accountUuid === shellId.accountUuid;
+    if (takesDefault && list.some(isDefault)) {
+      list.splice(list.findIndex(isDefault), 1, shell);
+      for (let i = list.length - 1; i >= 0; i--) if (list[i] !== shell && isDefault(list[i])) list.splice(i, 1);
+      have.add(shellId.accountUuid);
+    } else if (!have.has(shellId.accountUuid)) {
+      have.add(shellId.accountUuid);
+      list.push(shell);
+    }
+  }
   const listed = new Set(list.map((p) => dirOf(p)));
+  if (shell && list.includes(shell)) listed.add(dflt);
 
   for (const found of discoverProfiles({ home })) {
     if (listed.has(found.dir)) continue;
@@ -138,6 +193,43 @@ export function effectiveProfiles(configured, { home = os.homedir() } = {}) {
   return list;
 }
 
+/**
+ * WHAT IS WRONG WITH THE SUBSCRIPTION THIS ROW STANDS FOR, not merely with the
+ *  folder it is named after.
+ *
+ *  Trouble is filed per FOLDER, because a folder is what a worker is handed.
+ *  `effectiveProfiles` above lists one row per SUBSCRIPTION, dropping a second
+ *  folder holding an account it already has. So a limit hit in the dropped
+ *  folder is filed under a key no row carries and is drawn nowhere, while the
+ *  row for that same subscription goes on showing whatever was last filed on
+ *  the listed folder, however old.
+ *
+ *  Measured 2026-10-16: ~/.claude-3 hit a session limit at 3:15pm and the row
+ *  for that subscription showed an "organization has turned Claude Code off"
+ *  filed on ~/.claude five days earlier. Both folders hold accountUuid
+ *  8fe4a357; the newest fact about the account was the invisible one.
+ *
+ *  THE NEWEST READING WINS, because that is the only honest answer when two
+ *  folders of one subscription disagree: each entry is what was true when a
+ *  run last died there, and nothing clears a folder nothing spawns on.
+ *  Codex keys are never considered — an account's key carries its engine. */
+export function troubleForProfile(troubles, profile, { home = os.homedir() } = {}) {
+  const dflt = defaultClaudeHome(home);
+  const dirOf = (p) => (p === 'default' ? dflt : p);
+  const idOf = (p) => accountIdentity(dirOf(p) === dflt ? null : dirOf(p), { home });
+  const own = troubles?.[profile] ?? null;
+  const mine = idOf(profile)?.accountUuid;
+  if (!mine) return own;
+  const when = (t) => t?.at ?? t?.since ?? 0;
+  let best = own;
+  for (const [key, t] of Object.entries(troubles ?? {})) {
+    if (!t || key === profile || key.startsWith('codex:')) continue;
+    if (idOf(key)?.accountUuid !== mine) continue;
+    if (when(t) > when(best)) best = t;
+  }
+  return best;
+}
+
 /**
  * Test seam only: forget the cached directory listing. Nothing in the app
  *  calls this — the mtime check is what keeps it honest at runtime. */

package/main/account-tooling.mjs

@@ -213,7 +213,7 @@ export function accountIdentity(dir, { home = os.homedir() } = {}) {
   try {
     const acct = JSON.parse(fs.readFileSync(file, 'utf8'))?.oauthAccount;
     if (acct?.emailAddress) {
-      value = { email: acct.emailAddress, accountUuid: acct.accountUuid ?? null };
+      value = { email: acct.emailAddress, accountUuid: acct.accountUuid ?? null, ...(acct.organizationUuid ? { organizationUuid: acct.organizationUuid } : {}) };
     }
   } catch {
     // A half-written file, or one Claude Code has changed the shape of. The
@@ -224,6 +224,34 @@ export function accountIdentity(dir, { home = os.homedir() } = {}) {
   return value;
 }
 
+/**
+ * A CLOUD LOGIN'S NAME, from the one login here in the same organization. A
+ * cloud token can say its organization but not its email. Null when no login
+ * here is in it, or when two different emails are, so a team organization is
+ * never pinned on whichever member happens to be signed in here.
+ */
+export function nameForOrganization(org, identities) {
+  if (!org) return null;
+  const emails = new Set(identities.filter((id) => id?.organizationUuid === org && id.email).map((id) => id.email));
+  return emails.size === 1 ? [...emails][0] : null;
+}
+
+/**
+ * The folder here holding a cloud login, so the two share one reading. A login
+ * that says its email is that person in its organization; one that says only
+ * its organization is the one email here in it, and none when two people here
+ * share it.
+ */
+export function profileForCloudLogin(login, identities) {
+  return identities.find((id) => isCloudLoginOf(login, id, identities))?.profile ?? null;
+}
+
+/** Whether a cloud login is the same subscription as one login here, by `profileForCloudLogin`'s rule. */
+export function isCloudLoginOf({ org, email }, identity, identities) {
+  if (!org || !identity?.email || identity.organizationUuid !== org) return false;
+  return (email || nameForOrganization(org, identities)) === identity.email;
+}
+
 /**
  * THE SENTENCE FOR TWO ROWS THAT TURNED OUT TO BE ONE ACCOUNT. It only ever
  * speaks on a machine that already has two profile folders, so it describes a

package/main/account-usage.mjs

@@ -0,0 +1,46 @@
+// EVERY CLAUDE ACCOUNT'S OWN USAGE, for the Settings page.
+//
+// main/claude-usage.mjs reads the account in use, for the corner on every
+// screen. This reads all of them, only when Settings asks, so the page can say
+// which login has room, and so a reading can take back a mark the account no
+// longer deserves (`Supervisor#noteUsageReading`).
+import { ClaudeUsage, STALE_MS } from './claude-usage.mjs';
+
+export class AccountUsage {
+  constructor({ bin, env = () => process.env, onReading = () => {}, run, now = () => Date.now(), where } = {}) {
+    this._bin = bin;
+    this._env = env;
+    this._onReading = onReading;
+    this._run = run;
+    this._now = now;
+    this._where = where;
+    this._readers = new Map();
+  }
+
+  _reader(profile) {
+    let reader = this._readers.get(profile);
+    if (!reader) {
+      reader = new ClaudeUsage({
+        bin: this._bin, run: this._run, now: this._now, where: this._where,
+        account: () => ({ profile, env: this._env() }),
+      });
+      this._readers.set(profile, reader);
+    }
+    return reader;
+  }
+
+  /** One answer per account, in the order given: its limits, or why there are none. */
+  async readAll(profiles, { refresh = false } = {}) {
+    return Promise.all(profiles.map(async (profile) => {
+      const reader = this._reader(profile);
+      const last = reader.peek();
+      const fresh = !refresh && last && this._now() - last.at < STALE_MS;
+      const result = fresh ? { ok: true, reading: last } : await reader.refreshNow();
+      if (result.ok && result.reading) {
+        if (!fresh) this._onReading(profile, result.reading);
+        return { ...result.reading, profile };
+      }
+      return { ...(reader.peek() ?? {}), profile, error: result.error ?? null };
+    }));
+  }
+}