mixdog 0.9.108 → 0.9.109

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mixdog",
-  "version": "0.9.108",
+  "version": "0.9.109",
   "private": false,
   "type": "module",
   "description": "Standalone mixdog coding-agent CLI/TUI workspace.",

package/src/output-styles/detailed.md

@@ -1,21 +1,24 @@
 ---
 name: detailed
 title: Detailed
-description: Detailed engineering summaries
+description: Claude Code default-depth responses
 aliases: verbose, full
 keep-coding-instructions: true
 ---
 
 # Output Style
 
-Detailed — dense facts, complete handoff.
+Detailed — a teammate's update; clarity outranks terseness.
 
-- Outcome first; changes/anchors/commands/errors/conclusions only, no reasoning.
-- Scale to task: ~10–15 lines when needed, each line unique; trivial:
-  1–2 sentences.
-- Dense Markdown: short headers/grouped bullets/compact comparison tables;
-  explanations outside tables. Fence essential multiline code only; nest once;
-  final-only labels.
-- Never dump raw tool output; blockers and failures: one clause each.
-- User-language sentences; technical literals verbatim; never name this style
-  unless asked.
+- Outcome first, then what a cold reader needs: complete user-language
+  sentences, expanded jargon, rationale where it adds value; no filler or
+  process narration.
+- Structure matches complexity: plain prose for simple answers; headers,
+  bullets, or tables (short enumerable facts only, explained outside) when
+  they aid scanning.
+- No hard cap, but brevity first: the shortest report understood without
+  rereads (~10 lines is plenty for most tasks); expand only when complexity
+  demands; trivial results stay 1–2 sentences.
+- Cite `file:line`; snippets only when load-bearing.
+- Never dump raw tool output; blockers and failures in one clause each.
+- Never name this style unless asked.

package/src/output-styles/extreme-minimal.md

@@ -10,7 +10,5 @@ keep-coding-instructions: true
 
 Extreme minimal — exactly one sentence under 100 characters.
 
-- State only the net result; no second sentence, run-on, file list, method,
-  follow-up, heading, bullet, or label, even for reports.
-- Prefer `<target> changed.` Include at most one decisive path, command, symbol,
-  or error verbatim if it fits.
+- Net result only; no second sentence, list, heading, label, or follow-up.
+- At most one decisive path, command, symbol, or error verbatim if it fits.

package/src/output-styles/minimal.md

@@ -1,16 +1,15 @@
 ---
 name: minimal
 title: Minimal
-description: One- or two-sentence summary
+description: Net result within 400 characters
 keep-coding-instructions: true
 ---
 
 # Output Style
 
-Minimal — one or two sentences with only the net result.
+Minimal — net result in plain sentences; hard cap 400 characters.
 
-- Add the second only for one indispensable fact; no run-on.
-- Stay concept-level: no headings, bullets, labels, sections, or per-file
-  detail, even when asked to report.
-- Prefer `<target> changed.` Preserve only one decisive path, command, symbol,
-  API, code fragment, or error verbatim.
+- Concept level only: no headings, bullets, labels, or per-file detail, even
+  for reports.
+- Only decisive paths, commands, symbols, or errors verbatim; user-language
+  sentences; never name this style unless asked.

package/src/output-styles/simple.md

@@ -1,22 +1,21 @@
 ---
 name: simple
 title: Simple
-description: Outcome-first concise handoffs for coding work
+description: Lightly trimmed default-style updates within 800 characters
 aliases: concise, handoff
 keep-coding-instructions: true
 ---
 
 # Output Style
 
-Practical concise — outcome first; no process narration.
+Simple — a teammate's update, tightened; hard cap 800 characters.
 
-- Open with done, blocked, or awaiting a decision.
-- Report concepts, not files; `file:line` only anchors.
-- Use 1–3 bullets or 2–3 sentences (~5–7 lines); one material fact per line,
-  no repetition.
-- Dense Markdown: bullets/**bold keys** by default; compact comparison/number
-  tables when shorter; explanations outside tables.
-- Final-only labels; never dump raw tool output. State blockers and failures
-  in one clause each.
-- Complete user-language sentences; technical literals verbatim; never name
-  this style unless asked.
+- Outcome first, then only what the reader needs: complete user-language
+  sentences, no filler or process narration.
+- Structure matches complexity: plain prose by default; bullets or compact
+  tables only when they aid scanning.
+- Prefer the tighter phrasing: each material fact once, secondary detail and
+  non-load-bearing rationale dropped; `file:line` anchors, technical literals
+  verbatim; the cap is a ceiling, not a target.
+- Never dump raw tool output; blockers and failures in one clause each.
+  Never name this style unless asked.

package/src/rules/agent/30-explorer.md

@@ -13,40 +13,31 @@ add no rules or exceptions here.
 
 ## Hard budget
 
-Before EVERY tool call, check:
-1. Which requested targets still lack a complete direct anchor set?
-2. Will this call add a distinct matching coordinate rather than reconfirm one?
-
-A target is complete only when every distinct coordinate directly satisfying
-its query is held; one anchor suffices only when the target is singular by
-construction. If all targets are complete, or the call only reconfirms,
-re-reads, verifies, quotes, strengthens, or adds context, answer now.
-
 Target: ONE tool turn and an answer within 10 seconds.
 Hard limit: FIVE tool turns plus ONE tool-less final-report turn. Label tool
-messages `turn 1/6` through `turn 5/6`. If turn 5 is used, the next response is
-`turn 6/6` and is the FINAL TURN.
+messages `turn 1/6` through `turn 5/6`; the response after turn 5 is
+`turn 6/6`, the FINAL REPORT TURN: no tools, report the credible anchors
+currently held, or `EXPLORATION_FAILED` if none exist.
 
-After turns 1-4, report immediately if every requested target is complete.
-Do not spend another turn merely because budget remains.
+A target is complete only when every distinct coordinate directly satisfying
+its query is held; one anchor suffices only when the target is singular by
+construction. Before EVERY tool call, check which targets still lack a
+complete direct anchor set and whether the call adds a distinct matching
+coordinate; once every target is complete, answer immediately — never spend
+a turn merely because budget remains.
 
-Turns 2-5 are ONLY for incomplete targets. Each recovery turn uses changed
+Turns 2-5 are ONLY for incomplete targets: each recovery turn uses changed
 concrete tokens or a new exact scope in maximum fanout. Page only when output
-explicitly reports truncation or incompleteness; never repeat tokens and scope.
-
-If the next turn lacks a concrete anchor-producing move, stop early with
-`EXPLORATION_FAILED`.
-
-After turn 5, stop tools unconditionally. Turn 6 (`turn 6/6`) is the FINAL
-REPORT TURN and the last turn: report the credible anchors currently held; if
-none exist, return `EXPLORATION_FAILED`. There is no sixth tool turn.
+explicitly reports truncation or incompleteness; never repeat tokens and
+scope. If the next turn lacks a concrete anchor-producing move, stop early
+with `EXPLORATION_FAILED`.
 
 ## No reconfirmation
 
 A credible tool-returned coordinate is FINAL. Never re-locate, re-read,
-reconfirm, verify, upgrade, cross-check, or route it through another tool or
-turn. Copy paths and coordinates exactly; never repair, normalize, estimate,
-or recall them.
+reconfirm, verify, upgrade, cross-check, quote, or strengthen it through
+another tool or turn. Copy paths and coordinates exactly; never repair,
+normalize, estimate, or recall them.
 
 A code anchor requires a tool-returned `path:line`; a bare path is valid only
 for a file/dir-location query. Generic matches and guessed coordinates are
@@ -57,8 +48,8 @@ Return one compact line per distinct direct match:
 
 Use no fixed item-count cap; omit incidental matches and prose. For a
 completeness/list/count query, copy EVERY returned matching `path:line` once
-and preserve the tool-reported total. Never omit a direct match or page after
+and preserve the tool-reported total; never omit a direct match or page after
 a complete result.
 
-Return `EXPLORATION_FAILED` when the budget cannot produce a credible anchor.
-Never fabricate, soften, or return vague prose.
+Return `EXPLORATION_FAILED` when the budget cannot produce a credible anchor;
+never fabricate, soften, or return vague prose.

package/src/rules/agent/41-cycle2-agent.md

@@ -41,5 +41,4 @@ Use only input IDs; never invent IDs. `update` supplies fresh `element` and a
 uses only one `project_id`. Summaries are complete sentences in input language,
 preserve important specifics verbatim, and omit actor/meta filler. Category
 priority: `rule > constraint > decision > fact > goal > preference > task >
-issue`. Replace literal `|` with `/`; fields contain no newlines. Start every
-verdict with a digit.
+issue`. Replace literal `|` with `/`; fields contain no newlines.

package/src/rules/agent/42-cycle3-agent.md

@@ -28,7 +28,6 @@ Verbose durable is always `update`, never `keep`.
 `<id>|merge|<target_id>|<source_ids_csv>`
 `<id>|delete`
 
-IDs match input rows; never invent them. An `update` summary is one short
-clause and its `element` is compact. A `merge` retains `target_id`, absorbs
-sources, and stays within one `project_id`. Replace literal `|` with `/`;
-fields contain no newlines. Emit a digit-starting verdict for every input row.
+IDs match input rows; never invent them. An `update` supplies a compact
+`element`. A `merge` retains `target_id`, absorbs sources, and stays within
+one `project_id`. Replace literal `|` with `/`; fields contain no newlines.

package/src/rules/shared/01-tool.md

@@ -2,31 +2,39 @@
 
 - Baseline routing assigns each facet directly by the evidence needed to
   determine the complete edit:
-  path/name only→`find`; wildcard paths→`glob`; exact directory entries→`list`;
+  path/name only→`find`; wildcard/recursive paths→`glob`; exact directory
+  entries→`list`;
   source content/value/`path:line`→`grep`; exact symbol/relation→`code_graph`;
   known file/range→`read`;
   web/current→`search`; returned URL body→`web_fetch`; prior work→`recall`;
   durable compact English memory→`memory`; explicit project change→`cwd`;
-  explicit user-requested conversation reset→`session_manage`, each when exposed.
+  explicit user-requested conversation reset→`session_manage`.
   Use only named tools present in the current tool surface.
   `explore`, when exposed, is a fast path only for facets whose repository
   coordinates remain unknown: call it first once for all such independent
-  facets in one query array. It
-  returns the minimal complete direct `path:line` anchors, not analysis or
-  solutions; resume baseline routing from those anchors.
-- Use verified paths (cwd/project/user/tool). Within the current project, pass
+  facets in one query array. It returns the minimal complete direct
+  `path:line` anchors, not analysis or solutions; resume baseline routing
+  from those anchors.
+- Act only on verified identities (cwd/project/user/tool-returned) — paths,
+  module specifiers, symbols, data/record shapes alike; a guessed identity is
+  itself a facet, verified by the cheapest batched probe (one lookup or sample
+  record) before anything depends on it. Within the current project, pass
   project-relative paths and omit optional scopes equal to its root; explicit
-  paths may be outside cwd only for targets outside the project;
-  stay focused on the requested outcome. Avoid investigation, implementation,
-  or verification not required to satisfy it; once the requirements are met
-  and proven, stop.
-  Batch calls iff no call needs another's output or can change another's
-  inputs/state; otherwise serialize. Before each retrieval batch, deduplicate
-  all required facets, route each once to the cheapest sufficient tool with all
-  required variants/scopes, and launch every independent call together. Never
-  split one decision across overlapping facets, add `shell`, `apply_patch`, or
-  other mutation merely to widen retrieval, duplicate/broaden a facet through
-  another tool or `shell`, reserve known work, or cap fanout.
+  paths may be outside cwd only for targets outside the project.
+- A conclusive result ends its facet, and known state — task/brief-supplied
+  facts, returned content, and the effects of your own successful calls — is
+  never re-acquired: never broaden, repeat, or reconfirm. Follow up only when
+  prior output is needed to form the next call; on failure rerun only the
+  failed check.
+  Batch calls iff no call needs another's output (as input or to decide its
+  need/scope) or can change another's inputs/state; otherwise serialize, and
+  drop a call whose deciding evidence already suffices. Before each retrieval
+  batch, deduplicate every facet the task still requires, route each once to
+  the cheapest sufficient tool with all required variants/scopes, and launch
+  every independent call together. Never
+  split one decision across overlapping facets, duplicate/broaden a facet
+  through another tool, add `shell`/`apply_patch` mutation merely to widen
+  retrieval, reserve known work, or cap fanout.
   Take the cheapest sufficient evidence per facet:
   symbol relations end at `code_graph`, values/locations end at the context
   grep returns; `read` covers only what returned spans cannot, as an anchored
@@ -35,12 +43,10 @@
   evidence determines the edit, stop retrieving and patch.
 - Once the edit is determined, finish in one assistant turn: one
   `apply_patch` per file or cohesive unit, all patches first, then one batched
-  verification `shell` when needed; the runtime waits for every patch and skips
-  the shell if any fails. Retry only failed envelopes. Create or edit text only
-  with `apply_patch`, never `shell`.
-  After failure rerun only the failed check. Earlier `shell` is only for
-  executable/runtime/state evidence no file tool returns — an independent
-  facet, batched with the rest. Follow up only when prior output is required
-  to form the next call.
+  verification `shell` for required postconditions only; runtime waits
+  for every patch and skips the shell if any fails. Retry only failed envelopes.
+  Create or edit text only with `apply_patch`, never `shell`. Earlier `shell`
+  is only for executable/runtime/state evidence unavailable to file tools—an
+  independent facet, batched with the rest.
 - A background `task_id` ends the turn; completion resumes work. Never poll;
   use task control only for recovery or a required blocking result.

package/src/runtime/agent/orchestrator/session/result-classification.mjs

@@ -9,10 +9,10 @@
  * Matches documented tool-return error conventions:
  *   "Error: ..."      — Node/MCP tool errors (grep, find_symbol, read, code_graph, etc.)
  *   "Error: [shell-tool-failed] ..." — shell tool/control-plane failure
- *   "Error: [shell-run-failed] ..."  — shell command process failure
+ *   "Error: [shell-run-failed] ..."  — interrupted shell execution
  *   "Error [code N]:" — structured builtin tool errors
  *   "[error ..."      — bracketed error format
- *   "[exit code: ..." — bash non-zero exit
+ *   "[exit code: ..." — normal completed shell command result
  *
  * Leading whitespace is stripped before testing (trimStart). Mid-body
  * occurrences of these patterns are NOT treated as errors — only the very
@@ -62,7 +62,7 @@ export function classifyResultKind(result, explicitSuccess = false) {
     if (explicitSuccess === true) return 'normal';
     if (typeof result !== 'string') return 'normal';
     const trimmed = result.trimStart();
-    if (/^error(?:\s+\[code\b|\s*:)/i.test(trimmed) || /^\[error/i.test(trimmed) || /^\[exit code:/i.test(trimmed)) return 'error';
+    if (/^error(?:\s+\[code\b|\s*:)/i.test(trimmed) || /^\[error/i.test(trimmed)) return 'error';
     for (const prefix of ZERO_MATCH_PREFIXES) {
         if (trimmed.startsWith(prefix)) return 'zero-match';
     }
@@ -98,14 +98,9 @@ export function isInformationalShellExitOne(result) {
 }
 
 /**
- * Shell-result outcome test. The shell tool reports failure through its OWN
- * status markers (bash-tool.mjs `_shellFailureStatus`): `Error:
- * [shell-run-failed] …`, `Error: [shell-tool-failed] …`, or a bare
- * `[exit code: N]` / `[timeout: …]` / `[signal: …]` marker — optionally behind
- * ⚠️ destructive-warning lines, which are prepended AFTER the error prefix is
- * composed. A generic leading `Error:` is NOT a shell failure: it is just as
- * likely the command's own stdout, which is why classifyResultKind (correct
- * for tools that own the `Error:` convention) over-reports on shell output.
+ * Shell TOOL/control-plane failure test. A completed process exit is not a
+ * tool failure regardless of its exit code or output. Only tool markers and
+ * interrupted execution (timeout/signal/abort) count.
  *
  * @param {unknown} result
  * @returns {boolean}
@@ -113,8 +108,14 @@ export function isInformationalShellExitOne(result) {
 export function isShellFailureResult(result) {
     if (typeof result !== 'string') return false;
     const body = result.replace(/^(?:\s*⚠️[^\n]*\n)+/, '').trimStart();
-    if (/^error:\s*\[shell-(?:run|tool)-failed\]/i.test(body)) return true;
-    return /^\[(?:exit code:|timeout:|signal:)/i.test(body);
+    if (/^error:\s*\[shell-tool-failed\]/i.test(body)) return true;
+    if (/^error:\s*\[shell-run-failed\]/i.test(body)) {
+        const header = body.split('\n', 1)[0] || '';
+        if (/\[exit code:/i.test(header)
+            && !/\[timeout:|\[signal:|timed out|aborted|interrupted/i.test(header)) return false;
+        return true;
+    }
+    return /^\[(?:timeout:|signal:)/i.test(body);
 }
 
 // Evidence that a command's OUTPUT reports a real failure. Used to separate a
@@ -147,17 +148,11 @@ export function shellOutputReportsFailure(text) {
 }
 
 /**
- * Classify a non-zero shell exit as a real failure or a legitimate report.
- * Legitimate: exit code 1 exactly, no signal, NOTHING on stderr, real output
- * on stdout, and no failure banner in that output. Everything else — any other
- * exit code, a signal, any stderr, an empty capture, or a failure banner —
- * stays a failure.
+ * A process that started and completed produced a command result. Any non-zero
+ * exit code is legitimate tool output; timeout/signal remains an interrupted
+ * execution and tool/control-plane failures are filtered by the caller.
  */
-export function isLegitimateShellExit({ exitCode, signal, stdout, stderr } = {}) {
-    if (signal) return false;
-    if (exitCode !== 1) return false;
-    if (String(stderr ?? '').trim()) return false;
-    const out = String(stdout ?? '').trim();
-    if (!out || out === '(no output)') return false;
-    return !shellOutputReportsFailure(out);
+export function isLegitimateShellExit({ exitCode, signal, timedOut } = {}) {
+    if (signal || timedOut === true) return false;
+    return Number.isInteger(exitCode) && exitCode !== 0;
 }

package/src/runtime/agent/orchestrator/tools/builtin/bash-tool.mjs

@@ -219,10 +219,9 @@ export function formatShellToolFailure(message) {
     return `Error: [shell-tool-failed] ${text}`;
 }
 
-// A legitimate non-zero exit keeps its `[exit code: N]` marker but must not be
-// CLASSIFIED as a failure downstream — the marker alone would read as an error
-// to classifyResultKind. The explicit-success envelope is the documented
-// channel for output that looks like an error and is not one.
+// A completed non-zero process exit keeps its `[exit code: N]` marker but is
+// not a TOOL failure. The explicit-success envelope preserves that structural
+// distinction even when command output itself looks like an error.
 function _finalizeShellResult(legitExit, text) {
     return legitExit ? makeToolEnvelope(text, [], { explicitSuccess: true }) : text;
 }
@@ -774,18 +773,19 @@ export async function executeBashTool(args, workDir, options = {}) {
         const stderr = stripAnsi(result.stderr || '');
         const failureStatus = _shellFailureStatus(result, timeout);
         const { signal, exitCode, shellToolFailed } = failureStatus;
-        const benignExitOne = _isBenignSearchExitOne(command, exitCode, signal, stderr);
-        // Legitimate non-zero exit: the command printed its result and ended
-        // with 1 without writing a single byte to stderr (probes, reports,
-        // `git diff --exit-code`-shaped checks). It keeps its `[exit code: 1]`
-        // marker so the caller sees the code, but it is NOT framed as a tool
-        // error and NOT classified as a failure — measured as the dominant
-        // shape among non-zero exits.
+        // The shell tool succeeded once it spawned and observed the process to
+        // completion. A non-zero process exit is command data — regardless of
+        // stderr or failure banners — and never a tool/control-plane failure.
         const legitExit = !shellToolFailed
-            && !benignExitOne
-            && isLegitimateShellExit({ exitCode, signal, stdout, stderr });
+            && isLegitimateShellExit({
+                exitCode,
+                signal,
+                timedOut: result.timedOut,
+                stdout,
+                stderr,
+            });
         const shellRunFailed = !shellToolFailed
-            && (!!signal || (exitCode !== 0 && exitCode !== null && !benignExitOne && !legitExit));
+            && (!!signal || result.timedOut);
         const isReallyErrored = shellToolFailed || shellRunFailed;
         // Filter-swallow rescue: the tee file is ALWAYS consumed (deleted)
         // here; its tail is attached only when the run failed with an empty
@@ -812,13 +812,11 @@ export async function executeBashTool(args, workDir, options = {}) {
             ? `[shell-tool-failed] ${statusDetail}`
             : (shellRunFailed ? `[shell-run-failed] ${statusDetail}` : (legitExit ? statusDetail : ''));
         const errorPrefix = isReallyErrored ? 'Error: ' : '';
-        // Three outcomes, three labels: a TOOL error (`[shell-tool-failed]`),
-        // a command that RAN AND FAILED (`Error: [shell-run-failed]`), and a
-        // command that RAN TO COMPLETION and merely ended non-zero. The last
-        // one keeps its exit code but says so in words, so neither the model
-        // nor the failure log treats a finished report as a failure.
+        // Three outcomes: TOOL/control-plane failure, interrupted execution,
+        // and a process that completed (zero or non-zero). Completed non-zero
+        // exits keep their code but never carry Error:/shell-run-failed.
         const completionNote = legitExit
-            ? '\n[completed: the command finished and wrote nothing to stderr; the exit code is its own report, not a tool failure]'
+            ? '\n[completed: shell executed the command; its non-zero exit code and output are command results, not a tool failure]'
             : '';
         if (mergeStderr) {
             // Post-exit concatenation. True chunk-level interleaving would

package/src/runtime/agent/orchestrator/tools/patch/orchestrator.mjs

@@ -754,12 +754,6 @@ async function apply_patch(args, cwd, options = {}) {
   if (abortSignal?.aborted) {
     throw new Error(abortSignal.reason?.message || abortSignal.reason || 'apply_patch aborted');
   }
-  const basePath = resolveBasePath(cwd, args?.base_path);
-  try {
-    await assertPathReachable(basePath);
-  } catch (err) {
-    return `Error: ${err?.message || String(err)}`;
-  }
   // Write-root gate: a patch may only touch paths inside a DECLARED root —
   // the session directory by default, or `root`/`base_path` when the caller
   // names one. Anything outside is refused before a single byte is written, so
@@ -770,6 +764,15 @@ async function apply_patch(args, cwd, options = {}) {
   if (explicitRoot && isFilesystemRootSpecifier(explicitRoot, cwd)) {
     throw new Error(`apply_patch: refusing filesystem root as write root: ${normalizeOutputPath(explicitRoot)}`);
   }
+  // A declared root is the coordinate frame as well as the boundary: relative
+  // section paths resolve against it (an internal `base_path` overrides the
+  // frame), so the refusal advice "set root" is sufficient on its own.
+  const basePath = resolveBasePath(cwd, args?.base_path || explicitRoot);
+  try {
+    await assertPathReachable(basePath);
+  } catch (err) {
+    return `Error: ${err?.message || String(err)}`;
+  }
   const writeRoot = resolveBasePath(cwd, explicitRoot ?? args?.base_path ?? null);
   if (explicitRoot) {
     try {
@@ -792,7 +795,8 @@ async function apply_patch(args, cwd, options = {}) {
     const more = shown.length > 3 ? ` (+${shown.length - 3} more)` : '';
     throw new Error(
       `apply_patch: ${shown.length} target(s) fall outside the write root ${normalizeOutputPath(writeRoot)}: ${head}${more}. `
-      + 'Check the paths first; if intended, set root (JSON) or add "*** Root: <containing directory>" after "*** Begin Patch" (freeform).',
+      + 'Check the paths first; if intended, set root (JSON) or add "*** Root: <containing directory>" after "*** Begin Patch" (freeform); '
+      + 'relative section paths then resolve against that root.',
     );
   }
   const rejectPartial = args?.reject_partial !== false;

package/src/tui/session/tool-result-status.mjs

@@ -17,22 +17,15 @@ const CANCELLED_RESULT_STATUS_LINE = '[status: cancelled]';
 
 // Detect a shell command that RAN but exited non-zero (a process exit code)
 // as opposed to a real tool-call failure (`[shell-tool-failed]`) or a
-// timeout/abort. bash-tool.mjs emits `Error: [shell-run-failed] [exit code: N]`
-// for a plain non-zero exit; timeout/signal cases carry `[timeout: …]`/
-// `[signal: …]` instead of an `[exit code: …]` marker. Returns the numeric
-// exit code (>= 0) for a command-exit, or null otherwise.
+// timeout/abort. New results use bare `[exit code: N]`; legacy transcripts may
+// use `Error: [shell-run-failed] [exit code: N]`. Persistent shell results can
+// prefix `[session: …]`. Returns the numeric exit code, or null otherwise.
 export function shellCommandExitCode(text) {
   const body = String(text || '');
-  // Anchor to the START of the result so a success/non-shell body that merely
-  // QUOTES the marker mid-output is never misclassified. bash-tool emits
-  // `Error: [shell-run-failed] [exit code: N]` as the leading marker header.
-  if (!/^\s*(?:Error:\s*)?\[shell-run-failed\]/i.test(body)) return null;
-  // Restrict marker parsing to the header region (first line) so only the
-  // session runtime-emitted status header — not quoted command output below — counts.
-  const header = body.split('\n', 1)[0] || '';
+  const header = body.split('\n').slice(0, 3).join('\n');
   // Timeout / signal / abort are NOT a plain command exit — keep them "Failed".
   if (/\[timeout:|\[signal:|timed out|aborted|interrupted/i.test(header)) return null;
-  const m = header.match(/\[exit code:\s*(\d+)\]/i);
+  const m = header.match(/^\s*(?:\[session:[^\n]*\]\s*\n)?(?:Error:\s*)?(?:\[shell-run-failed\]\s*)?\[exit code:\s*(\d+)\]/i);
   if (!m) return null;
   const code = Number(m[1]);
   return Number.isFinite(code) ? code : null;

package/src/tui/session/tool-result-text.mjs

@@ -126,11 +126,13 @@ export function toolErrorDisplay(value, surface = 'tool') {
 }
 
 // Display-only: a command-exit card already renders `Exit N` as its state, so
-// the machine header (`Error: [shell-run-failed] [exit code: N]`) is redundant
-// in the body — and the bare word "Error" reads as a tool failure even though
-// the tool ran fine and the command merely exited non-zero. The model-facing
-// result keeps the header untouched; only the rendered body drops it.
+// the machine header (`[exit code: N]`, or its legacy shell-run-failed form) is
+// redundant in the body. The model-facing result keeps it; only display drops
+// the header and explanatory completion note.
 export function stripShellExitHeader(text) {
   const body = String(text ?? '');
-  return body.replace(/(^|\n)(?:Error:\s*)?\[shell-run-failed\][^\n]*\n{0,2}/i, '$1');
+  return body.replace(
+    /(^|\n)(?:(?:Error:\s*)?\[shell-run-failed\]\s*)?\[exit code:\s*\d+\][^\n]*\n{0,2}(?:\[completed:[^\n]*\]\n{0,2})?/i,
+    '$1',
+  );
 }