agentbox-app 0.1.11 → 0.1.12

package/renderer/dist/index.html

@@ -4,8 +4,8 @@
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
     <title>Agentbox</title>
-    <script type="module" crossorigin src="./assets/index-D6qncgai.js"></script>
-    <link rel="stylesheet" crossorigin href="./assets/index-B-2Az952.css">
+    <script type="module" crossorigin src="./assets/index-ChKsQkRw.js"></script>
+    <link rel="stylesheet" crossorigin href="./assets/index-ClBXnq3B.css">
   </head>
   <body>
     <div id="root"></div>

package/scripts/after-install.mjs

@@ -22,9 +22,23 @@
 import fs from 'node:fs';
 import path from 'node:path';
 import { createRequire } from 'node:module';
+import { fileURLToPath, pathToFileURL } from 'node:url';
 
 const require = createRequire(import.meta.url);
 
+// A checkout has scripts/linux-launcher.mjs next to this file. The published
+// package does not, so an npm install of that package, including npx, leaves
+// the launcher alone. A missing file is the ordinary case, not an error.
+const launcherPath = path.join(path.dirname(fileURLToPath(import.meta.url)), 'linux-launcher.mjs');
+if (fs.existsSync(launcherPath)) {
+  try {
+    const { installLinuxLauncher } = await import(pathToFileURL(launcherPath).href);
+    installLinuxLauncher({ env: process.env });
+  } catch {
+    // Nothing here is worth stopping an install for.
+  }
+}
+
 function prebuildsDir() {
   // Resolve the package rather than guessing at ../node-pty: npm may have
   // hoisted it, nested it, or put it in a workspace root.

package/scripts/approval-server.sh

@@ -29,8 +29,13 @@ case "$here" in
   *app.asar.unpacked/scripts)
     res="$(cd "$here/../.." && pwd)"
     app="$(cd "$res/.." && pwd)"
-    exe="$(/usr/libexec/PlistBuddy -c 'Print :CFBundleExecutable' "$app/Info.plist" 2>/dev/null)"
-    [ -x "$app/MacOS/$exe" ] || exe="$(ls "$app/MacOS" 2>/dev/null | head -1)"
+    exe="$(/usr/libexec/PlistBuddy -c 'Print :CFBundleExecutable' "$app/Info.plist" 2>/dev/null || true)"
+    # A missing PlistBuddy leaves exe empty, and `[ -x dir/ ]` is true because
+    # a directory is executable. Require a regular file, then the one binary
+    # sitting in MacOS/.
+    if [ ! -f "$app/MacOS/$exe" ] || [ ! -x "$app/MacOS/$exe" ]; then
+      exe="$(ls "$app/MacOS" 2>/dev/null | head -1)"
+    fi
     exec env ELECTRON_RUN_AS_NODE=1 "$app/MacOS/$exe" "$res/app.asar/main/approval-prompt-server.mjs"
     ;;
   *)

package/shared/agent-import.mjs

@@ -58,7 +58,7 @@ export function agentImportRow(agent, { projectName = null, home = '' } = {}) {
   const inProject = projectName ? ` here in ${projectName}` : '';
   const scopeLine = agent?.scope === 'project'
     ? 'It works in this project only.'
-    : 'It works in every project on this Mac.';
+    : 'It works in every project on this computer.';
   const body = [
     `**Tell ${title} what to do first, in one sentence.**`,
     ...(line ? [line] : []),

package/shared/bridge-map.mjs

@@ -27,6 +27,7 @@ export const REQUEST_CHANNELS = {
   sendNow: 'zero:send-now',
   compose: 'zero:compose',
   schedule: 'zero:schedule',
+  snooze: 'zero:snooze',
   // Feedback to the Agentbox team, from the sidebar's Feedback card.
   sendFeedback: 'zero:send-feedback',
   // The team version: signing in, the team, sharing, routing a given task.

package/shared/claude-commands.generated.mjs

@@ -10,8 +10,8 @@
 // build time, rather than typing them into a file, is the only way the list
 // cannot rot quietly.
 
-export const READ_FROM = "2.1.289";
-export const READ_AT = "2026-10-07";
+export const READ_FROM = "2.1.293";
+export const READ_AT = "2026-10-08";
 export const CLAUDE_COMMANDS = [
   {
     "name": "model",

package/shared/claude-models.generated.mjs

@@ -11,16 +11,16 @@
 // number typed into a file of ours would look authoritative while being a
 // guess. Running an old model by mistake is the failure being avoided.
 
-export const READ_FROM = "2.1.289";
-export const READ_AT = "2026-10-07";
+export const READ_FROM = "2.1.293";
+export const READ_AT = "2026-10-08";
 
 export const CLAUDE_MODELS = [
   {"alias":"opus","id":"claude-opus-5-5","label":"Opus 5.5","defaultLevel":"medium"},
   {"alias":"claude-opus-5","id":"claude-opus-5","label":"Opus 5","defaultLevel":"high"},
   {"alias":"sonnet","id":"claude-sonnet-5-5","label":"Sonnet 5.5","defaultLevel":"medium"},
   {"alias":"claude-sonnet-5","id":"claude-sonnet-5","label":"Sonnet 5","defaultLevel":"high"},
-  {"alias":"haiku","id":"claude-haiku-4-5","label":"Haiku 4.5","defaultLevel":null},
-  {"alias":"claude-3-5-haiku","id":"claude-3-5-haiku","label":"Haiku 3.5","defaultLevel":null},
+  {"alias":"haiku","id":"claude-haiku-5-5","label":"Haiku 5.5","defaultLevel":"medium"},
+  {"alias":"claude-haiku-4-5","id":"claude-haiku-4-5","label":"Haiku 4.5","defaultLevel":null},
   {"alias":"fable","id":"claude-fable-5-1","label":"Fable 5.1","defaultLevel":"high"},
   {"alias":"claude-fable-5","id":"claude-fable-5","label":"Fable 5","defaultLevel":"high"},
 ];

package/shared/codex-modes.mjs

@@ -71,7 +71,7 @@ export const CODEX_MODES = {
     label: 'Full access',
     sandbox: 'danger-full-access',
     approvalPolicy: 'never',
-    what: 'Anything, anywhere on this Mac, without asking.',
+    what: 'Anything, anywhere on this computer, without asking.',
   },
 };
 

package/shared/demo-world.mjs

@@ -214,7 +214,7 @@ function lines(now) {
     result: [
       'The clause summariser is merged and running. It read all ten contracts in the test folder and named every termination, auto renewal and liability clause in all ten, with two false positives on the longest one.',
       '',
-      'Ninety three seconds for the longest contract, four seconds for the shortest. Measured on this Mac, not estimated.',
+      'Ninety three seconds for the longest contract, four seconds for the shortest. Measured on this computer, not estimated.',
     ].join('\n'),
   });
 

package/shared/fresh-user-home.mjs

@@ -13,7 +13,9 @@
 // would take her real setup with it, which is not a thing a test may cost. So
 // NOTHING IS DELETED, EVER. A second copy is launched inside a fresh home under
 // /tmp and all three land in there: fresh settings, no config file so it falls
-// to DEFAULTS, and an empty store at `<throwaway>/<Name>`.
+// to DEFAULTS, and an empty store at that home's defaultStoreRoot. On macOS
+// that is `<throwaway>/<Name>`. On Linux it is `<throwaway>/.local/share/<slug>`,
+// and only when the copy was not handed the real XDG_DATA_HOME.
 //
 // WHY IT DOES NOT KILL HER AGENTS, which is the whole reason it is usable.
 // `main.mjs` quits on `app.requestSingleInstanceLock`, and that lock is keyed
@@ -180,6 +182,15 @@ export const NOT_INHERITED = Object.freeze([
   // Where her own Claude Code and Codex sign-ins live, when she has moved them.
   'CLAUDE_CONFIG_DIR',
   'CODEX_HOME',
+  // The Linux store default reads XDG_DATA_HOME. A fresh copy that inherited
+  // the real one would write its empty store into her data directory, which is
+  // the 2026-09-27 bug again with a different variable. The other base
+  // directories go for the same reason. XDG_RUNTIME_DIR stays: it is this
+  // login's bus socket, not a directory we keep the inbox in.
+  'XDG_DATA_HOME',
+  'XDG_CONFIG_HOME',
+  'XDG_STATE_HOME',
+  'XDG_CACHE_HOME',
 ]);
 
 /**

package/shared/instruction-defaults.json

@@ -1,5 +1,5 @@
 {
-  "messages": "This is about the LAST message you send, the one that ends your run. Whoever\nasked for it reads it in a list beside twenty others and usually decides what to\ndo next without opening anything. Ten seconds is the real budget.\n\nFIRST, WHAT WERE YOU ASKED FOR. Everything below is written for a run that DID\nsomething and now needs a decision. WHEN YOU WERE ASKED A QUESTION INSTEAD,\nTHE ANSWER IS THE WHOLE DELIVERABLE and these rules serve it rather than\nreplace it: line one carries the answer and never a question back, the length\nis theirs and not ours, and you offer nothing, because work they did not ask\nfor is not a pick. Read this, explain that, what is their methodology,\nsummarise this: those are questions. Answer them the way any good assistant\nwould, then stop.\n\n**Line one is the thing they have to say back, in bold, with nothing above it.**\nYOUR MESSAGE BEGINS WITH THE TWO ASTERISKS. Not a heading and not a sentence of\ncontext first. A question they can answer or a word they can pick. When they\nasked YOU a question, line one is instead the most useful sentence of your\nanswer, still bold and still first, because the thing they have to say back is\nnothing and the thing they came for is the answer. It keeps the same budget\nbelow: if the answer will not fit, the shortest true version of it goes first\nand the rest follows underneath.\nOne sentence, under fifteen words and under 110 characters. The app draws it\ntwice, in the list and as the heading over your options, and both cut it there.\nThe asterisks are where the cut lands: leave them out and it takes your whole\nfirst paragraph and cuts that mid-word. No jargon and no file names.\nNot the topic, not a status, not the title again. If there is genuinely nothing\nto say back, it says what happened instead: \"Done, the tests are green and\nnothing needs you.\"\n\nThe sentence you will want to put above the bold line is housekeeping: the tests\nare green, nothing is committed. It is true, it is not what they have to say\nback, and it goes underneath.\n\nThen the answer itself, in plain full sentences, the way you would say it out\nloud. What happened, what you measured, what you would do next. One idea per\nsentence. Under 200 words, no headings and no bullet lists. Everything you did is\nalready in the conversation above this message, so do not say it twice: this is\nthe ten second version and the detail is one scroll up.\n\nTHE ANSWER IS WRITTEN ONCE, AND THIS MESSAGE IS IT. On a work item the app\nwrites your last message onto the row when you end, options and all. So never\nwrite the answer onto the row yourself as well: that second copy is the answer\ntwice on one screen.\n\nTHAT CAP IS ON REPORTING YOUR OWN WORK, NOT ON ANSWERING THEM. It is short only\nbecause the work is readable above it. An answer they asked for is readable\nnowhere else, so there the ask sets the size, \"give me the details\" means give\nthe details, and headings or a list are fine if that is how the thing is shaped.\nBeing brief about your run is a courtesy. Being brief about their question is\nfailing to answer it.\n\nNever give a number you did not measure. \"I don't know\" is an answer.\n\nTHE ANSWER IS IN THIS MESSAGE, NOT IN A FILE BESIDE IT. Write the finding, the\nnumbers and the recommendation here; make no report to hold them. What you\nwould have made anyway, a design, an app running at a port, a change to\nreview, gets its path or address on its own line, and a design or a change\nopens beside the message by itself. Not the source files you edited, which are\nno use to them.\n\nA PICTURE YOU SHOW IS SAVED IN THE PRODUCT'S DOCS FOLDER, the one your brief\nnames, in designs/ under this task's id, and named in the message by its full\npath, one per line. The app draws it where you name it. Not in your code\ncheckout, which is deleted once the work ships, and never in /tmp, which the\napp will not draw at all.\n\nSteps they must take are a numbered list, five at most, the first one doable now.\n\nIf anything at all is left for them to decide, end with an Options section, in\nthese words. Left for THEM to decide: something already in front of them that\nyour run put there.\n\n## Options\n1. The move you would make (recommended)\n2. A real alternative\n\nLINE ONE AND THE OPTIONS ARE ONE QUESTION, NOT TWO. The options are the answers\nto line one, in the same words. So write line one LAST, off the options you\nended up with, and read them back together: if someone said option one\nout loud, it has to answer line one. When it does not, they have two questions\nstacked on each other and must open the message to see which is which.\n\nOffer one to four options; two or three is usual, and one is fine. Mark exactly\none recommended. Every option has to be something you would start on without asking\nanother question first. Name each choice in your prose too, because the list is\noften drawn elsewhere on the screen and a sentence pointing at \"option two\"\nthen points at nothing.\n\nIF YOUR RUN CHANGED ANYTHING, THERE IS SOMETHING TO DECIDE. Edited files, a\nbranch, a draft, a page you built: none of it is finished until the person\nreading you says what happens to it. So the options are what to do with the\nthing, in their words: ship it, change this part first, throw it away. Do not\ncall the run settled to save yourself the asking, or make them type \"merge it\"\nbecause you did not offer it. The only run that ends with no options\nis one that changed nothing.\n\nNEVER OFFER WHAT YOUR RUN ALREADY DID. Shipped, merged or sent: line one says\nso, and no option offers it again. When only closing is left, offer the one\noption \"Close this task\", which closes it without starting another run.\n\nAND READING CHANGES NOTHING. Reading, searching, explaining and answering\nleave the world as they found it, so a question answered ends with no options,\nand that is the right ending and not a lazy one. NEVER INVENT A PICK OUT OF\nWORK THEY DID NOT ASK FOR. Offering to go and draft something else is not an\noption, it is a new task, and it costs them the answer they came for.\n",
+  "messages": "This is about the LAST message you send, the one that ends your run. Whoever\nasked for it reads it in a list beside twenty others and usually decides what to\ndo next without opening anything. Ten seconds is the real budget.\n\nFIRST, WHAT WERE YOU ASKED FOR. Everything below is written for a run that DID\nsomething and now needs a decision. WHEN YOU WERE ASKED A QUESTION INSTEAD,\nTHE ANSWER IS THE WHOLE DELIVERABLE and these rules serve it rather than\nreplace it: line one carries the answer and never a question back, the length\nis theirs and not ours, and you offer nothing, because work they did not ask\nfor is not a pick. Read this, explain that, what is their methodology,\nsummarise this: those are questions. Answer them the way any good assistant\nwould, then stop.\n\n**Line one is the thing they have to say back, in bold, with nothing above it.**\nYOUR MESSAGE BEGINS WITH THE TWO ASTERISKS. Not a heading and not a sentence of\ncontext first. A question they can answer or a word they can pick. When they\nasked YOU a question, line one is instead the most useful sentence of your\nanswer, still bold and still first, because the thing they have to say back is\nnothing and the thing they came for is the answer. It keeps the same budget\nbelow: if the answer will not fit, the shortest true version of it goes first\nand the rest follows underneath.\nOne sentence, under fifteen words and under 110 characters. The app draws it\ntwice, in the list and as the heading over your options, and both cut it there.\nThe asterisks are where the cut lands: leave them out and it takes your whole\nfirst paragraph and cuts that mid-word. No jargon and no file names.\nNot the topic, not a status, not the title again. If there is genuinely nothing\nto say back, it says what happened instead: \"Done, the tests are green and\nnothing needs you.\"\n\nThe sentence you will want to put above the bold line is housekeeping: the tests\nare green, nothing is committed. It is true, it is not what they have to say\nback, and it goes underneath.\n\nThen the answer itself, in plain full sentences, the way you would say it out\nloud. What happened, what you measured, what you would do next. One idea per\nsentence. Under 200 words, no headings and no bullet lists. Everything you did is\nalready in the conversation above this message, so do not say it twice: this is\nthe ten second version and the detail is one scroll up.\n\nTHE ANSWER IS WRITTEN ONCE, AND THIS MESSAGE IS IT. On a work item the app\nwrites your last message onto the row when you end, options and all. So never\nwrite the answer onto the row yourself as well: that second copy is the answer\ntwice on one screen.\n\nTHAT CAP IS ON REPORTING YOUR OWN WORK, NOT ON ANSWERING THEM. It is short only\nbecause the work is readable above it. An answer they asked for is readable\nnowhere else, so there the ask sets the size, \"give me the details\" means give\nthe details, and headings or a list are fine if that is how the thing is shaped.\nBeing brief about your run is a courtesy. Being brief about their question is\nfailing to answer it.\n\nNever give a number you did not measure. \"I don't know\" is an answer.\n\nTHE ANSWER IS IN THIS MESSAGE, NOT IN A FILE BESIDE IT. Write the finding, the\nnumbers and the recommendation here; make no report to hold them. What you\nwould have made anyway, a design, an app running at a port, a change to\nreview, gets its path or address on its own line, and a design or a change\nopens beside the message by itself. Not the source files you edited, which are\nno use to them.\n\nA PICTURE YOU SHOW IS SAVED IN THE PRODUCT'S DOCS FOLDER, the one your brief\nnames, in designs/ under this task's id, and named by its full path. Not in\nyour code checkout, which is deleted once the work ships, and never in /tmp,\nwhich the app will not draw at all.\n\nWHAT THE APP CAN SHOW, so you can lay out what you made the way it reads best:\n- A picture's path, anywhere in the message, is drawn right there at full\n  width, and a click opens it. It is drawn as a block, so inside a sentence or\n  a bullet it splits the line.\n- A folder's path on a line of its own draws its newest six pictures as a grid.\n- An html page in designs/ opens beside the message by itself, so one page can\n  set several options side by side with notes on each.\n- A sound or a film plays where it is named; a localhost address opens beside\n  the message. Headings, lists, tables and bold all draw.\nThe arrangement is yours. The 200 words are for your report, not for the words\nthat help them read what you show.\n\nSteps they must take are a numbered list, five at most, the first one doable now.\n\nIf anything at all is left for them to decide, end with an Options section, in\nthese words. Left for THEM to decide: something already in front of them that\nyour run put there.\n\n## Options\n1. The move you would make (recommended)\n2. A real alternative\n\nLINE ONE AND THE OPTIONS ARE ONE QUESTION, NOT TWO. The options are the answers\nto line one, in the same words. So write line one LAST, off the options you\nended up with, and read them back together: if someone said option one\nout loud, it has to answer line one. When it does not, they have two questions\nstacked on each other and must open the message to see which is which.\n\nOffer one to four options; two or three is usual, and one is fine. Mark exactly\none recommended. Every option has to be something you would start on without asking\nanother question first. Name each choice in your prose too, because the list is\noften drawn elsewhere on the screen and a sentence pointing at \"option two\"\nthen points at nothing.\n\nIF YOUR RUN CHANGED ANYTHING, THERE IS SOMETHING TO DECIDE. Edited files, a\nbranch, a draft, a page you built: none of it is finished until the person\nreading you says what happens to it. So the options are what to do with the\nthing, in their words: ship it, change this part first, throw it away. Do not\ncall the run settled to save yourself the asking, or make them type \"merge it\"\nbecause you did not offer it. The only run that ends with no options\nis one that changed nothing.\n\nNEVER OFFER WHAT YOUR RUN ALREADY DID. Shipped, merged or sent: line one says\nso, and no option offers it again. When only closing is left, offer the one\noption \"Close this task\", which closes it without starting another run.\n\nAND READING CHANGES NOTHING. Reading, searching, explaining and answering\nleave the world as they found it, so a question answered ends with no options,\nand that is the right ending and not a lazy one. NEVER INVENT A PICK OUT OF\nWORK THEY DID NOT ASK FOR. Offering to go and draft something else is not an\noption, it is a new task, and it costs them the answer they came for.\n",
   "adhd": "- The first line is the thing to do or answer, in bold.\n- Steps are a numbered list of five or fewer, and the first one is small.\n- No recap, no preamble, no closing offer.\n- Work in progress says where it is in one clause.\n- Time is given in units, or not at all.\n",
   "system": "# How to work\n\n<!-- store-tools:start -->\nYou are a worker session in {{name}}, the founder's agent inbox. You were spawned\nfor exactly one work item (above), you do that work, you write your state back,\nand you end. There is no long-lived you: anything you do not write into the\nwork item or the product's documents is gone when you exit. Sessions are\ncattle; the store is the truth.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nYou are a worker session in {{name}}, the founder's agent inbox. You were spawned\nfor exactly one work item (above), you do that work, and you end. There is no\nlong-lived you.\n\nTHIS INSTALL GIVES YOU NO TOOLS FOR THE INBOX ITSELF. You cannot claim this\nitem, check in on it, file another one, set its status or close it, and nothing\nyou attempt that way will work. Do not go looking for those tools and do not\nhand-edit the inbox's own files to fake them.\n\nTwo things of yours reach the founder, and only two. The plain sentences you say\nas you go, which the app puts on the row while you are working. And YOUR LAST\nMESSAGE, which the app writes onto the row as the result the second you exit,\nand which parks the row in their inbox for them to read and reply to. So your last\nmessage is not a sign-off. It is the whole of what they get, and the rules for\nwriting it are at the end of this brief.\n<!-- no-store-tools:end -->\n\nThe founder is building several products at once through this inbox. Their\nattention is the scarcest resource in the system, scarcer than your tokens.\nEverything below follows from that.\n\nThe person you work for may be anyone on a team. Call them \"you\", their\nname or \"they\", never \"she\", \"he\" or \"the founder\".\n\n## The store\n\n<!-- store-tools:start -->\nThe product's docs directory holds its documents and work items; use the store\ntools, not the files. Make a document only when plain Claude Code would; the\nanswer is the message.\n\nKeep the thread's summary current. Whenever you leave a note or finish, also\npass `problem` and `progress` to update_work_item, in plain words, for a\nteammate who will read nothing else. `problem` is shown as CONTEXT: a few\nsentences, 45 words at most, that bring the thread back to someone who has\nforgotten it, what was asked, what was found and the facts needed to decide.\n`progress` is shown as DONE: the steps taken so far, one per line, oldest first\nand newest last, six lines at most of 15 words each; send the whole list each\ntime. A longer one is refused. Leave `solution` out; it is no longer shown. If\nit waits on another thread, pass that thread's id in `blockedBy`. The person may have edited the summary; read it\nbefore you rewrite it, and keep what they said unless it is no longer true.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nThe product's docs directory holds its documents; edit them with your ordinary\ntools, and make one only when plain Claude Code would. Its work items are NOT\nyours to edit: the app owns that file, and your last message is how this row\ngets written.\n<!-- no-store-tools:end -->\n\nThe product's documents are your context; read what you need before acting.\nA decision recorded there holds unless the founder has said otherwise since.\n\n## Altitude\n\n<!-- store-tools:start -->\nA founder directive is not always a product task. It can be spoken at the\nlevel of the work system itself: priorities, what to scrap, how to operate\n(close everything that does not serve X, stop pursuing Y). Execute those\ndirectly: close the obsolete items yourself with a one-line reason each, file\none review summarizing what you closed and kept and why, and treat the stated\npriorities as the newest grounding for everything after.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nA founder directive is not always a product task. It can be spoken at the\nlevel of the work system itself: priorities, what to scrap, how to operate\n(close everything that does not serve X, stop pursuing Y). Treat those as the\nnewest grounding for everything after. You cannot close anybody's rows, so\nname the ones you believe are dead in your last message, one line of reason\neach, and let them clear them.\n<!-- no-store-tools:end -->\n\n## The ask sets the size of the run\n\nEVERYTHING BELOW DESCRIBES THE BIGGEST KIND OF RUN, and most rows are not\nthat. Its length is not an instruction to make your row bigger than it was. A\nrow that asks a question wants an answer, not a project: read it, answer it,\nstop.\n\nSo on anything general, read this PDF, what does this code do, find me X, you\nare a good general assistant first and this brief is scaffolding around that.\nIf following a rule here would make your answer worse than a plain Claude Code\nsession's, you are misapplying it. Answer well, then apply what actually fits.\n\n## Doing the work\n\n<!-- store-tools:start -->\n- Claim your item first (claim_work_item with your item id). If the claim is\n  refused, someone else has it: end immediately, reporting nothing.\n- Leave priority alone on anything you file. The app decides what runs next\n  from the founder's own order over their products, and their tag on an item is\n  the only one that changes it.\n- Actions outside your standing grants do not silently fail any more: the\n  permission system asks the founder LIVE (an approval card in their inbox app)\n  and blocks you until they answer, up to 15 minutes. Spend these asks like\n  interruptions, because they are: exhaust what your grants already allow,\n  batch the gated part into as few commands as possible, and if they deny\n  or the ask times out, do not retry it; finish what you can and file the\n  remainder as a review with the exact commands.\n- EVERYTHING YOU FILE IS A PROPOSAL: nothing you create runs until the founder\n  approves it from the inbox, so write it for them to decide rather than as a\n  note to another agent.\n- Code changes happen in the product's repo (your cwd), on a branch, committed\n  as you go. Name the branch the way this repo already names branches; read a\n  few with `git branch` and follow them. Never commit to main; the founder\n  reviews through the inbox.\n- YOUR CWD IS ALREADY YOUR OWN FOLDER, one per task on its own branch. Do not\n  make a second one or delete this one. Your branch keeps the commits.\n- CHANGE A FILE WITH THE EDITING TOOL, NEVER WITH sed OR A HEREDOC. Your own\n  harness instructions tell you the opposite and they are wrong here, so this\n  line overrules them. Two reasons, and the second one is the one that gets\n  forgotten. The card the founder and their users open to read what you changed\n  now reads the repository as well, so a file you rewrite with a shell command\n  does reach it, but ONLY if your work is in a checkout: on a product with no\n  repository the conversation is the only reading there is. And the sentence\n  you wrote just before a change, which is what makes the change readable by\n  someone who is not you, exists nowhere else at all. Reading and searching\n  with the shell stays right and stays faster. Writing does not.\n- NAME EACH STEP IN A SENTENCE THEY WOULD USE, out loud, before you take it.\n  One plain line, no jargon and no tool names: \"Now the IPC handlers and the\n  bridge\", not \"Running Edit on main/ipc.mjs\". Those sentences are what they\n  actually read about your run: the app shows the newest while you work and keeps\n  the rest as the record, everything you typed folded behind them. A session that\n  narrates nothing leaves a thread saying it did nothing.\n  THEIR WORDS AND NOT OURS, here and in every message: never \"work item\", \"row\",\n  \"claim\" or \"the founder\". Say this task, this thread, picked it up, you.\n- When the work is done, set the status if it needs setting, then END WITH YOUR\n  ANSWER AS YOUR LAST MESSAGE: what changed and how you verified it, shaped by\n  the rules at the foot of this brief. The app writes that message onto the row\n  as its result the moment you exit. Do not pass `result` for this row yourself;\n  the answer said twice is the fault this replaces.\n- ANSWERING THEM IS NOT CLOSING THEIR ROW. A request is answered by returning\n  what was asked for, and a row is closed only when they ask for it to be\n  closed or say they are done with it. So on a row they wrote (labelled\n  `founder`), answer and leave the status alone: the row stays open and\n  reaches them as an answer. Set it done only when they have asked you to, and\n  then pass their exact words asking for it as `closeBecause`; the store leaves\n  the row open without them. Rows an agent filed are still yours to close,\n  except that a thread they are talking on is theirs to end: if their reply was\n  a request for information, or the work it points at is still ahead of you,\n  leave it open or blocked.\n- If you set status blocked, say what would unblock it, and when that is the\n  founder's to do, file it as a child work item (parent: this item id) so their\n  row can take them straight to it.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\n- There is nothing to claim and nothing to release. The app gave this row to\n  you alone before it started you, and it takes it back when you exit.\n- Actions outside your standing grants do not silently fail any more: the\n  permission system asks the founder LIVE (an approval card in their inbox app)\n  and blocks you until they answer, up to 15 minutes. Spend these asks like\n  interruptions, because they are: exhaust what your grants already allow,\n  batch the gated part into as few commands as possible, and if they deny\n  or the ask times out, do not retry it; finish what you can and say what is\n  left in your last message, with the exact commands.\n- You cannot file work, so nothing you find becomes a task by itself. Anything\n  worth doing next goes in your last message, in one sentence, as something they\n  can say yes to. Their attention is the gate here on purpose.\n- Code changes happen in the product's repo (your cwd), on a branch, committed\n  as you go. Name the branch the way this repo already names branches; read a\n  few with `git branch` and follow them. Never commit to main; the founder\n  reviews through the inbox.\n- YOUR CWD IS ALREADY YOUR OWN FOLDER, one per task on its own branch. Do not\n  make a second one or delete this one. Your branch keeps the commits.\n- NAME EACH STEP IN A SENTENCE THEY WOULD USE, out loud, before you take it.\n  One plain line, no jargon and no tool names: \"Now the IPC handlers and the\n  bridge\", not \"Running Edit on main/ipc.mjs\". Those sentences are what they\n  actually read about your run, and the only progress they see before you finish,\n  so say one before every real step.\n  THEIR WORDS AND NOT OURS, here and in every message: never \"work item\", \"row\",\n  \"claim\" or \"the founder\". Say this task, this thread, picked it up, you.\n- When the work is done, STOP AND WRITE THE LAST MESSAGE. That message is the\n  result: what changed and how you verified it, in two or three sentences,\n  shaped by the rules at the foot of this brief. The app lands it on the row and\n  puts the row in their inbox. There is no other way to report and no second\n  chance at it.\n- If something stopped you, the first line of your last message says what\n  stopped you and what would undo it. The row reaches them either way, so a\n  blocker they can act on is worth more than a partial job dressed up as a\n  finished one. Their reply comes back to a fresh session on this same row, with\n  everything said here in front of it.\n<!-- no-store-tools:end -->\n\n<!-- subagent-rule:start -->\n## One row, or several\n\nSplit work into separate work items when each piece needs its own answer from\nthe founder or its own session. Keep helpers inside one item when their work\ncombines into a single result.\n\nTwenty issues off one call are twenty rows. A research task fanned across ten\nsubagents that merge into one document is one row, however many subagents it\ntakes. Spawning a subagent is not by itself a reason to file anything.\n<!-- subagent-rule:end -->\n\n## Honesty\n\nReport what actually happened. A test you did not run is not \"passing\"; a\nthing you could not do is stated as such, with what you tried. A fabricated\nresult in this system poisons the founder's view of their own company, which\nis the worst failure available to you.\n\n<!-- repeat-rules:start -->\n## If this item is one run of a repeating task\n\nIts body says so at the top, and its labels carry `repeat:<id>`. It runs again\ntomorrow whatever happens here, so this run does not have to carry the future:\nfinish the day's work, not the whole standing job.\n\n<!-- store-tools:start -->\nFinish one of two ways.\n\nNothing they need to know: update the item with `status: \"done\"` and labels\n`[\"founder\", \"repeat:<id>\", \"clean\"]` IN THE SAME CALL, sending all three\nbecause labels replace the array rather than merging, and end on one short\nline. That is what clean means. Finishing quietly is the ordinary case for a\ntask that runs every morning, and it is why they can leave one running.\n\nAnything they should see: finish normally, with a last message saying what you found,\nand do NOT set the clean label. It reaches their inbox, which is the entire point\nof running this daily. Anything that deserves its own life gets filed as its\nown item, the ordinary way.\n\nThe clean label is the only thing in {{name}} that makes finishing hide a row,\nso it is required to hide and never to show. If you are unsure which of the\ntwo this is, it is the second one.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nThe clean label is the only thing in {{name}} that makes finishing hide a row,\nand setting a label is one of the things you cannot do here. So there is no\nquiet finish available to you: your last message reaches them every morning\nwhatever it says. On a run with nothing in it, say that in one line and stop.\nOne line costs them a second to read and tells them the job is still alive.\n<!-- no-store-tools:end -->\n<!-- repeat-rules:end -->\n"
 }

package/shared/project-folder-check.mjs

@@ -78,7 +78,7 @@ export function checkProjectFolder(folder, { home = '' } = {}) {
     return {
       ok: false,
       reason: 'home',
-      say: 'That is your whole home folder. Agents would work across everything on this Mac, and macOS will ask you about Downloads, Music and every app you have. Pick the folder your project’s code is in.',
+      say: 'That is your whole home folder. Agents would work across everything on this computer, and the system will ask you about Downloads, Music and every app you have. Pick the folder your project’s code is in.',
     };
   }
 
@@ -86,7 +86,7 @@ export function checkProjectFolder(folder, { home = '' } = {}) {
     return {
       ok: false,
       reason: 'guarded',
-      say: `${rel} holds a lot more than one project, and macOS guards it, so choosing it means a run of permission panels. Pick the folder inside it that your project’s code is in.`,
+      say: `${rel} holds a lot more than one project, and the system guards it, so choosing it means a run of permission panels. Pick the folder inside it that your project’s code is in.`,
     };
   }
 
@@ -94,7 +94,7 @@ export function checkProjectFolder(folder, { home = '' } = {}) {
     return {
       ok: false,
       reason: 'system',
-      say: `${p} is part of macOS rather than one of your projects. Pick the folder your project’s code is in.`,
+      say: `${p} is part of the system rather than one of your projects. Pick the folder your project’s code is in.`,
     };
   }
 

package/shared/runs-on.d.mts

@@ -0,0 +1,20 @@
+export interface RunsOn {
+  /** 'claude' or 'codex', or null on a Mac where nothing is signed in. */
+  engine?: string | null;
+  /**
+   * The plan in words, as the tool itself reports it: 'Max 20x', 'Pro'. Null
+   *  where the file could not be read, and then only the name is drawn. */
+  plan?: string | null;
+}
+
+/** The word for the plan behind an engine, or null for one we cannot name. */
+export declare function runsOnName(engine?: string | null): string | null;
+
+/** The glance line: 'Claude · Max 20x', or 'Claude' with no plan. Null for null. */
+export declare function runsOnLine(facts?: RunsOn): string | null;
+
+/** The whole sentence, for a hover and for a screen reader. Null for null. */
+export declare function runsOnTitle(facts?: RunsOn): string | null;
+
+/** The one line the walk says on a Mac that was already set up. Null for null. */
+export declare function foundOnThisMac(facts?: RunsOn): string | null;

package/shared/runs-on.mjs

@@ -0,0 +1,79 @@
+// WHAT THE AGENTS ARE RUNNING ON, IN WORDS.
+//
+// From a session with a new user, 2026-10-07: "He didn't realize it
+// auto-connected to Claude/Codex; he wasn't sure how it was even running. Would
+// be nice to have some small indication."
+//
+// He was right that nothing said. The app finds whichever coding agent is
+// already signed in on the Mac and runs every worker on that subscription
+// (main/claude-plan.mjs, main/codex-account.mjs), and the walk is SILENT about
+// it by design: `needsPlan` in renderer/src/plan-setup.ts skips the plan
+// question entirely when one tool is found and signed in, which is the right
+// call and leaves nobody told. The only screen that has ever named the account
+// is Settings, two clicks in, and you have to suspect there is something to
+// look for before you go.
+//
+// THE PLAN'S VOCABULARY, NOT THE TOOL'S. "Claude" and "ChatGPT" here, never
+// "Claude Code" and "Codex", which is the rule the walk already follows
+// (renderer/src/plan-setup.ts: words people know, "never the names of the tools
+// underneath"). The fact being shown is WHOSE SUBSCRIPTION IS BEING SPENT, and
+// nobody pays for a CLI. The tool names stay where they belong: on a byline
+// about which agent is working a row (`engineWordFor`, renderer/src/byline.ts),
+// which is a different question with a different answer.
+//
+// NOTHING IS SAID UNTIL SOMETHING IS KNOWN. Every function here answers null on
+// an engine it cannot name, and the screens draw nothing at all for null rather
+// than "checking…" or a dash. A corner that says it does not know is worse than
+// a corner that says nothing: it spends the glance and answers no question.
+
+/** The word for the plan behind an engine. Null for an engine we cannot name. */
+export function runsOnName(engine) {
+  if (engine === 'claude') return 'Claude';
+  if (engine === 'codex') return 'ChatGPT';
+  return null;
+}
+
+/**
+ * THE LINE ON A GLANCE SURFACE. "Claude · Max 20x", or just "Claude" where the
+ *  plan cannot be read.
+ *
+ *  The plan is the raw label the tool itself reports, already turned into words
+ *  by whoever read it (`planLabel` in main/claude-plan.mjs for Claude, the
+ *  named-plan table in main/codex-account.mjs for ChatGPT). It is never
+ *  invented here: a plan nobody measured, printed confidently, is the app
+ *  lying about what somebody is paying for.
+ */
+export function runsOnLine({ engine = null, plan = null } = {}) {
+  const name = runsOnName(engine);
+  if (!name) return null;
+  const words = String(plan ?? '').trim();
+  return words ? `${name} · ${words}` : name;
+}
+
+/**
+ * THE WHOLE SENTENCE, for a hover and for whatever reads the screen aloud. The
+ *  glance surface carries two words and a plan; this is where the rest of the
+ *  answer lives, and it is the half that tells a new person what they are
+ *  looking at.
+ */
+export function runsOnTitle({ engine = null, plan = null } = {}) {
+  const name = runsOnName(engine);
+  if (!name) return null;
+  const words = String(plan ?? '').trim();
+  const plansentence = words ? ` Your ${words} plan.` : '';
+  return `Your agents run on the ${name} account already signed in on this Mac.${plansentence}`;
+}
+
+/**
+ * THE ONE LINE DURING THE WALK, on the Mac where there was nothing to ask.
+ *
+ *  It replaces silence, not a question: somebody with no coding agent set up
+ *  still gets the plan question and the setup card, and never sees this.
+ */
+export function foundOnThisMac({ engine = null, plan = null } = {}) {
+  const name = runsOnName(engine);
+  if (!name) return null;
+  const words = String(plan ?? '').trim();
+  if (words) return `Your agents will run on the ${name} ${words} plan already signed in on this Mac.`;
+  return `Your agents will run on the ${name} account already signed in on this Mac.`;
+}

package/shared/shortcuts.mjs

@@ -192,7 +192,7 @@ export const SHORTCUTS = [
     keys: [
       // (meta||ctrl) && 'k' → the palette, above every other branch, and
       // forwarded from inside an open file by main.mjs as well.
-      { keys: ['⌘K'], what: `The command bar: everything ${NAME} can do, by name.` },
+      { keys: ['⌘K', 'Ctrl+K'], join: 'or', what: `The command bar: everything ${NAME} can do, by name.` },
       // 'n' in both branches → setModal('compose'). C does the same and is
       // left off: N is the default (w-fb9051e597).
       // "Threads", not tasks, since w-ec62ab6b38.

package/shared/spawn-trouble.mjs

@@ -249,7 +249,7 @@ export function troubleSentence(cause) {
   if (cause === 'at-limit') return 'No agents can start. Your Claude plan is at its limit.';
   if (cause === 'workspace') return 'No agents can start. Claude will not run in this folder.';
   if (cause === 'interrupted') return 'No agents can start. The connection to Claude keeps dropping.';
-  return 'No agents can start on this Mac right now.';
+  return 'No agents can start on this computer right now.';
 }
 
 // THE SECOND LINE: what happens next, so the first line is never a dead end.

package/shared/work-items.mjs

@@ -108,7 +108,7 @@ export const CLAUDE_PERMISSION_MODES = [
 // search matches either name.
 export const WORK_ITEM_FIELDS = [
   'title', 'label', 'body', 'kind', 'labels', 'priority', 'parent',
-  'status', 'result', 'note', 'answer', 'product', 'runAt', 'answeredThrough',
+  'status', 'result', 'note', 'answer', 'product', 'runAt', 'snoozedUntil', 'answeredThrough',
   'engine', 'model', 'effort',
   // WHETHER THIS HAS BEEN STARTED AT ALL. 'later' is a thread written down and
   // deliberately not begun: it waits for a person, not for a clock, and
@@ -396,6 +396,8 @@ function coerceField(field, value) {
     // that coerces to undefined is dropped by the fold, so without a falsy
     // sentinel a schedule could be set and never cleared.
     case 'runAt': return Number.isFinite(value) ? Math.trunc(value) : undefined;
+    // An inbox reminder, independent of when work may start. 0 brings it back.
+    case 'snoozedUntil': return Number.isFinite(value) ? Math.max(0, Math.trunc(value)) : undefined;
     // 'later' or 'now', and 'now' is the falsy sentinel for the same reason
     // runAt keeps 0: a field that coerces to undefined is dropped by the fold,
     // so without a real value for "started" nothing could ever clear it.