severally-mcp 2.0.0 → 2.3.1

package/plugins/severally/skills/codex/severally/reference.md

@@ -17,9 +17,8 @@ checked as given: the server rejects a first-round `explore` that carries a prop
 anchoring-sensitive — if you want your plan critiqued, that is `review`.
 
 **For a decision heavy enough to be worth two consultations**, ask `explore` first on the facts alone, then
-`review` with the proposal, and read what the first raised that the second never did. Measured on this
-project: repeat runs of the identical brief did not move the bottom line, while withholding the proposal once
-did, and the withheld run was the only one to question what the decision was even about.
+`review` with the proposal, and read what the first raised that the second never did. A consultant that sees
+your proposal tends to answer around it; one that does not is more likely to question the framing itself.
 
 ## A brief for a decision you will live with
 
@@ -70,10 +69,14 @@ names. Your own CLI is a fresh session but not another lineage, and its `quality
 consultants of one vendor.
 
 Send **one** `targets` call: every consultant receives the byte-identical brief, which is what makes the answers
-comparable. Poll the single group with `consult_get({ group_id })` and stop it with
-`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap (nine by default, shared by
-every severally session on this machine) and one consultation's quota per consultant, and `targets` is refused
-on a follow-up.
+comparable (on a follow-up to the group, the same new question, with each one's own earlier rounds). Poll the single group with `consult_get({ group_id })` and stop it with
+`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap per consultant (nine by default,
+shared by every severally session on this machine; the group starts only if every member gets one) and one
+consultation's quota per consultant. To ask every member again, follow up the group: `followup_to: "<group_id>"`
+with no `target` or `targets` (see Follow-ups).
+
+While you wait, `consult_get` blocks for up to its limit (ten minutes where the client allows it). To work on
+something independent in between, pass a shorter `wait_ms` and come back.
 
 `comparison.by_target` holds, per consultant: stance, summary, confidence, evidence basis, finding points (each
 with its `id` and severity), `severity_counts`, `decision_changers`, alternatives, unknowns (`u1` …),
@@ -93,7 +96,7 @@ Reading them against each other:
 4. **Read `decision_changers` before spending a follow-up**: a consultant that named the condition under which
    it would change its mind has told you what evidence to go get.
 5. **Spend a follow-up only on a divergence that would change your decision**, sent only to the consultant
-   whose reading it belongs to.
+   whose reading it belongs to, or to the whole group (`followup_to: "<group_id>"`) when it concerns all of them.
 6. **A stance every consultant shares is not evidence that the plan was checked.** Look for a premise they all
    rely on and none could verify; name it only if you can actually identify one.
 
@@ -123,14 +126,23 @@ in `failure.detail`, which tells you whether to retry with a longer budget or a
 
 By default a chain has five rounds: one initial round plus up to four follow-ups
 (`followup_to: "<previous job_id>"`); the operator can configure 1–20 (`server.max_rounds`), and
-`rounds_remaining` says what is left. A follow-up starts in a fresh working directory with no files: pass
+`rounds_remaining` says what is left. `followup_to: "<group_id>"`, with no `target` or `targets`, sends the same new
+question to every member of a fan-out, each continuing from its own latest round with its own history; a member
+that is still running, never answered or has used its rounds is listed under `skipped` and not asked.
+
+A follow-up needs only `followup_to` and the new `question`:
+`consult_start({ request: { followup_to: "<job_id>", question: "..." } })`. The consultant, the mode, `network` and what
+the earlier round was given (objective, constraints, success criteria, facts, proposal, counterpoints,
+artifacts) carry over, and the brief restates them; a field you pass replaces the earlier one, an empty list
+included. A follow-up starts in a fresh working directory with no files: pass
 `context.expose_from_parent: true` to copy again, as they are now, the paths the earlier round exposed (a changed
 or vanished entry is marked), and leave it off when the follow-up does not need them.
 
 Spend follow-ups only where you and the consultant actually diverge: quote the specific point, give the evidence
 that answers it, and ask what would change their view. Write your verdicts with `consult_record` first: the
 consultant is shown each earlier point with your verdict, so it answers what your checking found instead of
-restating it. A follow-up works across a server restart.
+restating it. A follow-up works across a server restart; `consult_list` shows an earlier session's
+consultations with their `job_id` and `group_id`.
 
 After each follow-up, state in one sentence the cause you still differ on. If it is the same as last round and
 the round brought no new evidence and no new condition that would change the judgement, stop and hand the user

package/plugins/severally/skills/opencode/severally/SKILL.md

@@ -5,9 +5,9 @@ description: Use when a decision deserves a second, independent mind - an archit
 
 # Consulting a peer agent
 
-You have three peers, each reached through the `severally` MCP server as a fresh child session. They can
-search and browse the web. They cannot edit files, reach the network outside search/browse, load MCP tools,
-see your session, or consult anyone else. In practice they know only what you put in the brief and the files you expose to them.
+You have three peers, each reached through the `severally` MCP server as a fresh child session that can read files
+and search the web, but not edit them, load MCP tools, see your session or consult anyone else. Each knows only
+what you put in the brief and the files you expose to it.
 
 One caveat on that list: a consultant can read local files. Its writes are blocked,
 its network reaches only web search and browsing (none with `network: "off"`), credential and history
@@ -29,13 +29,14 @@ copied read-only into its working directory. The Codex consultant additionally h
    }})
    ```
 
-2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits up to 45 seconds for
-   the answer by itself; call it again while `status` is `running`, and work on something independent in between.
+2. **`consult_get({ group_id })`** (`consult_get({ job_id })` for one consultant). It waits for the answer by itself,
+   up to a limit the server sets (45 seconds, or ten minutes where the client allows it); call it again while
+   `status` is `running`. To work on something independent meanwhile, ask for a shorter wait (`reference.md`).
 3. **Check one point, report, and record it once** (see **Before you hand the decision back**).
 
-That is the whole routine. The rest of the record — more verdicts, a prediction and reflection, follow-ups,
-the export into the repository, the details of reading a fan-out — is in `reference.md`, in the same
-directory as this file. Read it only for a decision you will have to justify later, or when you follow up.
+That is the whole routine. The rest — follow-ups, a prediction and reflection, the export, reading a fan-out
+in detail — is in `reference.md`, in the same directory as this file. Read it for a decision you will have to
+justify later, or when you follow up.
 
 ## Pick the consultant
 
@@ -53,12 +54,10 @@ costs one consultation's quota per consultant. Narrow to `target` (singular) onl
 specific peer, or when the decision clearly does not warrant that much. This is the one rule for how many to
 ask.
 
-A consultant is one CLI running one model, and the operator decides which ones exist. `consult_start`'s
-description lists the ones this machine can actually reach as `name: CLI, model`. When the user names one,
-pass **the word the user used** as `target` — a name, a CLI (`codex`, `agy`), a vendor or a model
-(「Claude Opusと相談して」 is `target: "claude opus"`) — and let the server resolve it. A word that fits several
-comes back as `target_ambiguous` with the candidates: ask the user which one they meant. One that is not
-installed comes back as `target_unavailable` with the available list: take that as final and tell the user.
+The operator decides which consultants exist; `consult_start`'s description lists the ones this machine can
+actually reach. When the user names one, pass **the word the user used** as `target`
+(「Claude Opusと相談して」 is `target: "claude opus"`). `target_ambiguous`: ask the user which one they meant.
+`target_unavailable`: take the available list as final and tell the user.
 
 **Do not pick a model yourself.** When the user named no one, ask everyone; overriding the operator's
 consultants on your own judgement — including after a `usage_limit` failure — substitutes a different mind
@@ -72,9 +71,8 @@ answer can say which model answered.
 
 ## When this is worth it
 
-When a wrong answer is expensive or hard to undo: an architectural or interface decision, a data migration, a
-security or concurrency design; two options that still look close; an investigation that has stalled after two
-failed attempts; or the user asked. Not for routine edits, a rename, a test that just needs writing, or
+When a wrong answer is expensive or hard to undo (an interface, a migration, a security or concurrency design),
+two options still look close, an investigation has stalled after two attempts, or the user asked. Not for
 anything you would be comfortable defending on your own.
 
 **Before you ask the user to approve a change that is hard to reverse** and nobody else has reviewed it,
@@ -91,15 +89,13 @@ Pass `initiator: "user"` when the user asked for the consultation; leave it out
 - **Ask one decidable question.** What runs out the clock is scope, not brief length: when the budget runs out
   the session is killed and you get nothing. Split "research everything about X" or three questions at once,
   and ask the one whose answer changes what you do next.
-- **Hand over the code.** The consultant starts in an empty working directory and is not told where your
-  repository is. Name the files by absolute path in `context.expose_paths` in this first call (at most 20
-  entries, 500 files, 5 MB; never your home directory or one holding keys), or pass
+- **Hand over the code.** The consultant is not told where your repository is. Name the files by absolute path
+  in `context.expose_paths` (a repository root works; never your home directory or one holding keys), or pass
   `context.expose_diff: { repo: "<absolute path>" }` for a change you are making. When `consult_start` answers
   `files_exposed: 0` and the question is about code, `consult_cancel` and start again with `expose_paths`.
 - **Put the load-bearing facts in `context.facts`**, and test output or a log in `context.artifacts`.
-- **The mode follows from the context.** Leave `mode` out: no proposal is `explore`, a proposal is `review`, a
-  proposal with `counterpoints` (the other side's claims) is `debate`. To gather opinions without showing your
-  own, leave `context.proposal` empty; a reviewed plan is answered around the plan.
+- **Leave `mode` out**; it follows from the context. To gather opinions without showing your own, leave
+  `context.proposal` empty: a reviewed plan is answered around the plan.
 - A constraint is read as fixed and will not be challenged; if it is your own call, put it under `facts` with
   its reason. For material that must not leave the machine through a URL, pass `network: "off"`.
 

package/plugins/severally/skills/opencode/severally/reference.md

@@ -17,9 +17,8 @@ checked as given: the server rejects a first-round `explore` that carries a prop
 anchoring-sensitive — if you want your plan critiqued, that is `review`.
 
 **For a decision heavy enough to be worth two consultations**, ask `explore` first on the facts alone, then
-`review` with the proposal, and read what the first raised that the second never did. Measured on this
-project: repeat runs of the identical brief did not move the bottom line, while withholding the proposal once
-did, and the withheld run was the only one to question what the decision was even about.
+`review` with the proposal, and read what the first raised that the second never did. A consultant that sees
+your proposal tends to answer around it; one that does not is more likely to question the framing itself.
 
 ## A brief for a decision you will live with
 
@@ -70,10 +69,14 @@ names. Your own CLI is a fresh session but not another lineage, and its `quality
 consultants of one vendor.
 
 Send **one** `targets` call: every consultant receives the byte-identical brief, which is what makes the answers
-comparable. Poll the single group with `consult_get({ group_id })` and stop it with
-`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap (nine by default, shared by
-every severally session on this machine) and one consultation's quota per consultant, and `targets` is refused
-on a follow-up.
+comparable (on a follow-up to the group, the same new question, with each one's own earlier rounds). Poll the single group with `consult_get({ group_id })` and stop it with
+`consult_cancel({ group_id })`. A fan-out takes one slot of the concurrency cap per consultant (nine by default,
+shared by every severally session on this machine; the group starts only if every member gets one) and one
+consultation's quota per consultant. To ask every member again, follow up the group: `followup_to: "<group_id>"`
+with no `target` or `targets` (see Follow-ups).
+
+While you wait, `consult_get` blocks for up to its limit (ten minutes where the client allows it). To work on
+something independent in between, pass a shorter `wait_ms` and come back.
 
 `comparison.by_target` holds, per consultant: stance, summary, confidence, evidence basis, finding points (each
 with its `id` and severity), `severity_counts`, `decision_changers`, alternatives, unknowns (`u1` …),
@@ -93,7 +96,7 @@ Reading them against each other:
 4. **Read `decision_changers` before spending a follow-up**: a consultant that named the condition under which
    it would change its mind has told you what evidence to go get.
 5. **Spend a follow-up only on a divergence that would change your decision**, sent only to the consultant
-   whose reading it belongs to.
+   whose reading it belongs to, or to the whole group (`followup_to: "<group_id>"`) when it concerns all of them.
 6. **A stance every consultant shares is not evidence that the plan was checked.** Look for a premise they all
    rely on and none could verify; name it only if you can actually identify one.
 
@@ -123,14 +126,23 @@ in `failure.detail`, which tells you whether to retry with a longer budget or a
 
 By default a chain has five rounds: one initial round plus up to four follow-ups
 (`followup_to: "<previous job_id>"`); the operator can configure 1–20 (`server.max_rounds`), and
-`rounds_remaining` says what is left. A follow-up starts in a fresh working directory with no files: pass
+`rounds_remaining` says what is left. `followup_to: "<group_id>"`, with no `target` or `targets`, sends the same new
+question to every member of a fan-out, each continuing from its own latest round with its own history; a member
+that is still running, never answered or has used its rounds is listed under `skipped` and not asked.
+
+A follow-up needs only `followup_to` and the new `question`:
+`consult_start({ request: { followup_to: "<job_id>", question: "..." } })`. The consultant, the mode, `network` and what
+the earlier round was given (objective, constraints, success criteria, facts, proposal, counterpoints,
+artifacts) carry over, and the brief restates them; a field you pass replaces the earlier one, an empty list
+included. A follow-up starts in a fresh working directory with no files: pass
 `context.expose_from_parent: true` to copy again, as they are now, the paths the earlier round exposed (a changed
 or vanished entry is marked), and leave it off when the follow-up does not need them.
 
 Spend follow-ups only where you and the consultant actually diverge: quote the specific point, give the evidence
 that answers it, and ask what would change their view. Write your verdicts with `consult_record` first: the
 consultant is shown each earlier point with your verdict, so it answers what your checking found instead of
-restating it. A follow-up works across a server restart.
+restating it. A follow-up works across a server restart; `consult_list` shows an earlier session's
+consultations with their `job_id` and `group_id`.
 
 After each follow-up, state in one sentence the cause you still differ on. If it is the same as last round and
 the round brought no new evidence and no new condition that would change the judgement, stop and hand the user

package/scripts/init-config.mjs

@@ -53,7 +53,7 @@ export function renderConfig() {
     '  // ranking: optional, higher first -- which consultant a name that fits several goes to,',
     '  // before the built-in rules (opus over sonnet, newer version). e.g. "ranking": ["sol", "opus"]',
     '  //',
-    '  // server: optional -- max_rounds (5, 1-20), max_concurrent (9, 1-9), timeout_ms (3600000),',
+    '  // server: optional -- max_rounds (5, 1-20), max_concurrent (9, 1-9), timeout_ms (1800000),',
     '  //   max_wait_ms (45000), max_jobs_retained, kill_grace_ms: see CONFIG.md',
     '  "clis": {},',
     '  "consultants": {',

package/scripts/install.mjs

@@ -243,6 +243,57 @@ if (mode === 'plugin') {
 log(`   server command: ${JSON.stringify(serverCommand)}`);
 
 const codexHome = process.env.CODEX_HOME ?? path.join(home, '.codex');
+// consult_get waits 45 s by default, under the 60 s that some MCP clients
+// allow a tool call. A client known to wait longer is registered with this,
+// so one consult_get usually covers a whole consultation. The plugin's own
+// .mcp.json carries the same value for Claude Code, and its Codex manifest
+// with tool_timeout_sec 660 (codex 0.163 stops a tool call at 300 s by
+// default, progress notwithstanding). `codex mcp add` cannot set that
+// timeout, so a --manual Codex gets it as one line written into config.toml
+// under [mcp_servers.severally] (see the Codex row), together with the env;
+// both or neither, since the wait without the timeout would outlast Codex's
+// own deadline.
+const LONG_WAIT = 'SEVERALLY_MAX_WAIT_MS=600000';
+const AGY_WAIT = 'SEVERALLY_MAX_WAIT_MS=165000';
+const agyConfig = path.join(home, '.gemini', 'config', 'mcp_config.json');
+const CODEX_TIMEOUT_SEC = 660;
+const codexConfig = path.join(codexHome, 'config.toml');
+// The user's own tool_timeout_sec, read before --force removes the table that holds it.
+let priorCodexTimeout;
+
+// Where [mcp_servers.severally] sits in config.toml, and what it holds.
+// A minimal text read, not a TOML parser: the table runs to the next header
+// that is not one of its own sub-tables (codex may put env in one).
+function codexTable() {
+  let lines;
+  try { lines = fs.readFileSync(codexConfig, 'utf8').split('\n'); } catch (err) { return { reason: `cannot read ${codexConfig}: ${err.message}` }; }
+  const start = lines.findIndex((l) => /^\s*\[\s*mcp_servers\.severally\s*\]/.test(l));
+  if (start < 0) return { reason: `${codexConfig} has no [mcp_servers.severally] table` };
+  let end = lines.findIndex((l, i) => i > start && /^\s*\[/.test(l) && !/^\s*\[\s*mcp_servers\.severally\./.test(l));
+  if (end < 0) end = lines.length;
+  const block = lines.slice(start + 1, end).join('\n');
+  const timeout = block.match(/^\s*tool_timeout_sec\s*=\s*(\d+(?:\.\d+)?)/m)?.[1];
+  return { lines, start, timeout: timeout === undefined ? undefined : Number(timeout), wait: /SEVERALLY_MAX_WAIT_MS\s*=\s*"?\d+/.test(block) };
+}
+
+// The wait follows the timeout Codex will enforce: 15 s under the user's own
+// tool_timeout_sec when that is short, else the full 600000 ms.
+function codexPlan() {
+  const sec = priorCodexTimeout ?? CODEX_TIMEOUT_SEC;
+  return { sec, ms: sec < 615 ? Math.max(0, Math.floor((sec - 15) * 1000)) : 600000 };
+}
+
+// Inserts tool_timeout_sec right after the table header. Returns why it could
+// not, or null.
+function writeCodexTimeout(sec) {
+  const t = codexTable();
+  if (t.reason) return t.reason;
+  if (t.timeout !== undefined) return null; // never overwrite the user's value
+  t.lines.splice(t.start + 1, 0, `tool_timeout_sec = ${sec}`);
+  try { fs.writeFileSync(codexConfig, t.lines.join('\n')); } catch (err) { return `cannot write ${codexConfig}: ${err.message}`; }
+  return null;
+}
+
 const claudeSkillsDir = path.join(home, '.claude', 'skills');
 
 // ---------------------------------------------------------------- clients
@@ -260,7 +311,9 @@ const CLIENTS = [
     // `claude mcp get` exits non-zero when the server is not registered.
     isRegistered: () => tryRun('claude', ['mcp', 'get', 'severally'], { real: true }).ok,
     remove: () => tryRun('claude', ['mcp', 'remove', '--scope', 'user', 'severally']),
-    add: (bin) => tryRun('claude', ['mcp', 'add', '--scope', 'user', 'severally', '--', ...bin]),
+    // Claude Code waits on a tool call far longer than consult_get's ten
+    // minutes, so its consult_get may wait that long (see LONG_WAIT).
+    add: (bin) => tryRun('claude', ['mcp', 'add', '--scope', 'user', 'severally', '--env', LONG_WAIT, '--', ...bin]),
     skillFrom: path.join(PLUGIN, 'skills', 'claude', 'severally'),
     skillTo: path.join(claudeSkillsDir, 'severally'),
   },
@@ -269,8 +322,35 @@ const CLIENTS = [
     label: 'Codex',
     backup: [path.join(codexHome, 'config.toml')],
     isRegistered: () => tryRun('codex', ['mcp', 'get', 'severally'], { real: true }).ok,
-    remove: () => tryRun('codex', ['mcp', 'remove', 'severally']),
-    add: (bin) => tryRun('codex', ['mcp', 'add', 'severally', '--', ...bin]),
+    remove: () => {
+      priorCodexTimeout = codexTable().timeout;
+      return tryRun('codex', ['mcp', 'remove', 'severally']);
+    },
+    // The long wait is the env plus tool_timeout_sec in config.toml, both or neither.
+    add: (bin) => {
+      const { sec, ms } = codexPlan();
+      const r = tryRun('codex', ['mcp', 'add', 'severally', '--env', `SEVERALLY_MAX_WAIT_MS=${ms}`, '--', ...bin]);
+      if (!r.ok) return r;
+      if (dryRun) {
+        log(`   [dry-run] write tool_timeout_sec = ${sec} into ${codexConfig} under [mcp_servers.severally]`);
+        return r;
+      }
+      const why = writeCodexTimeout(sec);
+      if (!why) {
+        log(`   consult_get waits up to ${ms / 1000} s (SEVERALLY_MAX_WAIT_MS=${ms}, tool_timeout_sec = ${sec})`);
+        return r;
+      }
+      const back = tryRun('codex', ['mcp', 'remove', 'severally']);
+      if (!back.ok) return back;
+      log(`   the long consult_get wait was not set (it stays 45 s): ${why}`);
+      return tryRun('codex', ['mcp', 'add', 'severally', '--', ...bin]);
+    },
+    keptNote: () => {
+      const t = codexTable();
+      if (t.timeout === undefined || !t.wait) {
+        log(`   this registration lacks the long consult_get wait (45 s); --force adds it (SEVERALLY_MAX_WAIT_MS and tool_timeout_sec = ${CODEX_TIMEOUT_SEC})`);
+      }
+    },
     skillFrom: path.join(PLUGIN, 'skills', 'codex', 'severally'),
     skillTo: path.join(codexHome, 'skills', 'severally'),
   },
@@ -287,7 +367,14 @@ const CLIENTS = [
       return r.ok && /severally/.test(r.out);
     },
     remove: () => tryRun('agy', ['mcp', 'remove', 'severally']),
-    add: (bin) => tryRun('agy', ['mcp', 'add', 'severally', ...bin]),
+    // agy stops an MCP tool call at 3 minutes, progress notifications or not
+    // (measured: a 310 s call ended at 180 s), so its wait is 15 s under that.
+    add: (bin) => tryRun('agy', ['mcp', 'add', '--env', AGY_WAIT, 'severally', ...bin]),
+    keptNote: () => {
+      if (!/SEVERALLY_MAX_WAIT_MS/.test(fs.existsSync(agyConfig) ? fs.readFileSync(agyConfig, 'utf8') : '')) {
+        log('   this registration lacks the longer consult_get wait (45 s); --force adds it (SEVERALLY_MAX_WAIT_MS=165000)');
+      }
+    },
     skillFrom: path.join(PLUGIN, 'skills', 'antigravity', 'severally'),
     skillTo: path.join(home, '.gemini', 'config', 'skills', 'severally'),
   },
@@ -316,7 +403,14 @@ const CLIENTS = [
     // reachable only inside whatever directory the installer happened to
     // run from.
     remove: () => ({ ok: true, out: 'opencode has no mcp remove; re-adding replaces the entry' }),
-    add: (bin) => tryRun('opencode', ['mcp', 'add', 'severally', '--global', '--', ...bin]),
+    // OpenCode sets no deadline of its own on a tool call (a 610 s call came
+    // back), so it gets the long consult_get wait with no timeout to pair.
+    add: (bin) => tryRun('opencode', ['mcp', 'add', 'severally', '--global', '--env', LONG_WAIT, '--', ...bin]),
+    keptNote: () => {
+      const text = [path.join(xdgConfig, 'opencode', 'opencode.json'), path.join(xdgConfig, 'opencode', 'opencode.jsonc')]
+        .map((f) => { try { return fs.readFileSync(f, 'utf8'); } catch { return ''; } }).join('\n');
+      if (!text.includes('SEVERALLY_MAX_WAIT_MS')) log('   this registration lacks the long consult_get wait (45 s); --force adds it (SEVERALLY_MAX_WAIT_MS)');
+    },
     // A zero exit from `mcp add` can be a usage dump in disguise (see above),
     // so this client's registration is verified by listing after adding --
     // and the recorded command is compared against this install's.
@@ -349,6 +443,16 @@ function registrationCommandMatches(client, bin) {
   return false;
 }
 
+// The list right after an add can be briefly empty, so it is asked up to
+// three times, 1.5 s apart, before the add is judged.
+function listedAfterAdd(client) {
+  for (let i = 0; i < 3; i++) {
+    if (i) Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, 1500);
+    if (client.isRegistered()) return true;
+  }
+  return false;
+}
+
 // Registers one client's MCP server directly (through its own `mcp add`) and
 // copies its skill, backing up everything it touches first. Shared by plugin
 // mode (Antigravity only) and --manual mode (all three clients).
@@ -361,19 +465,30 @@ function installClientDirectly(client, bin) {  step(`Registering with ${client.l
   if (client.isRegistered() && !force) {
     keptRegistrations = true;
     log('   already registered; leaving it as it is (use --force to re-register)');
+    client.keptNote?.();
   } else {
     if (client.isRegistered()) client.remove();
     const r = client.add(bin);
     if (!r.ok) {
       log(`   failed: ${r.out}`);
       process.exitCode = 1;
-    } else if (!dryRun && client.verifyAdd && !client.isRegistered()) {
+    } else if (!dryRun && client.verifyAdd && !listedAfterAdd(client)) {
       // opencode prints usage and exits 0 on flags a future version renames,
       // so a zero exit from `mcp add` proves nothing: confirm the entry is
       // actually listed, or the server silently never reaches the client.
-      log('   add exited 0 but the server is not listed; registration failed');
-      log(`   the list said: ${lastListOutput.slice(0, 500) || '(nothing)'}`);
-      process.exitCode = 1;
+      // Its list has also come back empty with the server in its config
+      // (twice, on the first run after an upgrade), so a config
+      // holding exactly this install's command is a registration, noted.
+      const said = `   the list said: ${lastListOutput.slice(0, 500) || '(nothing)'}`;
+      if (registrationCommandMatches(client, bin)) {
+        log(`   registered in ${client.label}'s global config, but \`${client.bin} mcp list\` does not show it yet`);
+        log(said);
+        log(`   check with \`${client.bin} mcp list\` after restarting it`);
+      } else {
+        log('   add exited 0 but the server is not listed; registration failed');
+        log(said);
+        process.exitCode = 1;
+      }
     } else if (!dryRun && client.verifyAdd && !registrationCommandMatches(client, bin)) {
       log('   registration not verified: the listed server command does not match this install');
       process.exitCode = 1;

package/src/adapters/antigravity-sandbox.mjs

@@ -55,7 +55,11 @@ const WEB_TOOLS = new Set(['search_web', 'read_url_content']);
 // call through. So the hook always answers, allow included, and anything it
 // cannot read or check -- broken JSON, a stdin error, arguments nested past
 // what it walks, an exception of its own -- is denied. A hook that never runs
-// or is killed answers nothing, and that stays agy's call. For the file-reading tool
+// or is killed answers nothing, and that stays agy's call: agy 1.4.2 fails such
+// a call rather than running it ("JSON hook ... failed: command failed: ..."),
+// checked live on 2026-10-20 with invoke_subagent against a hook that exited 1,
+// exited 2, outlived the 10 s timeout, and whose script was missing -- each
+// time the step ended in ERROR and no child agent started. For the file-reading tool
 // and for a file: URL, every path-like parameter is also checked against the
 // protected roots and file names, before and after resolving links, with ~
 // expanded: a consultant that can browse must not read a credential and

package/src/adapters/codex.mjs

@@ -167,11 +167,16 @@ export function interpret({ stdout, stderr, code, lastMessageText }) {
     }
   }
 
-  if (errorEvents.length) {
-    const msg = errorEvents
-      .map((e) => e.message ?? e.error?.message ?? JSON.stringify(e))
-      .join(' | ');
-    return { ok: false, failureKind: classifyMessage(msg), message: msg, usageRaw: usage, events: events.length };
+  const errorMsg = errorEvents
+    .map((e) => e.message ?? e.error?.message ?? JSON.stringify(e))
+    .join(' | ');
+  // An error the turn recovered from (the stream still ends in
+  // turn.completed, with an answer) does not throw the answer away; the lead
+  // is told about it instead. A turn that ends in turn.failed has failed,
+  // whatever text it left behind.
+  const recovered = errorEvents.length > 0 && Boolean(text) && events.at(-1)?.type === 'turn.completed';
+  if (errorEvents.length && !recovered) {
+    return { ok: false, failureKind: classifyMessage(errorMsg), message: errorMsg, usageRaw: usage, events: events.length };
   }
   if (!text) {
     const msg = (stderr || '').trim() || `codex exited with code ${code} and produced no final message`;
@@ -183,7 +188,13 @@ export function interpret({ stdout, stderr, code, lastMessageText }) {
       events: events.length,
     };
   }
-  return { ok: true, text, usageRaw: usage, events: events.length };
+  return {
+    ok: true,
+    text,
+    usageRaw: usage,
+    events: events.length,
+    recoveredError: recovered ? { failureKind: classifyMessage(errorMsg), message: errorMsg } : null,
+  };
 }
 
 /**

package/src/brief.mjs

@@ -184,6 +184,8 @@ function renderExposeManifest(manifest) {
   const skipped = [
     count('symlink') ? `${count('symlink')} symlink(s), or path(s) through one, were skipped, not followed.` : null,
     count('protected') ? `${count('protected')} credential or history path(s) were left out on purpose.` : null,
+    count('ignored') ? `${count('ignored')} path(s) (.git, node_modules, whatever .gitignore excludes) were left out as not source.` : null,
+    count('submodule') ? `${count('submodule')} submodule(s) or nested repositor(ies) were left out; their files are not copied.` : null,
     count('gone') ? `No longer there, so not copied again: ${named('gone')}.` : null,
     count('masked') ? `Not copied again, because the record of the earlier round masked the path: ${named('masked')}.` : null,
     count('replaced') ? `The earlier round's change is replaced by the diff given in this round: ${named('replaced')}.` : null,
@@ -204,9 +206,30 @@ function renderExposeManifest(manifest) {
 // from crowding out the question it is there to inform.
 const clip = (s, max = 400) => (s.length > max ? `${s.slice(0, max)}...` : s);
 
+// The earlier rounds have a budget of their own, beside the request's cap:
+// when they outgrow it, the oldest rounds are left out, and the brief says so.
+const HISTORY_CHARS = 40_000;
+
+function renderRound(p) {
+  // Prefixed with the round, so a point from round 1 is not taken for this one's.
+  const tag = (id) => `r${p.round}.${id}`;
+  const verdict = (x) => (x.verdict ? ` -- lead's verdict: ${x.verdict}${x.effect ? ` (${clip(x.effect)})` : ''}` : '');
+  const list = (title, items, line) => (items?.length ? [title, ...items.map(line)].join('\n') : null);
+  return [
+    `### Round ${p.round} (${p.mode})`,
+    `Question asked: ${p.question}`,
+    `Your answer, summarised: ${p.summary}`,
+    list('Points you raised:', p.findings,
+      (f) => `- ${tag(f.id)}: ${clip(f.point)}${verdict(f)}${f.grounds ? `\n  grounds: ${clip(f.grounds)}` : ''}`),
+    list('Unknowns you named:', p.unknowns, (u) => `- ${tag(u.id)}: ${clip(u.point)}${verdict(u)}`),
+    list('Checks you proposed:', p.next_checks, (c) => `- ${tag(c.id)}: ${clip(c.point)}${verdict(c)}`),
+  ].filter(Boolean).join('\n');
+}
+
 /**
  * @param {object} req validated request
- * @param {object} chain { round, priorRounds: [{question, mode, summary, findings: [{id, point, verdict, effect}]}] }
+ * @param {object} chain { round, priorRounds: [{question, mode, summary, findings: [{id, point, grounds, verdict, effect}],
+ *   unknowns: [{id, point, verdict, effect}], next_checks: [{id, point, verdict, effect}]}] }
  */
 export function renderBrief(req, chain = { round: 1, priorRounds: [] }, exposeManifest = null) {
   const parts = [];
@@ -238,22 +261,21 @@ export function renderBrief(req, chain = { round: 1, priorRounds: [] }, exposeMa
   if (chain.priorRounds && chain.priorRounds.length) {
     parts.push('');
     parts.push('## Earlier rounds of this same consultation');
-    for (const p of chain.priorRounds) {
-      parts.push(
-        [
-          `### Round ${p.round} (${p.mode})`,
-          `Question asked: ${p.question}`,
-          `Your answer, summarised: ${p.summary}`,
-          p.findings && p.findings.length
-            ? ['Points you raised, with what the lead\'s own check found -- confirmed: it held; not_applicable: checked, and it'
-              + ' does not apply here; unverifiable: could not be checked; no verdict: not checked yet:',
-              ...p.findings.map((f) => `- ${f.id}: ${clip(f.point)}${f.verdict ? ` -- lead's verdict: ${f.verdict}${f.effect ? ` (${clip(f.effect)})` : ''}` : ''}`)].join('\n')
-            : null,
-        ]
-          .filter(Boolean)
-          .join('\n'),
-      );
+    parts.push(
+      'Each point carries the lead\'s own check where there is one -- confirmed: it held; not_applicable: checked, and'
+      + ' it does not apply here; unverifiable: could not be checked; unverified, or no verdict: not checked yet.',
+    );
+    const blocks = chain.priorRounds.map(renderRound);
+    let kept = 0;
+    let used = 0;
+    // Newest first: the round being followed up always goes in.
+    for (let i = blocks.length - 1; i >= 0 && (kept === 0 || used + blocks[i].length <= HISTORY_CHARS); i--) {
+      used += blocks[i].length;
+      kept += 1;
     }
+    const left = chain.priorRounds.slice(0, blocks.length - kept).map((p) => p.round);
+    if (left.length) parts.push(`(Round${left.length > 1 ? 's' : ''} ${left.join(', ')} left out to keep this brief within its size.)`);
+    parts.push(...blocks.slice(blocks.length - kept));
     parts.push('');
     parts.push(
       'This round is a follow-up. The lead has narrowed the exchange to the divergences above. Do not restate your earlier answer; address what is new, and say plainly if the new information changes or does not change your position.',