@hwip/cli 0.1.4 → 0.1.6

package/README.md

@@ -557,11 +557,17 @@ offers it during setup and `hwip uninstall` takes it away again.
 What you get back after a reboot is your **past sessions**, ready to
 resume from the phone — not live agents. tmux does not survive a reboot
 either, and this doesn't try to bring those sessions back to life.
-A resume starts the agent in the directory it last ran in; for Claude Code
-and OpenCode it also picks up the conversation that session last had
-(`--resume <id>` / `--session <id>`, the id this machine read off the live
-pane's own process — an id two panes both answered to is not kept). Claude Code starts fresh when that conversation is no longer on disk,
-and the other agents always start a new one.
+A resume starts the agent in the directory it last ran in; for Claude Code,
+OpenCode, Codex, Pi and Hermes it also picks up the conversation that session
+last had (`claude --resume <id>`, `opencode --session <id>`,
+`codex resume <thread>`, `pi --session <file>`, `hermes --resume <id>` — the
+id this machine read off the live pane's own process; an id two panes both
+answered to is not kept). Claude Code, Codex and Pi start fresh when that
+conversation is no longer on disk, and the other agents always start a new one.
+Each ended run of a name is its own row on the phone, and starting one
+again picks up that run's conversation, not the newest one. If the name
+is live again by then, that run starts beside it under the next free name
+of the family (`<name>-2`, `<name>-3`, …) instead of being refused.
 
 Two details worth knowing:
 
@@ -645,8 +651,9 @@ went.
 - **The prompt** (`--prompt`) is typed once, and only when the agent is the foreground program of the pane and its detection rules read the screen as `idle` — not working, not a dialog. If that does not happen within 90 seconds the prompt is not typed, the session stays, and the phone is told. **Only agents that have an `idle` rule can take a prompt** (today Claude Code, Codex, Gemini CLI and pi): for any other agent nothing separates "ready" from a trust or permission dialog, and the Enter that submits a prompt would answer the dialog's default with nobody there to read it. `hwip schedule add … --prompt` refuses those agents and says which ones work; a schedule without `--prompt` starts any agent. The rules that decide this are the ones shipped in the `hwip` package, not the detection rules the listener updates over the air: a phone's input is typed by someone who has seen the screen, a schedule by nobody, and a rule set that arrives over the air is not signed — it must not be able to call a dialog `idle` and have your prompt and Enter typed into it.
 - **The cap**: a session that runs longer than `--max-runtime` is asked to end the way the phone's *end session* does — the agent's own quit command, then signals. It is never killed; one that stays keeps the schedule from starting its next run (`overlap`).
 - **The phone is told** with one push per listener tick, listing each schedule with how many times and why (`<label> · 놓침 31회` — the push is in Korean). A run skipped because the last one is still going counts once until the result changes; a push that does not go out is tried again after 30 seconds, then 1, 2, 4 … minutes up to 30 (only a refusal by the server, such as the daily limit, is not tried again; a timeout, a proxy or a captive portal in the way is), and is dropped after 24 hours. The push has one title per kind of news — skipped or missed, over its runtime, or a prompt not typed — and a general one when a push holds several kinds. The prompt is never in it. A free account sends at most 100 pushes a day (`pushPerDay`), which is why these are batched.
-- **State** is files under `~/.local/state/hwip`: one `schedules/<id>.json` per schedule (limit 20) and `schedule-state.json`, written only by the listener, with where each schedule has got to.
-- **From the phone**: the app lists the schedules of a computer, makes one for a session this computer has run, and removes one. It names the session, a time and what to do; the directory, the agent's command and its arguments are never the phone's (see *Defense*). A schedule made there needs an agent that can take a prompt, and shows in `hwip schedule` like any other.
+- **Editing**: `hwip schedule edit <id>` changes the time (`--at`, `--days`, `--every`), `--prompt` and `--max-runtime` of a schedule in place; the id, the session, the directory and the agent stay. What a flag does not name is kept — `--at` keeps the days, `--days` the time. A changed time counts from the edit: the times before it are neither started nor counted as missed, and an `--every` schedule runs one period after the edit; changing only the prompt or the run time keeps the schedule on its times. A session already running keeps going. A listener of an older build is restarted first, because it would skip the edited file as unreadable; when it cannot be replaced, a new time is not written (exit 1) and the schedule keeps running as it was.
+- **State** is files under `~/.local/state/hwip`: one `schedules/<id>.json` per schedule (limit 20) and `schedule-state.json`, written only by the listener, with where each schedule has got to. `agent-dirs.json` holds the directories `hwip <agent>` typed in a shell found its agent in: a listener run as a login service has only the PATH its service file baked, so a scheduled launch adds these to it — run an agent from a shell once (`hwip cc`) before scheduling it, or the run is skipped with `'claude' not found on PATH` in `~/.hwip/listener.log`.
+- **From the phone**: the app lists the schedules of a computer, makes one for a session this computer has run, edits one, and removes one. It names the session, a time and what to do; the directory, the agent's command and its arguments are never the phone's (see *Defense*). A schedule made there needs an agent that can take a prompt, and shows in `hwip schedule` like any other.
 
 ### Session history
 
@@ -832,7 +839,7 @@ The phone also reads this machine's schedules (see [Scheduled sessions](#schedul
 { subtype: 'agent.schedule.list.result',  requestId, at, schedules | encrypted | error }
 ```
 
-`schedules` is the list as a JSON string; `encrypted` is the list sealed for the asking device (purpose `schedule.list`, bound to this machine's device id) as `{ v: 1, requestId, at, schedules: [...], unreadable? }` — the app checks that the `requestId` inside is the one it asked, so an older sealed list is not taken for a newer answer. `unreadable` is how many schedule files could not be read; a directory that cannot be listed at all, or that holds more than 20 files, is the error `read_failed`, never an empty list (and a remove then fails as `schedule_failed`; `hwip schedule rm` still works on the computer). A list too long for one frame has its prompts shortened, step by step (`too_large` only when it does not fit even without them). Each entry holds `id`, `source`, `agentKind`, `project` (the directory's name, not its path), `session`, `when`, `prompt` (cut to 500 characters, shorter when the list would not fit), `maxRuntimeMin`, `nextAt` and the `last` result — never a directory path or the agent's arguments.
+`schedules` is the list as a JSON string; `encrypted` is the list sealed for the asking device (purpose `schedule.list`, bound to this machine's device id) as `{ v: 1, requestId, at, schedules: [...], unreadable? }` — the app checks that the `requestId` inside is the one it asked, so an older sealed list is not taken for a newer answer. `unreadable` is how many schedule files could not be read; a directory that cannot be listed at all, or that holds more than 20 files, is the error `read_failed`, never an empty list (and a remove then fails as `schedule_failed`; `hwip schedule rm` still works on the computer). A list too long for one frame has its prompts shortened, step by step (`too_large` only when it does not fit even without them). Each entry holds `id`, `source`, `agentKind`, `project` (the directory's name, not its path), `session`, `when`, `prompt` (cut to 500 characters, shorter when the list would not fit; `promptLocked: true` says the phone cannot change it — it is not the whole text, or the schedule has agent arguments — so the app leaves it to `hwip schedule edit`), `maxRuntimeMin`, `nextAt` and the `last` result — never a directory path or the agent's arguments.
 
 ### Your API key and redirects
 
@@ -972,7 +979,12 @@ handing the listener a key:
   session name, its `seq`/`epoch` and that nonce, so a relay that cannot
   swap in a key of its own (below) can't move one to another stream,
   replay one from an earlier subscription, or hand one back as input —
-  or as anything else this listener sealed for the phone. Your
+  or as anything else this listener sealed for the phone. A history page
+  (scrolling up past the live window) holds the same nonce and `epoch`,
+  the request id it answers and where it sits in the scrollback, so a
+  relay can't hand an earlier page back under a new request or move
+  where the next one is asked for; only the request id rides beside it
+  in the clear. Your
   keystrokes are sealed for this listener as `stream.input` with their
   `seq`/`epoch` stamps, the stream's start epoch and the phone's device
   id inside, so a forged restart can't replay them. The start answer (`agent.stream.start.ok`)
@@ -1188,7 +1200,7 @@ device, takes plain commands as before; an unreadable
 forgets the pins, and with them goes back to taking plain commands until a
 device is pinned again.
 
-**A schedule request** — the phone making or removing a scheduled session — rides
+**A schedule request** — the phone making, changing or removing a scheduled session — rides
 the same `agent.command` push, with a `schedule` field and no `body`. It carries
 a time, a prompt and, if the phone says so, an agent and a run time — and nothing
 else. The directory and the agent come from what this machine recorded for the
@@ -1197,8 +1209,11 @@ schedule at another directory; it cannot send agent arguments, a worktree or a
 label either, and a request that carries one is refused rather than ignored
 (`schedule_invalid`; `schedule_limit` at 20 schedules; `unknown_session` for a
 session this machine never recorded; `schedule_failed` when this machine's own
-files would not read or write). A remove names the schedule's own
-session, so it cannot reach another. Applying a request never types into a
+files would not read or write). A change (`op: 'update'`) carries the schedule's id
+and any of the time, the prompt and the run time; what it leaves out stays as it was,
+and a change with none of them is refused. A schedule made on the computer with agent arguments keeps its prompt: the phone may change its time and run time, not what is typed under those arguments. A change and a remove name the schedule's own
+session, so they cannot reach another. A listener of an older build refuses a change as
+`schedule_invalid`. Applying a request never types into a
 session. The request is sealed like any
 command — the whole of it inside the body, only `op` beside it, and the sender,
 label and counter checks above apply, so a replay or a swapped `op` changes

package/dist/agent-dirs.d.ts

@@ -0,0 +1,15 @@
+/**
+ * Where the person's own shell finds their agents (F8). A schedule is started by the listener, and the listener run by
+ * launchd or systemd has only the PATH its service file baked: tmux's and node's directories and the system ones. An
+ * agent installed anywhere else — `~/.local/bin/claude` — is not on it, and the scheduled session's pane dies at once
+ * with "command not found". So every `hwip <agent>` typed in a shell writes down the directory its agent was found in,
+ * and a schedule launch adds those directories to its PATH.
+ *
+ * Builtins only: wrapper.ts writes this on the `hwip cc` hot path.
+ */
+export declare const agentDirsPath: () => string;
+/** Writes down the directory of `binary`, an absolute path the shell resolved. Best-effort: a launch never fails on it. */
+export declare const rememberAgentDir: (binary: string) => void;
+/** `path` with every written-down directory it lacks appended: what the listener has first, so nothing it runs changes. */
+export declare const withAgentDirs: (path: string | undefined) => string;
+//# sourceMappingURL=agent-dirs.d.ts.map

package/dist/agent-dirs.js

@@ -0,0 +1,76 @@
+"use strict";
+/**
+ * Where the person's own shell finds their agents (F8). A schedule is started by the listener, and the listener run by
+ * launchd or systemd has only the PATH its service file baked: tmux's and node's directories and the system ones. An
+ * agent installed anywhere else — `~/.local/bin/claude` — is not on it, and the scheduled session's pane dies at once
+ * with "command not found". So every `hwip <agent>` typed in a shell writes down the directory its agent was found in,
+ * and a schedule launch adds those directories to its PATH.
+ *
+ * Builtins only: wrapper.ts writes this on the `hwip cc` hot path.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.withAgentDirs = exports.rememberAgentDir = exports.agentDirsPath = void 0;
+const node_fs_1 = require("node:fs");
+const node_path_1 = require("node:path");
+const gate_js_1 = require("./gate.js");
+const private_files_js_1 = require("./private-files.js");
+/** More than anyone has agents in; bounds what a schedule launch puts on PATH. */
+const MAX_DIRS = 16;
+const agentDirsPath = () => (0, node_path_1.join)((0, gate_js_1.stateDir)(), 'agent-dirs.json');
+exports.agentDirsPath = agentDirsPath;
+/**
+ * Whether the file is the user's own regular file that only they can write: a directory put on PATH by someone else runs
+ * their programs as the agent. 'missing' when there is none yet.
+ */
+const fileState = (path) => {
+    try {
+        const info = (0, node_fs_1.lstatSync)(path);
+        const mine = typeof process.getuid !== 'function' || info.uid === process.getuid();
+        return info.isFile() && mine && (info.mode & 0o022) === 0 ? 'ok' : 'refused';
+    }
+    catch {
+        return 'missing';
+    }
+};
+const readDirs = () => {
+    try {
+        const path = (0, exports.agentDirsPath)();
+        if (fileState(path) !== 'ok')
+            return [];
+        const parsed = JSON.parse((0, node_fs_1.readFileSync)(path, 'utf-8'));
+        if (!Array.isArray(parsed))
+            return [];
+        return parsed.filter((dir) => typeof dir === 'string' && (0, node_path_1.isAbsolute)(dir)).slice(0, MAX_DIRS);
+    }
+    catch {
+        return [];
+    }
+};
+/** Writes down the directory of `binary`, an absolute path the shell resolved. Best-effort: a launch never fails on it. */
+const rememberAgentDir = (binary) => {
+    if (!(0, node_path_1.isAbsolute)(binary))
+        return;
+    const dir = (0, node_path_1.dirname)(binary);
+    const path = (0, exports.agentDirsPath)();
+    // Never written through a link, nor into a file that is not read back: either would be writing for nothing, or elsewhere.
+    if (fileState(path) === 'refused')
+        return;
+    const dirs = readDirs();
+    if (dirs.includes(dir))
+        return;
+    try {
+        (0, private_files_js_1.mkdirHandedBack)((0, gate_js_1.stateDir)(), 0o700);
+        (0, node_fs_1.writeFileSync)(path, JSON.stringify([...dirs, dir].slice(-MAX_DIRS)), { mode: 0o600 });
+        (0, private_files_js_1.handBackToSudoUser)(path);
+    }
+    catch {
+        // The schedule launch then says the agent is not on PATH, which is the truth.
+    }
+};
+exports.rememberAgentDir = rememberAgentDir;
+/** `path` with every written-down directory it lacks appended: what the listener has first, so nothing it runs changes. */
+const withAgentDirs = (path) => {
+    const have = (path ?? '').split(node_path_1.delimiter).filter(Boolean);
+    return [...have, ...readDirs().filter((dir) => !have.includes(dir))].join(node_path_1.delimiter);
+};
+exports.withAgentDirs = withAgentDirs;

package/dist/agent-rules.default.d.ts

@@ -18,7 +18,7 @@
  *   still be working underneath, so it must not change the state.
  *
  * Every agent here carries the same rules the server manifest publishes
- * (hwip server/src/agent-rules/manifest.json, version 2026.10.18.1 — hwip#532, merged and deployed before this cli ships),
+ * (hwip server/src/agent-rules/manifest.json, version 2026.10.21.1 — hwip#616, merged and deployed before this cli ships),
  * so a listener that never reaches the endpoint classifies them too. A fetched
  * manifest replaces this bundle whole for state reports; schedules read only
  * this bundle. An agent without rules here

package/dist/agent-rules.default.js

@@ -21,7 +21,7 @@ exports.DEFAULT_MANIFEST = void 0;
  *   still be working underneath, so it must not change the state.
  *
  * Every agent here carries the same rules the server manifest publishes
- * (hwip server/src/agent-rules/manifest.json, version 2026.10.18.1 — hwip#532, merged and deployed before this cli ships),
+ * (hwip server/src/agent-rules/manifest.json, version 2026.10.21.1 — hwip#616, merged and deployed before this cli ships),
  * so a listener that never reaches the endpoint classifies them too. A fetched
  * manifest replaces this bundle whole for state reports; schedules read only
  * this bundle. An agent without rules here
@@ -31,7 +31,7 @@ exports.DEFAULT_MANIFEST = void 0;
 const agent_state_js_1 = require("./agent-state.js");
 exports.DEFAULT_MANIFEST = {
     engineVersion: agent_state_js_1.ENGINE_VERSION,
-    version: '2026.10.18.1',
+    version: '2026.10.21.1',
     agents: {
         claude: [
             {
@@ -237,8 +237,8 @@ exports.DEFAULT_MANIFEST = {
             // guarded by any button or footer string so the phrase in tool
             // output or agent text alone is not a dialog. tailLines 30
             // because an edit request draws its diff between that line and
-            // the buttons. Other prompts (the agent asking a question) are
-            // not captured and report `unknown`.
+            // the buttons. Other prompts (anything but a permission request or
+            // the question tool, below) are not read and report `unknown`.
             // No idle rule: at rest the footer is only `ctrl+p commands`,
             // which says nothing the absence of `esc interrupt` does not.
             {
@@ -253,6 +253,17 @@ exports.DEFAULT_MANIFEST = {
                     { contains: ['enter confirm'] },
                 ],
             },
+            {
+                // The question tool's panel (captured on opencode 2.1.2).
+                // tailLines 40: answers carry notes. `esc interrupt` means a
+                // turn still running, so these words in agent text do not count.
+                id: 'opencode-blocked-question',
+                state: 'blocked',
+                priority: 900,
+                tailLines: 40,
+                contains: ['questions', 'enter submit', 'esc dismiss'],
+                not: [{ contains: ['esc interrupt'] }],
+            },
             {
                 id: 'opencode-working-interrupt-hint',
                 state: 'working',

package/dist/blocked-prompt.js

@@ -42,10 +42,13 @@ exports.promptPlaintext = exports.showsPrompt = exports.parseBlockedDialog = exp
  * numbered answers. No footer.
  *
  * pi has no approval dialog of its own; extensions that gate tools ask through
- * `ctx.ui.select` (`parsePiSelect`, `blocked-prompt-pi.test.ts`).
+ * `ctx.ui.select` (`parsePiSelect`, `blocked-prompt-pi.test.ts`). The `ask_user_question` extension draws its own
+ * picker (`parsePiQuestion`).
  *
  * OpenCode (v2.0.29, `blocked-prompt-opencode.test.ts`): a `┃` panel, `△ Permission required`, the request, and a
- * row of buttons whose chosen one is told apart by background colour only (`parseOpencodePermission`).
+ * row of buttons whose chosen one is told apart by background colour only (`parseOpencodePermission`). Its question
+ * tool (v2.1.2) draws a `Questions` panel whose highlighted answer differs by the colour of its number
+ * (`parseOpencodeQuestion`).
  */
 const node_crypto_1 = require("node:crypto");
 /** Dialog titles whose layout was captured and is read. */
@@ -334,14 +337,91 @@ const parsePiSelect = (pane) => {
         options,
     });
 };
+/** A line indented under an answer, as both question pickers draw a note. */
+const QUESTION_NOTE = /^ {5}(\S.*)$/;
+const appendNote = (option, text) => {
+    option.note = option.note === undefined ? text.trim() : `${option.note} ${text.trim()}`;
+};
+const PI_QUESTION_FOOTER = /^ ↑↓ navigate • Enter select • Esc cancel$/;
+const PI_QUESTION_OPTION = /^(> | {2})(?:(\d{1,2})\. )?(\S.*)$/;
+/**
+ * The `ask_user_question` extension's single-answer picker (pi 0.85.1, `pi-blocked.txt`): a full-width rule, the
+ * question, an optional context, numbered answers with `> ` on the highlighted one and an indented note under any,
+ * an unnumbered last answer that opens a text field (left out: keys cannot fill it), then the
+ * `↑↓ navigate • Enter select • Esc cancel` footer and a closing rule.
+ */
+const parsePiQuestion = (pane) => {
+    const lines = pane.split('\n').map((l) => l.trimEnd());
+    let footer = -1;
+    for (let i = lines.length - 1; i >= 0 && footer < 0; i--)
+        if (PI_QUESTION_FOOTER.test(lines[i]))
+            footer = i;
+    if (footer < 0 || !FULL_RULE.test(lines[footer + 1] ?? ''))
+        return undefined;
+    let top = -1;
+    for (let i = footer - 1; i >= 0 && top < 0; i--)
+        if (FULL_RULE.test(lines[i]))
+            top = i;
+    if (top < 0)
+        return undefined;
+    // The picker takes the editor's place, so one rule follows it; the same text in the agent's output sits above
+    // the editor and its two rules.
+    if (lines.slice(footer + 1).filter((l) => FULL_RULE.test(l)).length > 1)
+        return undefined;
+    // Answers run up to the footer's gap; the question and context sit above the first one's gap.
+    let first = top + 1;
+    while (first < footer && !/^(> | {2})1\. /.test(lines[first]))
+        first++;
+    if (first >= footer || lines[first - 1] !== '')
+        return undefined;
+    const options = [];
+    let own;
+    for (const line of lines.slice(first, footer)) {
+        if (line === '')
+            continue;
+        const note = QUESTION_NOTE.exec(line);
+        if (note && options.length > 0) {
+            appendNote(options[options.length - 1], note[1]);
+            continue;
+        }
+        const m = PI_QUESTION_OPTION.exec(line);
+        if (!m || own !== undefined)
+            return undefined;
+        const n = m[2] === undefined ? options.length + 1 : Number(m[2]);
+        if (m[2] === undefined)
+            own = n;
+        options.push({ n, label: m[3].trim(), selected: m[1] === '> ' });
+    }
+    if (own === undefined)
+        return undefined;
+    const text = lines.slice(top + 1, first).map((l) => l.replace(/^ /, ''));
+    const gap = text.indexOf('');
+    const asked = (gap < 0 ? text : text.slice(0, gap)).join(' ').trim();
+    if (asked === '')
+        return undefined;
+    const context = gap < 0 ? [] : trimBlank(text.slice(gap + 1)).map((l) => l.trim()).filter((l) => l !== '');
+    const prompt = assemble({
+        region: lines.slice(top, footer + 1),
+        title: asked,
+        detail: [...context, ...options.filter((o) => o.note !== undefined && o.n !== own).map((o) => `${o.label}: ${o.note}`)],
+        question: asked,
+        options,
+    });
+    return prompt && { ...prompt, options: prompt.options.filter((o) => o.n !== own) };
+};
 // One SGR sequence and its parameters; any other escape is dropped without changing the background.
 const SGR = /^\u001b\[([0-9;:]*)m/;
 const ANY_ESCAPE = new RegExp(`^(?:${ESCAPES.source})`);
-/** `line` without escapes, and the background each of its UTF-16 units is drawn on ('7' = reverse video). */
-const withBackground = (line) => {
+/**
+ * `line` without escapes, and the background ('7' = reverse video) and foreground each of its UTF-16 units is drawn
+ * in ('' = the default).
+ */
+const withColours = (line) => {
     let text = '';
     const bg = [];
+    const fg = [];
     let current = '';
+    let ink = '';
     let reverse = false;
     for (let i = 0; i < line.length;) {
         const sgr = SGR.exec(line.slice(i));
@@ -351,6 +431,7 @@ const withBackground = (line) => {
                 const code = Number(p[j]);
                 if (code === 0) {
                     current = '';
+                    ink = '';
                     reverse = false;
                 }
                 else if (code === 7)
@@ -359,12 +440,18 @@ const withBackground = (line) => {
                     reverse = false;
                 else if (code === 49)
                     current = '';
+                else if (code === 39)
+                    ink = '';
                 else if ((code >= 40 && code <= 47) || (code >= 100 && code <= 107))
                     current = String(code);
+                else if ((code >= 30 && code <= 37) || (code >= 90 && code <= 97))
+                    ink = String(code);
                 else if (code === 38 || code === 48 || code === 58) {
                     const span = p[j + 1] === '2' ? 3 : p[j + 1] === '5' ? 1 : 0;
                     if (code === 48)
                         current = p.slice(j, j + 2 + span).join(';');
+                    if (code === 38)
+                        ink = p.slice(j, j + 2 + span).join(';');
                     j += 1 + span;
                 }
             }
@@ -378,27 +465,27 @@ const withBackground = (line) => {
         }
         text += line[i];
         bg.push(reverse ? '7' : current);
+        fg.push(ink);
         i++;
     }
-    return { text, bg };
+    return { text, bg, fg };
 };
 const OPENCODE_BAR = '┃';
 const OPENCODE_HEADER = /^\s*△ Permission required$/;
 const OPENCODE_HINTS = /ctrl\+|⇆|enter confirm/;
 const OPENCODE_SUBTITLE = /^→ (\S.*)$/;
+/** The column after the panel bar on a row drawn in the panel; -1 for any other row. */
+const inPanel = (row) => {
+    const at = row.text.indexOf(OPENCODE_BAR);
+    return at >= 0 && row.text.slice(0, at).trim() === '' ? at + 1 : -1;
+};
 /**
  * OpenCode's permission request: `△ Permission required` in a `┃` panel, the request (a `$ command`, or `→ Edit file`
  * over its diff), then a row of buttons `Allow once   Always allow   Reject` beside `… enter confirm`. The chosen
  * button differs from the others only by its background, so this reads the pane with its escapes: a plain capture
  * yields nothing. Left/right move the choice; the dialog draws no question, so the question is a fixed one.
  */
-const parseOpencodePermission = (pane) => {
-    const rows = pane.split('\n').map(withBackground);
-    // Text after the panel bar, with the bar's column, for every row drawn in the panel.
-    const inPanel = (row) => {
-        const at = row.text.indexOf(OPENCODE_BAR);
-        return at >= 0 && row.text.slice(0, at).trim() === '' ? at + 1 : -1;
-    };
+const parseOpencodePermission = (rows) => {
     let head = -1;
     for (let i = rows.length - 1; i >= 0 && head < 0; i--) {
         const at = inPanel(rows[i]);
@@ -453,6 +540,71 @@ const parseOpencodePermission = (pane) => {
         idSalt: `opencode:selected=${selected}`,
     });
 };
+const OPENCODE_QUESTION_HEADER = /^\s*Questions$/;
+/** The one footer captured: a single question, single answer. Several questions add `tab`, several answers a toggle. */
+const OPENCODE_QUESTION_FOOTER = /^\s*↑↓ select {2}enter submit {2}esc dismiss$/;
+const OPENCODE_QUESTION_OPTION = /^ {2}(\d{1,2})\. (\S.*)$/;
+/** The answer OpenCode adds to every question: it opens a text field, which keys cannot fill. */
+const OPENCODE_OWN_ANSWER = 'Type your own answer';
+/**
+ * OpenCode's question tool (v2.1.2): `Questions` in a `┃` panel, the question, numbered answers each over an
+ * optional indented note, and a `↑↓ select  enter submit  esc dismiss` footer. The highlighted answer differs only by
+ * the colour of its number, so this too reads the pane with its escapes. Up/down move the highlight.
+ */
+const parseOpencodeQuestion = (rows) => {
+    const textOf = (i) => rows[i].text.slice(inPanel(rows[i])).trimEnd();
+    let footer = -1;
+    for (let i = rows.length - 1; i >= 0 && footer < 0; i--) {
+        if (inPanel(rows[i]) >= 0 && OPENCODE_QUESTION_FOOTER.test(textOf(i)))
+            footer = i;
+    }
+    if (footer < 0)
+        return undefined;
+    let head = footer - 1;
+    while (head >= 0 && inPanel(rows[head]) >= 0 && !OPENCODE_QUESTION_HEADER.test(textOf(head)))
+        head--;
+    if (head < 0 || inPanel(rows[head]) < 0)
+        return undefined;
+    const question = [];
+    const options = [];
+    const numberInk = [];
+    for (let i = head + 1; i < footer; i++) {
+        const text = textOf(i);
+        const option = OPENCODE_QUESTION_OPTION.exec(text);
+        if (option) {
+            options.push({ n: Number(option[1]), label: option[2].trim(), selected: false });
+            numberInk.push(rows[i].fg[inPanel(rows[i]) + 2]);
+            continue;
+        }
+        const note = QUESTION_NOTE.exec(text);
+        if (options.length > 0 && note) {
+            appendNote(options[options.length - 1], note[1]);
+        }
+        else if (options.length > 0 && text.trim() !== '') {
+            return undefined;
+        }
+        else if (options.length === 0) {
+            question.push(text.trim());
+        }
+    }
+    // The highlighted answer: the one number ink no other answer shares, the rest all alike.
+    const odd = numberInk.filter((ink) => numberInk.filter((other) => other === ink).length === 1);
+    if (odd.length !== 1 || new Set(numberInk).size !== 2)
+        return undefined;
+    options[numberInk.indexOf(odd[0])].selected = true;
+    const asked = trimBlank(question).join(' ').trim();
+    if (asked === '')
+        return undefined;
+    const prompt = assemble({
+        region: rows.slice(head, footer + 1).map((r) => r.text.trimEnd()),
+        title: 'Question',
+        detail: options.filter((o) => o.note !== undefined && o.label !== OPENCODE_OWN_ANSWER).map((o) => `${o.label}: ${o.note}`),
+        question: asked,
+        options,
+        idSalt: `opencode-question:selected=${options.findIndex((o) => o.selected)}`,
+    });
+    return prompt && { ...prompt, options: prompt.options.filter((o) => o.label !== OPENCODE_OWN_ANSWER) };
+};
 /** The checks and caps every reader shares: numbering 1..n, one highlight, label and detail limits. */
 const assemble = (d) => {
     const { options } = d;
@@ -489,8 +641,14 @@ const assemble = (d) => {
 const READERS = {
     claude: (pane) => parseClaudeDialog((0, exports.stripEscapes)(pane)),
     gemini: (pane) => parseGeminiDialog((0, exports.stripEscapes)(pane)),
-    pi: (pane) => parsePiSelect((0, exports.stripEscapes)(pane)),
-    opencode: parseOpencodePermission,
+    pi: (pane) => {
+        const plain = (0, exports.stripEscapes)(pane);
+        return parsePiSelect(plain) ?? parsePiQuestion(plain);
+    },
+    opencode: (pane) => {
+        const rows = pane.split('\n').map(withColours);
+        return parseOpencodePermission(rows) ?? parseOpencodeQuestion(rows);
+    },
 };
 /** The approval dialog at the bottom of `pane`, read the way `kind` draws it; undefined when it is not one of those. */
 const parseBlockedDialog = (pane, kind) => READERS[kind]?.(pane);

package/dist/listener.d.ts

@@ -229,6 +229,11 @@ export interface ReportedKnownSession {
     lastSeq?: number;
     /** The later tmux sessions the run went on in (Q35): the server ends another run's push window at their start. */
     tmuxRunIds?: string[];
+    /** The last name the agent gave the run, and who gave it (hwip docs/session-runs.md Q39): what the phone calls it once ended. */
+    providerSessionName?: string;
+    providerSessionNameSource?: ProviderNameSource;
+    /** Whether starting the run again picks its conversation back up (Q43) — never the conversation id itself. */
+    resumable: boolean;
     lastSeenAt: string;
 }
 /** Each live run's first seq, for the report (Q24). A run that has recorded nothing yet has none. */
@@ -502,6 +507,13 @@ export interface SessionResumeRequest {
      * the same answer a phone too old to send it gets.
      */
     agentKind?: string;
+    /**
+     * Which run of that name and agent (docs/session-runs.md Q41–Q46): the
+     * earlier-runs fold starts one conversation, not the newest. Selects among
+     * runs this machine recorded; one it never had is refused. Read only when
+     * it reads as a run id.
+     */
+    runId?: string;
     requestId?: string;
 }
 export interface SessionResumeResult {
@@ -640,6 +652,27 @@ export interface ScreenHistorySnapshot {
     error?: string;
     capturedAt: string;
 }
+/**
+ * What a sealed history page's envelope holds (as JSON): the page and every
+ * number a viewer pages by, bound to the request it answers and to the
+ * subscription it was sealed for. On a sealed stream the snapshot carries
+ * only `requestId` (for routing) beside this — a relay that hands an earlier
+ * page back under a new request, or rewrites where it sits, is caught on open.
+ */
+export type SealedHistoryPage = {
+    sessionName: string;
+    requestId: string;
+    nonce?: string;
+    epoch: number;
+    before: number;
+    lines: number;
+    hasMore: boolean;
+    truncated: boolean;
+    /** The pane's history size when this page was captured, so the viewer can
+     *  tell how much the history grew between its request and the capture. */
+    historySize: number;
+    content: string;
+};
 /**
  * Answer a phone's request for one page of scrollback above the live window.
  * Returns true when the message was ours to answer, so the caller stops routing