@yagni-app/code-staging 1.2.13-staging.2196.1 → 1.2.13-staging.2198.1

package/dist/extension/index.js

@@ -48,6 +48,7 @@ import { createGrantCensus } from "./permission/grantCensus.js";
 import { runsInSandboxHarness, toolchainBashToolDefinition, toolchainSpawnHookFromEnv, toolchainUserBashOperations, } from "./toolchain/spawnHook.js";
 import { CLOUD_SESSION_ENV } from "./pipeline/cloud.js";
 import { registerStageClock } from "./pipeline/stageClock.js";
+import { registerBashDefaultTimeout } from "./toolchain/bashDefaultTimeout.js";
 import { scrubSecrets } from "./pipeline/scrubSecrets.js";
 import { registerTelemetry as defaultRegisterTelemetry } from "./telemetry/register.js";
 import { loadHooksConfig, makeHookRunner, registerHooks } from "./hooks.js";
@@ -176,6 +177,9 @@ export async function registerYagni(pi, deps = {}) {
     // not matter: pi runs every tool_call handler until one blocks, and an allow
     // (a result without `block`) never ends the loop, so this block always lands.
     registerStageClock(pi, env, now);
+    // A sandbox session's bash call without a timeout gets a default one, so a
+    // command that never exits cannot hold the session. It never blocks.
+    registerBashDefaultTimeout(pi, env);
     // The grounding settings switch (the judgment-loop kill switch): resolved
     // ONCE at boot from the USER-tier config (default on; a malformed config
     // fails soft to on with a sink warn). Eval mode is its own carve-out and

package/dist/extension/toolchain/bashDefaultTimeout.d.ts

@@ -0,0 +1,25 @@
+/**
+ * A default timeout for bash in a sandbox session. Pi's bash has none, so a
+ * command that never exits (a server, an interactive prompt) holds the whole
+ * session until an outer clock stops it. A rails build session on staging
+ * went quiet for 35 minutes after one such call (YAG-1130).
+ */
+import { type ExtensionAPI } from "@earendil-works/pi-coding-agent";
+/**
+ * Ten minutes: long enough for an install or a test suite, short enough that a
+ * command that never exits does not hold the session. The model can pass a
+ * longer `timeout`, and pi's timed-out result tells it so.
+ */
+export declare const SANDBOX_BASH_TIMEOUT_SECONDS = 600;
+/**
+ * Give every bash call without a positive timeout the default one. pi's bash
+ * treats 0 as no timeout, so 0, negatives and non-numbers get it too; every
+ * positive number the model asked for stays. A background call
+ * (`run_in_background`) is left alone: it returns at once, so it cannot hold
+ * the session, and the sandbox's background job (`sandbox/session.ts`) kills
+ * the job when its timeout runs out, which would stop a backgrounded server.
+ * It never blocks. A developer's own terminal (no sandbox harness) gets
+ * nothing.
+ */
+export declare function registerBashDefaultTimeout(pi: Pick<ExtensionAPI, "on">, env: NodeJS.ProcessEnv, seconds?: number): void;
+//# sourceMappingURL=bashDefaultTimeout.d.ts.map

package/dist/extension/toolchain/bashDefaultTimeout.js

@@ -0,0 +1,40 @@
+/**
+ * A default timeout for bash in a sandbox session. Pi's bash has none, so a
+ * command that never exits (a server, an interactive prompt) holds the whole
+ * session until an outer clock stops it. A rails build session on staging
+ * went quiet for 35 minutes after one such call (YAG-1130).
+ */
+import { isToolCallEventType } from "@earendil-works/pi-coding-agent";
+import { runsInSandboxHarness } from "./spawnHook.js";
+/**
+ * Ten minutes: long enough for an install or a test suite, short enough that a
+ * command that never exits does not hold the session. The model can pass a
+ * longer `timeout`, and pi's timed-out result tells it so.
+ */
+export const SANDBOX_BASH_TIMEOUT_SECONDS = 600;
+/**
+ * Give every bash call without a positive timeout the default one. pi's bash
+ * treats 0 as no timeout, so 0, negatives and non-numbers get it too; every
+ * positive number the model asked for stays. A background call
+ * (`run_in_background`) is left alone: it returns at once, so it cannot hold
+ * the session, and the sandbox's background job (`sandbox/session.ts`) kills
+ * the job when its timeout runs out, which would stop a backgrounded server.
+ * It never blocks. A developer's own terminal (no sandbox harness) gets
+ * nothing.
+ */
+export function registerBashDefaultTimeout(pi, env, seconds = SANDBOX_BASH_TIMEOUT_SECONDS) {
+    if (!runsInSandboxHarness(env))
+        return;
+    pi.on("tool_call", async (event) => {
+        if (!isToolCallEventType("bash", event))
+            return undefined;
+        const input = event.input;
+        if (input.run_in_background === true)
+            return undefined;
+        if (typeof input.timeout === "number" && input.timeout > 0)
+            return undefined;
+        event.input.timeout = seconds;
+        return undefined;
+    });
+}
+//# sourceMappingURL=bashDefaultTimeout.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yagni-app/code-staging",
-  "version": "1.2.13-staging.2196.1",
+  "version": "1.2.13-staging.2198.1",
   "description": "YAGNI Code: a terminal coding agent that already knows your company. One YAGNI login routes the model and grounds the agent in your team's context.",
   "license": "SEE LICENSE IN LICENSE.md",
   "author": "YAGNI, Inc. <jack@yagni.app> (https://yagni.app)",
@@ -58,5 +58,5 @@
     "turndown": "^7.2.4",
     "typebox": "^1.3.15"
   },
-  "yagniSourceSha": "c0c70b535de32727cd574cd8c4eedc460601ff76"
+  "yagniSourceSha": "a784a903593e5a0174b06dff4e34cc21fff4be4b"
 }