@cat-factory/executor-harness 1.88.0 → 1.92.0

package/dist/pi.js

@@ -4,10 +4,11 @@ import { homedir } from 'node:os';
 import { dirname, join } from 'node:path';
 import { killChildProcess, spawnDetached } from './process.js';
 import { pathExists } from './fs-utils.js';
-import { redactSecrets } from './redact.js';
+import { redactSecrets, secretsToRedact } from './redact.js';
 import { HarnessFailure } from './failure.js';
 import { log } from './logger.js';
 import { ProgressGuard, progressGuardLimitsFromEnv, toolCallSignal, } from './progress-guard.js';
+import { ToolCallTracker, readToolCallId, toolCallResult, toolCallStart, } from './tool-trajectory.js';
 // Drives the Pi coding-agent CLI. Pi is pointed at the Worker's OpenAI-compatible
 // proxy via a custom provider in ~/.pi/agent/models.json, authenticated with the
 // per-job session token (interpolated from $PI_PROXY_TOKEN) — so no provider key
@@ -606,10 +607,17 @@ export function runPi(opts) {
         let malformedLines = 0;
         let observerErrors = 0;
         const guard = new ProgressGuard(opts.guardLimits ?? progressGuardLimitsFromEnv(), opts.expectsEdits ?? true);
-        // Start boundary for the next tool span: each tool's slice runs from the previous
-        // tool's end (or the run start) to its own `tool_execution_end`. Approximate but
-        // contiguous — enough for the trace tree, and metadata-only.
-        let toolBoundary = Date.now();
+        // Pairs each tool call's start with its result, numbers the pairs and captures the two
+        // bodies (scrubbed + capped). A call whose start Pi never emitted still gets an entry,
+        // timed from the previous call's end — see `ToolCallTracker`.
+        //
+        // The known-secret list is DERIVED from the token this function itself hands the child
+        // (`PI_PROXY_TOKEN` / `SEARXNG_API_KEY`) rather than taken as a parameter: the bodies
+        // travel to a store and to external trace sinks, and a caller that forgets to pass the
+        // list produces bodies scrubbed of credential SHAPES only, with no signal that the
+        // narrower rule ever ran. Deriving it here means the one place that knows the child's
+        // credentials is the place that scrubs them.
+        const tools = new ToolCallTracker(secretsToRedact(opts.sessionToken));
         // SIGTERM first, then SIGKILL if Pi ignores it. Shared by the watchdog abort
         // and the no-progress guard; the `close` handler turns it into a rejection.
         const killChild = () => killChildProcess(child);
@@ -648,22 +656,19 @@ export function runPi(opts) {
                     opts.onProgress(progress);
             }
             if (opts.onSpan) {
+                const start = toolCallStart(event);
+                if (start)
+                    tools.started(start.id, start.name, start.args);
                 const signal = toolCallSignal(event);
                 if (signal && signal.name) {
-                    const endedAt = Date.now();
+                    const call = tools.finished(readToolCallId(event), signal.name, toolCallResult(event), signal.isError);
                     try {
-                        opts.onSpan({
-                            tool: signal.name,
-                            startedAt: toolBoundary,
-                            endedAt,
-                            ok: !signal.isError,
-                        });
+                        opts.onSpan({ ...call, bodies: 'stored' });
                     }
                     catch {
                         // A faulty observer must never break the run.
                         observerErrors++;
                     }
-                    toolBoundary = endedAt;
                 }
             }
             if (runGuard && !guardReason && !aborted) {

package/dist/progress-guard.d.ts

@@ -35,11 +35,38 @@ export interface ProgressGuardLimits {
      * without it.
      */
     maxConsecutiveWebCalls?: number;
+    /**
+     * Abort after this many consecutive MCP tool-server calls (`mcp__*`) with no other
+     * tool call in between: the tool-server analogue of `maxConsecutiveWebCalls`, and
+     * present for the same reason. An `mcp__*` call is exempt from the no-edit bound (see
+     * `isMcpToolCall`), so without a streak of its own a run could query a tool server
+     * indefinitely without tripping any guard. Any non-MCP tool call resets the streak.
+     * Optional: defaults to {@link DEFAULT_PROGRESS_GUARD_LIMITS}.
+     */
+    maxConsecutiveMcpCalls?: number;
+    /**
+     * Abort after this many consecutive calls that are EXEMPT from the no-edit bound
+     * (planning, read-only exploration, subagent dispatch, `mcp__*`) with no action call
+     * in between. The backstop that makes each individual exemption mean "not counted"
+     * rather than "unbounded": every per-family streak above resets on any call outside
+     * its own family, so a run alternating `web_search` with `mcp__issues__search` (or
+     * with `read`) trips none of them and, having never made an action call, never
+     * reaches `maxToolCallsWithoutEdit` either. Only the job's wall-clock ceiling
+     * bounded that.
+     *
+     * Deliberately far above every family cap, because it is not a research bound and
+     * must not become one: reading a hundred files before the first edit is legitimate
+     * work-up, and any `bash`/edit/action call resets the streak. Optional: defaults to
+     * {@link DEFAULT_PROGRESS_GUARD_LIMITS}.
+     */
+    maxConsecutiveNonActionCalls?: number;
 }
 export declare const DEFAULT_PROGRESS_GUARD_LIMITS: {
     maxToolCallsWithoutEdit: number;
     maxConsecutiveErrors: number;
     maxConsecutiveWebCalls: number;
+    maxConsecutiveMcpCalls: number;
+    maxConsecutiveNonActionCalls: number;
 };
 /** Read {@link ProgressGuardLimits} from the environment, falling back to the defaults. */
 export declare function progressGuardLimitsFromEnv(env?: NodeJS.ProcessEnv): ProgressGuardLimits;
@@ -69,6 +96,8 @@ export declare class ProgressGuard {
     private edits;
     private consecutiveErrors;
     private consecutiveWebCalls;
+    private consecutiveMcpCalls;
+    private consecutiveNonActionCalls;
     constructor(limits: ProgressGuardLimits, 
     /** When false (assess-only runs like the merger), the no-edit bound is skipped. */
     expectsEdits?: boolean);

package/dist/progress-guard.js

@@ -28,6 +28,16 @@ export const DEFAULT_PROGRESS_GUARD_LIMITS = {
     // A genuine research burst is a handful of searches; an uninterrupted run of this
     // many web calls (with no read/edit/bash between) is a search loop, not progress.
     maxConsecutiveWebCalls: 25,
+    // Looser than the web cap: a tool server is usually the agent's route to the SYSTEM OF
+    // RECORD (the issue tracker, the advisory database, the design source), and reading a
+    // list and then each of its items is a normal opening move, not a rabbit-hole. A run
+    // that makes this many in a row with no read, edit or bash between is looping.
+    maxConsecutiveMcpCalls: 40,
+    // Well clear of every family cap above, and of any plausible read-up: a run that makes
+    // this many exempt calls with not one action call between them has stopped converging,
+    // whatever mix of reads, searches and lookups it is cycling through. Sized as a
+    // backstop rather than a judgement, because the families are where judgement belongs.
+    maxConsecutiveNonActionCalls: 200,
 };
 // Tool names that mutate files, so a call to one clears the no-edit suspicion. Kept
 // broad on purpose: different models/extensions name the same capability differently
@@ -98,6 +108,28 @@ const EXPLORATION_TOOLS = new Set([
 // call between) can be caught as a search loop — see `maxConsecutiveWebCalls`. Covers both
 // Pi's `web_search`/`web_fetch` and Claude Code's `WebSearch`/`WebFetch`.
 const WEB_TOOLS = new Set(['web_search', 'web_fetch', 'websearch', 'webfetch']);
+// A call to a tool server (MCP). Every MCP client names these `mcp__<server>__<tool>`, and
+// the prefix is the ONLY thing the harness can know about them: what a given server's tools
+// do is a backend registration this image has never seen, so the guard classifies by shape.
+//
+// Matched, rather than enumerated in EXPLORATION_TOOLS, because the set is open: it is
+// whatever tool servers the running kind was wired with. A prefix test is also why this is a
+// function, `name.startsWith` on the already-lower-cased name, so `MCP__Issues__search`
+// classifies the same as `mcp__issues__search`.
+function isMcpToolCall(loweredName) {
+    return loweredName.startsWith('mcp__');
+}
+// Whether a call is EXEMPT from the no-edit bound: planning and bookkeeping, read-only
+// exploration, a subagent dispatch, or a tool-server call. One predicate rather than the
+// four tests inlined at the branch, because the combined non-action streak and the no-edit
+// exemption must be the SAME set: a family exempted in one place and missed in the other is
+// either an unbounded loop or a run killed for a call the bound says it may make.
+function isNonActionToolCall(loweredName) {
+    return (PLANNING_TOOLS.has(loweredName) ||
+        EXPLORATION_TOOLS.has(loweredName) ||
+        SUBAGENT_DISPATCH_TOOLS.has(loweredName) ||
+        isMcpToolCall(loweredName));
+}
 /** Read {@link ProgressGuardLimits} from the environment, falling back to the defaults. */
 export function progressGuardLimitsFromEnv(env = process.env) {
     const num = (raw, fallback) => {
@@ -108,6 +140,8 @@ export function progressGuardLimitsFromEnv(env = process.env) {
         maxToolCallsWithoutEdit: num(env.JOB_MAX_TOOLCALLS_WITHOUT_EDIT, DEFAULT_PROGRESS_GUARD_LIMITS.maxToolCallsWithoutEdit),
         maxConsecutiveErrors: num(env.JOB_MAX_CONSECUTIVE_TOOL_ERRORS, DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveErrors),
         maxConsecutiveWebCalls: num(env.JOB_MAX_CONSECUTIVE_WEB_CALLS, DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveWebCalls),
+        maxConsecutiveMcpCalls: num(env.JOB_MAX_CONSECUTIVE_MCP_CALLS, DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveMcpCalls),
+        maxConsecutiveNonActionCalls: num(env.JOB_MAX_CONSECUTIVE_NON_ACTION_CALLS, DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveNonActionCalls),
     };
 }
 /**
@@ -127,9 +161,12 @@ export function mergeGuardLimits(base, overrides) {
     return {
         maxToolCallsWithoutEdit: loosen(base.maxToolCallsWithoutEdit, overrides.maxToolCallsWithoutEdit),
         maxConsecutiveErrors: loosen(base.maxConsecutiveErrors, overrides.maxConsecutiveErrors),
-        // `maxConsecutiveWebCalls` is optional on the interface (callers may omit it), so
-        // fall back to the default before loosening — keeps `loosen`'s base a concrete number.
+        // The streak knobs are optional on the interface (callers may omit them), so fall back
+        // to the default before loosening: it keeps `loosen`'s base a concrete number.
         maxConsecutiveWebCalls: loosen(base.maxConsecutiveWebCalls ?? DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveWebCalls, overrides.maxConsecutiveWebCalls),
+        maxConsecutiveMcpCalls: loosen(base.maxConsecutiveMcpCalls ?? DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveMcpCalls, overrides.maxConsecutiveMcpCalls),
+        maxConsecutiveNonActionCalls: loosen(base.maxConsecutiveNonActionCalls ??
+            DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveNonActionCalls, overrides.maxConsecutiveNonActionCalls),
     };
 }
 /**
@@ -146,6 +183,8 @@ export class ProgressGuard {
     edits = 0;
     consecutiveErrors = 0;
     consecutiveWebCalls = 0;
+    consecutiveMcpCalls = 0;
+    consecutiveNonActionCalls = 0;
     constructor(limits, 
     /** When false (assess-only runs like the merger), the no-edit bound is skipped. */
     expectsEdits = true) {
@@ -189,14 +228,49 @@ export class ProgressGuard {
         else {
             this.consecutiveWebCalls = 0;
         }
-        // Planning, read-only exploration and subagent-dispatch calls don't count toward the
-        // no-edit bound (see PLANNING_TOOLS / EXPLORATION_TOOLS / SUBAGENT_DISPATCH_TOOLS) —
-        // only "action" calls without an edit do.
-        if (PLANNING_TOOLS.has(name) ||
-            EXPLORATION_TOOLS.has(name) ||
-            SUBAGENT_DISPATCH_TOOLS.has(name)) {
+        // Tool-server (MCP) calls: bounded as their own streak for exactly the reason the web
+        // streak exists. They are exempt from the no-edit bound below, and an exemption with no
+        // counter-bound is a loop the guard cannot see. Any non-MCP call resets it.
+        if (isMcpToolCall(name)) {
+            this.consecutiveMcpCalls++;
+            const mcpCap = this.limits.maxConsecutiveMcpCalls ?? DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveMcpCalls;
+            if (this.consecutiveMcpCalls >= mcpCap) {
+                return (`no progress: ${this.consecutiveMcpCalls} consecutive tool-server (MCP) calls without ` +
+                    `any other action. The agent is stuck querying its tools instead of doing the work. ` +
+                    `Aborting.`);
+            }
+        }
+        else {
+            this.consecutiveMcpCalls = 0;
+        }
+        // Planning, read-only exploration, subagent-dispatch and tool-server calls don't count
+        // toward the no-edit bound (see `isNonActionToolCall`): only "action" calls without an
+        // edit do.
+        //
+        // An `mcp__*` call is exempt for the same reason a `read` is: the bound targets the
+        // credential rabbit-hole (endless `bash` probing with nothing implemented), and reaching
+        // a registered tool server is the platform TELLING the agent to look something up
+        // ("prefer them over guessing"). Counting them would abort an edits-expected kind for
+        // consulting the issue tracker the deployment wired for it, punishing the run for
+        // following its own prompt. They are neutral rather than edit-satisfying, exactly like a
+        // subagent dispatch: a read-only lookup must not clear the suspicion the bound holds.
+        //
+        // The exempt calls carry ONE streak of their own, and it is what keeps every exemption
+        // above from adding up to an unbounded run: each per-family cap resets on any call
+        // outside its family, so alternating two exempt families trips neither, and a run that
+        // never makes an action call never reaches the no-edit bound either.
+        if (isNonActionToolCall(name)) {
+            this.consecutiveNonActionCalls++;
+            const nonActionCap = this.limits.maxConsecutiveNonActionCalls ??
+                DEFAULT_PROGRESS_GUARD_LIMITS.maxConsecutiveNonActionCalls;
+            if (this.consecutiveNonActionCalls >= nonActionCap) {
+                return (`no progress: ${this.consecutiveNonActionCalls} consecutive read-only calls (searching, ` +
+                    `reading, tool-server lookups, subagent dispatches) with no action call between them. ` +
+                    `The agent is cycling through research instead of doing the work. Aborting.`);
+            }
             return null;
         }
+        this.consecutiveNonActionCalls = 0;
         this.toolCalls++;
         if (FILE_EDIT_TOOLS.has(name))
             this.edits++;

package/dist/tool-trajectory.d.ts

@@ -0,0 +1,78 @@
+/** Cap on a captured argument blob. Generous for a command line, far below a file body. */
+export declare const MAX_TOOL_ARGS_CHARS: number;
+/** Cap on a captured result. Larger than the args cap: a result is where the bytes actually are. */
+export declare const MAX_TOOL_RESULT_CHARS: number;
+/** A captured body plus what the cap dropped from it. */
+export interface CapturedToolBody {
+    text: string;
+    dropped: number;
+}
+/**
+ * Serialise, scrub and cap one tool body.
+ *
+ * A non-string value is JSON-serialised, and a value that cannot be (a cycle, a `BigInt`, a
+ * throwing getter) is NAMED as unserialisable rather than dropped to `''`: an empty body means
+ * "the call carried none", and a capture failure is a different fact.
+ */
+export declare function captureToolBody(value: unknown, max: number, secrets: readonly string[]): CapturedToolBody;
+/** What {@link ToolCallTracker} emits per completed call — the fields a `ToolSpan` needs. */
+export interface TrackedToolCall {
+    tool: string;
+    seq: number;
+    startedAt: number;
+    endedAt: number;
+    ok: boolean;
+    args: string;
+    result: string;
+    argsDropped: number;
+    resultDropped: number;
+}
+/**
+ * Pairs each tool call's START with its RESULT and numbers the pairs, so the two agent CLIs feed
+ * one trajectory shape from two very different streams (Pi's flat `tool_execution_*` events, the
+ * claude-code stream's `tool_use` / `tool_result` content blocks).
+ *
+ * Correlation is BY ID where the stream supplies one, and by tool name otherwise, because that is
+ * the difference between the two producers: claude-code's blocks always carry a `tool_use_id`, and
+ * a parallel batch of calls is routine there, while Pi's stream is sequential. A result the tracker
+ * cannot pair with a start is still EMITTED (with no args and the previous call's end as its
+ * start): losing a step of the trajectory to a schema tweak would be worse than an entry that says
+ * less than its neighbours, and the `seq` it takes keeps every later entry's ordinal honest.
+ */
+export declare class ToolCallTracker {
+    private readonly secrets;
+    private seq;
+    private readonly byId;
+    private readonly byTool;
+    /**
+     * Start boundary for a call whose own start was never seen: the previous call's end, or the run
+     * start. Approximate but contiguous, which is the property the trace tree needs.
+     */
+    private boundary;
+    constructor(secrets?: readonly string[], now?: number);
+    /** Record that a call began, with the arguments the agent supplied. */
+    started(id: string | undefined, tool: string, args: unknown, at?: number): void;
+    /** Record that a call finished, and return the completed entry. */
+    finished(id: string | undefined, tool: string, result: unknown, isError: boolean, at?: number): TrackedToolCall;
+    private take;
+}
+/** Read a tool-call id off a stream event, whatever the producer calls it. */
+export declare function readToolCallId(event: Record<string, unknown>): string | undefined;
+/** A tool call BEGINNING, read off a Pi `--mode json` event, or undefined if it isn't one. */
+export declare function toolCallStart(event: Record<string, unknown>): {
+    id?: string;
+    name: string;
+    args: unknown;
+} | undefined;
+/** The RESULT payload of a Pi `tool_execution_end` event, unwrapped from its envelope. */
+export declare function toolCallResult(event: Record<string, unknown>): unknown;
+/**
+ * Feed one claude-code `user` turn's content blocks to the tracker, emitting an entry per
+ * `tool_result`.
+ *
+ * The CLI answers each `tool_use` with a `tool_result` carrying the same `tool_use_id`, so the
+ * pairing is exact even when the model fired a batch of calls in parallel — which it routinely
+ * does, and which is why the trajectory here is ordered by the ordinal the tracker stamps rather
+ * than by the turn the results arrived on.
+ */
+export declare function recordClaudeToolResults(tracker: ToolCallTracker, content: readonly unknown[], emit: (call: TrackedToolCall) => void): void;

package/dist/tool-trajectory.js

@@ -0,0 +1,194 @@
+import { redact } from './redact.js';
+// The TRAJECTORY capture: what the agent DID, one entry per tool call, in the order it made them.
+//
+// The harness has always buffered a compact span per tool call (name + timing + ok) for the run's
+// trace. That is enough to draw a tree and not enough to answer the question anyone actually asks
+// of a finished run — WHICH command, against WHAT, and what came back. The evidence standard for a
+// merged PR is "how, not just the diff", and a span saying `bash` ran for 300ms is not evidence of
+// anything. So each entry now carries the call's arguments and result, captured here because this
+// is the only process that ever sees them: an agent CLI's tool loop is internal to the CLI, and
+// the container is gone the moment the job settles.
+//
+// Two properties keep that affordable and safe:
+//
+//  - **Bounded at capture.** Each body is capped (a build log is routinely megabytes) and the entry
+//    STATES what the cap dropped, so a reader can tell a short command from the head of a long one.
+//    The caps are what keep the drain buffer and the poll response small.
+//  - **Scrubbed at capture.** A tool's arguments and output routinely echo an env var, a clone URL
+//    or the leased subscription token, and these travel to a store and to external trace sinks.
+//
+// The RETENTION decision is the backend's, not this module's: entries carry `bodies: 'stored'` and
+// the backend's double gate (`LLM_RECORD_PROMPTS` + the workspace's `storeAgentContext`) decides
+// whether to keep them, exactly as it already does for the prompt bodies the call-metric
+// reconstruction assembles here. Deciding it twice would mean the container had to be told the
+// workspace's settings, and an image one release behind its backend would then be deciding it with
+// stale ones.
+/** Cap on a captured argument blob. Generous for a command line, far below a file body. */
+export const MAX_TOOL_ARGS_CHARS = 2 * 1024;
+/** Cap on a captured result. Larger than the args cap: a result is where the bytes actually are. */
+export const MAX_TOOL_RESULT_CHARS = 4 * 1024;
+const EMPTY = { text: '', dropped: 0 };
+/**
+ * Serialise, scrub and cap one tool body.
+ *
+ * A non-string value is JSON-serialised, and a value that cannot be (a cycle, a `BigInt`, a
+ * throwing getter) is NAMED as unserialisable rather than dropped to `''`: an empty body means
+ * "the call carried none", and a capture failure is a different fact.
+ */
+export function captureToolBody(value, max, secrets) {
+    if (value === undefined || value === null)
+        return EMPTY;
+    let text;
+    if (typeof value === 'string') {
+        text = value;
+    }
+    else {
+        try {
+            text = JSON.stringify(value) ?? '';
+        }
+        catch {
+            return { text: '[unserialisable]', dropped: 0 };
+        }
+    }
+    if (text === '')
+        return EMPTY;
+    const scrubbed = redact(text, secrets);
+    if (scrubbed.length <= max)
+        return { text: scrubbed, dropped: 0 };
+    return { text: scrubbed.slice(0, max), dropped: scrubbed.length - max };
+}
+/**
+ * Pairs each tool call's START with its RESULT and numbers the pairs, so the two agent CLIs feed
+ * one trajectory shape from two very different streams (Pi's flat `tool_execution_*` events, the
+ * claude-code stream's `tool_use` / `tool_result` content blocks).
+ *
+ * Correlation is BY ID where the stream supplies one, and by tool name otherwise, because that is
+ * the difference between the two producers: claude-code's blocks always carry a `tool_use_id`, and
+ * a parallel batch of calls is routine there, while Pi's stream is sequential. A result the tracker
+ * cannot pair with a start is still EMITTED (with no args and the previous call's end as its
+ * start): losing a step of the trajectory to a schema tweak would be worse than an entry that says
+ * less than its neighbours, and the `seq` it takes keeps every later entry's ordinal honest.
+ */
+export class ToolCallTracker {
+    secrets;
+    seq = 0;
+    byId = new Map();
+    byTool = new Map();
+    /**
+     * Start boundary for a call whose own start was never seen: the previous call's end, or the run
+     * start. Approximate but contiguous, which is the property the trace tree needs.
+     */
+    boundary;
+    constructor(secrets = [], now = Date.now()) {
+        this.secrets = secrets;
+        this.boundary = now;
+    }
+    /** Record that a call began, with the arguments the agent supplied. */
+    started(id, tool, args, at = Date.now()) {
+        const pending = {
+            tool,
+            startedAt: at,
+            args: captureToolBody(args, MAX_TOOL_ARGS_CHARS, this.secrets),
+        };
+        if (id) {
+            this.byId.set(id, pending);
+            return;
+        }
+        const queue = this.byTool.get(tool) ?? [];
+        queue.push(pending);
+        this.byTool.set(tool, queue);
+    }
+    /** Record that a call finished, and return the completed entry. */
+    finished(id, tool, result, isError, at = Date.now()) {
+        const pending = this.take(id, tool);
+        const captured = captureToolBody(result, MAX_TOOL_RESULT_CHARS, this.secrets);
+        const call = {
+            tool: pending?.tool ?? tool,
+            seq: this.seq++,
+            startedAt: pending?.startedAt ?? this.boundary,
+            endedAt: at,
+            ok: !isError,
+            args: pending?.args.text ?? '',
+            argsDropped: pending?.args.dropped ?? 0,
+            result: captured.text,
+            resultDropped: captured.dropped,
+        };
+        this.boundary = at;
+        return call;
+    }
+    take(id, tool) {
+        if (id) {
+            const byId = this.byId.get(id);
+            if (byId) {
+                this.byId.delete(id);
+                return byId;
+            }
+        }
+        const queue = this.byTool.get(tool);
+        // FIFO, so a sequential stream pairs each result with the call that opened first. A stream
+        // that interleaves un-idded calls of one tool would mis-pair here; none of the two producers
+        // does, and the alternative (refusing to pair at all) loses the args on every ordinary run.
+        const pending = queue?.shift();
+        if (queue && queue.length === 0)
+            this.byTool.delete(tool);
+        return pending;
+    }
+}
+/** Read a tool-call id off a stream event, whatever the producer calls it. */
+export function readToolCallId(event) {
+    for (const key of ['toolCallId', 'tool_call_id', 'callId', 'id']) {
+        const value = event[key];
+        if (typeof value === 'string' && value !== '')
+            return value;
+    }
+    return undefined;
+}
+/** A tool call BEGINNING, read off a Pi `--mode json` event, or undefined if it isn't one. */
+export function toolCallStart(event) {
+    if (event.type !== 'tool_execution_start' && event.type !== 'tool_call')
+        return undefined;
+    const name = typeof event.toolName === 'string' ? event.toolName : '';
+    if (!name)
+        return undefined;
+    // Read every spelling the stream might use rather than pinning one: Pi's event schema has been
+    // renamed under us before (see `todoResultDetails`, which reads three shapes of one result), and
+    // a rename here costs the ARGUMENTS of every call, silently.
+    const args = event.args ?? event.arguments ?? event.input ?? event.parameters;
+    const id = readToolCallId(event);
+    return { name, args, ...(id ? { id } : {}) };
+}
+/** The RESULT payload of a Pi `tool_execution_end` event, unwrapped from its envelope. */
+export function toolCallResult(event) {
+    const result = event.result;
+    if (result && typeof result === 'object') {
+        const inner = result;
+        // `details` is the structured payload Pi's own extensions return (the todo tool's shape), and
+        // `content`/`output` the free-text ones. Falling back to the whole envelope keeps a shape none
+        // of these match readable rather than empty.
+        return inner.details ?? inner.content ?? inner.output ?? result;
+    }
+    return result ?? event.output ?? event.content;
+}
+/**
+ * Feed one claude-code `user` turn's content blocks to the tracker, emitting an entry per
+ * `tool_result`.
+ *
+ * The CLI answers each `tool_use` with a `tool_result` carrying the same `tool_use_id`, so the
+ * pairing is exact even when the model fired a batch of calls in parallel — which it routinely
+ * does, and which is why the trajectory here is ordered by the ordinal the tracker stamps rather
+ * than by the turn the results arrived on.
+ */
+export function recordClaudeToolResults(tracker, content, emit) {
+    for (const block of content) {
+        if (!block || typeof block !== 'object')
+            continue;
+        const record = block;
+        if (record.type !== 'tool_result')
+            continue;
+        const id = typeof record.tool_use_id === 'string' ? record.tool_use_id : undefined;
+        // The block carries no tool NAME (only the id the assistant turn named), so an unpaired
+        // result falls back to a stated placeholder rather than an empty string that would render
+        // as a nameless step.
+        emit(tracker.finished(id, 'unknown', record.content, record.is_error === true));
+    }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cat-factory/executor-harness",
-  "version": "1.88.0",
+  "version": "1.92.0",
   "description": "Container payload: a thin TypeScript wrapper that runs the Pi coding agent against a cloned repo and opens a PR. Runs in the Cloudflare Container (and, in local native mode, as a host process); carries no secrets.",
   "repository": {
     "type": "git",
@@ -30,9 +30,9 @@
     "hono": "^4.12.33",
     "typescript": "7.0.2",
     "vitest": "^4.1.10",
-    "@cat-factory/kernel": "0.215.0",
-    "@cat-factory/server": "0.195.0",
-    "@cat-factory/spend": "0.13.2"
+    "@cat-factory/kernel": "0.236.0",
+    "@cat-factory/server": "0.215.0",
+    "@cat-factory/spend": "0.14.14"
   },
   "scripts": {
     "build": "tsc -p tsconfig.json",

package/src/agent-capabilities.ts

@@ -178,6 +178,20 @@ function sanitizeServerId(value: unknown): string | undefined {
   return MCP_SERVER_ID_PATTERN.test(value) ? value : undefined
 }
 
+/**
+ * A tool name an `allowedTools` entry may name. Kept byte-identical to kernel's
+ * `MCP_TOOL_NAME_PATTERN` for the same reason {@link MCP_SERVER_ID_PATTERN} is a copy, and pinned
+ * against it by `test/agent-capabilities.conformity.test.ts`.
+ *
+ * The comma is the reason the rule exists on THIS side of the boundary too:
+ * {@link claudeAllowedToolPatterns} builds the list that the runner joins into one
+ * `--allowedTools` argument with commas, so an entry carrying one splits into two patterns of which
+ * the second matches no tool the CLI has. Dropped rather than passed through, because the entries
+ * that survive are what narrows the session: a bad one would silently take the run's whole MCP
+ * surface with it.
+ */
+export const MCP_TOOL_NAME_PATTERN = /^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$/
+
 /**
  * Whether an HTTP tool server's URL may be started. Mirrors kernel's `isAllowedMcpHttpUrl` (see
  * {@link MCP_SERVER_ID_PATTERN} for why it is a copy, and the conformity suite that pins it):
@@ -219,13 +233,25 @@ function parseStringArray(value: unknown): string[] | undefined {
   return out.length ? out : undefined
 }
 
+/**
+ * The `allowedTools` list: string entries that are single tool NAMES (see
+ * {@link MCP_TOOL_NAME_PATTERN}). Undefined when nothing survives, which is the same answer as an
+ * absent field (every tool the server exposes) and the right one: the alternative is a list whose
+ * only surviving entries are the platform's own built-in tool names, i.e. a run narrowed to no MCP
+ * tools at all. The backend refuses these at registration; this is the boundary check.
+ */
+function parseAllowedTools(value: unknown): string[] | undefined {
+  const names = parseStringArray(value)?.filter((name) => MCP_TOOL_NAME_PATTERN.test(name))
+  return names?.length ? names : undefined
+}
+
 /** Validate one `mcpServers` entry, or undefined when malformed for its transport. */
 function parseMcpServerSpec(value: unknown): McpServerSpec | undefined {
   if (typeof value !== 'object' || value === null) return undefined
   const o = value as Record<string, unknown>
   const id = sanitizeServerId(o.id)
   if (!id) return undefined
-  const allowedTools = parseStringArray(o.allowedTools)
+  const allowedTools = parseAllowedTools(o.allowedTools)
   const secretKeys = parseStringArray(o.secretKeys)
   if (o.transport === 'http') {
     // https anywhere, plain http only on loopback: the CLI would happily be pointed at a
@@ -370,9 +396,13 @@ function tomlString(value: string): string {
 
 /**
  * The `[mcp_servers.<id>]` TOML block Codex reads from its `CODEX_HOME/config.toml`. Codex's MCP
- * client is stdio-only, so an `http` server is skipped here — the backend states such a server as
- * unavailable when it declares `harnesses: ['claude-code']`, and a deployment that wires an HTTP
- * server for Codex gets a no-op rather than a malformed config.
+ * client is stdio-only, so an `http` server is skipped here.
+ *
+ * The skip is now a BACKSTOP rather than the decision: the backend knows which transports each
+ * harness reaches (`MCP_HARNESS_TRANSPORTS`) and drops an `http` server from a Codex dispatch under
+ * its own `transport_unsupported` reason, so the prompt states the gap instead of advertising a tool
+ * this writer then silently omitted. It stays because a body that reached the container by any other
+ * route must still produce a valid config rather than a malformed one.
  */
 export function codexMcpConfigToml(servers: McpServerSpec[]): string {
   const blocks: string[] = []