@skrr-ai/cli 0.1.27 → 0.1.29

package/dist/lib/sky-code.js

@@ -17,7 +17,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
     return (mod && mod.__esModule) ? mod : { "default": mod };
 };
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.DEDICATED_RUNTIME_ENGINE_MESSAGE = exports.DEDICATED_WORKLOAD_UID_ENV = exports.ENGINE_PATH_ENV = void 0;
+exports.ENGINE_START_REFUSED_EXIT_CODE = exports.EngineStartRefusedError = exports.DEDICATED_RUNTIME_ENGINE_MESSAGE = exports.DEDICATED_WORKLOAD_UID_ENV = exports.ENGINE_PATH_ENV = void 0;
 exports.engineHome = engineHome;
 exports.skyCodeInstructionHome = skyCodeInstructionHome;
 exports.managedEnginePath = managedEnginePath;
@@ -36,6 +36,7 @@ const node_fs_1 = require("node:fs");
 const node_os_1 = require("node:os");
 const node_path_1 = __importDefault(require("node:path"));
 const auth_core_1 = require("@skrr-ai/auth-core");
+const inference_broker_1 = require("@skrr-ai/inference-broker");
 const config_1 = require("./config");
 // Deliberately does NOT import the managed marker any more. This module used to
 // read it to decide whether a run was managed; that decision now arrives as a
@@ -263,7 +264,7 @@ exports.DEDICATED_RUNTIME_ENGINE_MESSAGE = 'On a Dedicated Runtime, coding engin
 function notInstalledMessage(env = process.env) {
     if (isDedicatedRuntimeWorkload(env)) {
         return [
-            'The skrr Code engine (`sky-code`) is not on this machine.',
+            'The skrr Code engine is not on this machine.',
             '',
             exports.DEDICATED_RUNTIME_ENGINE_MESSAGE,
             'This machine was built from an image without it; it arrives when the',
@@ -287,6 +288,41 @@ function notInstalledMessage(env = process.env) {
         'for a published release.',
     ].join('\n');
 }
+/**
+ * OSK-8822 — the run was REFUSED before the engine started.
+ *
+ * `prepare` used to have exactly one way to answer: an env map, where `{}` means
+ * "run on the operator's own credentials". So when the server refused the
+ * ACCOUNT — a plan allowance used up, a model the plan does not include — the
+ * refusal could only become a BYOK run, and the engine started with no
+ * credential and failed a second time with a generic error, exiting with the
+ * same `1` as a task that ran and failed.
+ *
+ * A distinct type rather than a sentinel env, so the one outcome that must stop
+ * the run cannot be produced by accident and cannot be mistaken for an ordinary
+ * `prepare` failure. Whoever throws it has already told the user why: it is a
+ * control signal, and its message is for logs, not for printing a second time.
+ */
+class EngineStartRefusedError extends Error {
+    /** The refusal's machine-readable code, e.g. `plan-allowance-exhausted`. */
+    code;
+    constructor(code, message) {
+        super(message);
+        this.name = 'EngineStartRefusedError';
+        this.code = code;
+    }
+}
+exports.EngineStartRefusedError = EngineStartRefusedError;
+/**
+ * The exit code of a refused run: sysexits' `EX_NOPERM`, the one that means
+ * "not permitted" rather than "not available".
+ *
+ * CLI-owned, like `127` for a missing engine, because nothing ran to report one.
+ * It has to differ from `1`, which is what an engine that started and failed
+ * reports — the production case this exists for exited `1`, and CI could not tell
+ * "your plan refused this" from "the task failed".
+ */
+exports.ENGINE_START_REFUSED_EXIT_CODE = 77;
 /**
  * Credential-shaped variables the engine may inherit as its OWN model credential.
  *
@@ -468,11 +504,20 @@ function engineSpawnEnv(env, extraEnv,
 // Required, not defaulted: the safe value differs per call and a parameter that
 // can be forgotten on a security boundary will be.
 mode) {
-    return {
+    const spawnEnv = {
         ...(0, auth_core_1.sanitizeSpawnEnv)(env),
         ...(mode === 'managed' ? {} : inheritedProviderCredentials(env)),
         ...extraEnv,
     };
+    if (mode !== 'managed')
+        return spawnEnv;
+    // OSK-8758 — a managed engine reaches the broker at a synthetic host, and must
+    // never address that host to a proxy. Behind an egress proxy (a Dedicated
+    // Runtime guest) Bun wrote every broker request in proxy form, and a runtime
+    // that honoured the proxy over the socket would send the prompt to it. Layered
+    // over the env built above, so it extends whatever list the engine would
+    // otherwise have received rather than replacing it.
+    return { ...spawnEnv, ...(0, inference_broker_1.inferenceBrokerNoProxyEnv)(spawnEnv) };
 }
 async function execEngine(args, env = process.env, options = {}) {
     // Resolve the binary FIRST, before `prepare` runs.
@@ -483,15 +528,18 @@ async function execEngine(args, env = process.env, options = {}) {
     const { path: bin } = resolveEngine(env);
     if (!bin)
         throw new Error('sky-code-not-installed');
-    const extraEnv = options.prepare ? await options.prepare() : {};
-    // A copy, so a hook cannot mutate the caller's array as a side effect.
-    const spawnArgs = options.finalizeArgs ? options.finalizeArgs([...args]) : args;
     // Assumed until the spawn tells us otherwise, so a teardown that runs after a
     // spawn ERROR does not claim the run was interrupted.
     const outcome = { interrupted: false };
-    // Read AFTER `prepare`, because that is when the hook knows what it acquired.
-    const mode = options.credentialMode?.() ?? 'byok';
     try {
+        // Inside the `try`, so a `prepare` that refuses the run (OSK-8822) — or one
+        // that acquired something and then threw — still reaches `cleanup`. Rejecting
+        // is how a hook stops the run: nothing below it, the spawn included, runs.
+        const extraEnv = options.prepare ? await options.prepare() : {};
+        // A copy, so a hook cannot mutate the caller's array as a side effect.
+        const spawnArgs = options.finalizeArgs ? options.finalizeArgs([...args]) : args;
+        // Read AFTER `prepare`, because that is when the hook knows what it acquired.
+        const mode = options.credentialMode?.() ?? 'byok';
         return await spawnEngine(bin, spawnArgs, env, extraEnv, mode, outcome);
     }
     finally {

package/dist/lib/task-instruction-offer.js

@@ -2,6 +2,8 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.maybeOfferTaskManagementInstructions = maybeOfferTaskManagementInstructions;
 const data_provider_1 = require("@skrr-ai/data-provider");
+const config_1 = require("./config");
+const daemon_target_1 = require("./daemon-target");
 const prompt_1 = require("./prompt");
 const TEMPLATE_KEY = 'oversky-task-management';
 function capabilitiesOf(daemon) {
@@ -64,11 +66,21 @@ async function maybeOfferTaskManagementInstructions(log) {
     if (shouldSkipOffer())
         return;
     try {
+        // The offer speaks of "this machine", so on a Dedicated Runtime guest only the
+        // guest's own daemon may be the candidate — never the first eligible row of the
+        // account, which is the owner's laptop (OSK-8759). A guest whose daemon has
+        // published no id gets no candidate. Off a guest nothing is read here and the
+        // search below is unchanged.
+        const local = (0, daemon_target_1.localMachine)({ baseURL: (0, config_1.loadConfig)().baseURL });
+        if (local.dedicatedRuntime && !local.daemonId)
+            return;
         const [daemons, offerResponse] = await Promise.all([
             data_provider_1.dataService.getDaemons(),
             data_provider_1.dataService.getManagedInstructionOffer(TEMPLATE_KEY),
         ]);
         const candidate = daemons.active.find((daemon) => {
+            if (local.dedicatedRuntime && daemon.daemonId !== local.daemonId)
+                return false;
             if (!detectedProviders(daemon).length)
                 return false;
             return offerResponse.offers.find((offer) => offer.daemonId === daemon.daemonId)?.eligible;

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/refresh.d.ts

@@ -1,12 +1,78 @@
 import { type ReauthState, type TokenPair } from './types.js';
 declare function authLockPath(): string;
 declare function reauthFlagPath(): string;
+/**
+ * How long a process whose own listeners took a fatal signal gets to shut down
+ * before it is exited anyway: bounded, so a cleanup that hangs cannot make the
+ * process unkillable, and longer than the longest cleanup a command registers.
+ *
+ * That is `skrr machines dedicated cp` cancelling an upload. It waits out the
+ * chunk in flight, which the server bounds at 30 s (a 20 s tool timeout plus a
+ * 10 s response grace, `DedicatedRuntimeMachineAccess.js`), and then sends one
+ * abort; 45 s leaves 15 s for that abort after a chunk of the full length. An
+ * abort that needs longer is going to a machine that has just failed to answer
+ * a chunk in time, and the daemon's stale-staging sweep removes what it leaves.
+ * `agents chat` waits 10 s for the cancelled run and then reads its record once.
+ *
+ * One constant rather than a bound each listener declares: every cleanup
+ * registered today fits under it, and a registry of bounds would be machinery
+ * for a second number nobody has needed.
+ */
+export declare const LOCK_SIGNAL_FALLBACK_EXIT_MS = 45000;
+export interface LockExitHandlerOptions {
+    /** Overrides LOCK_SIGNAL_FALLBACK_EXIT_MS. For tests. */
+    fallbackExitMs?: number;
+}
 /**
  * P1-6 — Register best-effort lock-release handlers on process exit
  * signals so a crash or SIGTERM during a refresh leaves the lock file
  * in a released state. Without this, a sibling process must wait up to
  * `LOCK_STALE_MS` (5 s) for `proper-lockfile` to declare the lock stale.
  *
+ * A signal handler here must see the lock released when the process ends, and
+ * otherwise get out of the way. It used to release and call `process.exit`
+ * synchronously, and because it is installed as soon as a CLI command loads,
+ * it ran before — and so instead of — every listener a command registered for
+ * its own cleanup: Ctrl-C during `skrr machines dedicated cp` left partial
+ * files behind (OSK-8708), `agents chat` never cancelled the run it said it
+ * would, and the daemon had to strip these listeners off to reach its own
+ * drain at all (OSK-2086). Now:
+ *
+ *   1. The lock is released only when the process actually ends: by the
+ *      `exit` listener, and immediately before a re-raise (dying by a signal
+ *      runs no `exit` listener). Never on the signal itself. A refresh already
+ *      inside `withAuthLock` keeps running while a command cleans up, and
+ *      releasing under it would let a sibling `skrr` take the lock and spend
+ *      the same refresh token — which rotates on use, so one of the two would
+ *      be signed out.
+ *   2. If anything else is listening for the signal — a command's cleanup —
+ *      that listener owns shutdown, and this handler does not exit.
+ *      signal-exit's listeners do not count (`signalExitListenerCount`).
+ *   3. Otherwise it does what Node does for an unhandled fatal signal: it
+ *      removes itself and re-raises the signal, so the process dies BY the
+ *      signal. That is more faithful than `exit(128 + n)`, which only imitates
+ *      the number: a parent can tell the two apart, and does. bash stops a
+ *      loop when a child is killed by SIGINT but carries on after one that
+ *      exited 130, and systemd counts death by SIGTERM as a clean stop but
+ *      exit status 143 as a failure. (signal-exit, when present, sees the
+ *      re-raised signal with no other listener and runs its exit callbacks
+ *      before re-raising it once more.) Not on Windows, where raising a
+ *      signal at yourself is TerminateProcess with status 1: Ctrl-C would exit
+ *      1 and no `exit` listener would run. There it exits `128 + n`.
+ *   4. While owners are shutting down, an unref'd fallback timer exits
+ *      `128 + n` after `fallbackExitMs`, and a second fatal signal exits as
+ *      soon as that signal's listeners have run — so an owner's handler for a
+ *      second signal gets its synchronous turn, and nothing more. The forced
+ *      exits use `process.exit`, not a re-raise, so `exit` listeners (this
+ *      lock release, a command's last synchronous cleanup) still run.
+ *
+ * The listener is PREPENDED, so it runs first and counts every other
+ * listener — including `once` listeners, which remove themselves when called
+ * and would otherwise be invisible to a handler that ran after them. A
+ * listener added LATER with `prependOnceListener` is the exception: it runs
+ * before this one and has removed itself by the time this one counts, so it
+ * is not seen as an owner. Register command cleanup with `on` or `once`.
+ *
  * Guards:
  *   - `_exitHandlersInstalled` (module-level): safe to call multiple
  *     times (e.g., from unit-test re-imports) — handlers are registered
@@ -20,7 +86,7 @@ declare function reauthFlagPath(): string;
  * next to `auth.lock`. It is synchronous so it runs safely in POSIX
  * signal handlers and `process.on('exit')`.
  */
-export declare function installLockExitHandlers(): void;
+export declare function installLockExitHandlers(options?: LockExitHandlerOptions): void;
 /**
  * Acquire the cross-process auth lock, run the body, release on `finally`.
  * Throws if the lock can't be acquired within

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/refresh.js

@@ -3,7 +3,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
     return (mod && mod.__esModule) ? mod : { "default": mod };
 };
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.__refreshDiagnostics = exports.UNKNOWN_401_BUDGET = void 0;
+exports.__refreshDiagnostics = exports.UNKNOWN_401_BUDGET = exports.LOCK_SIGNAL_FALLBACK_EXIT_MS = void 0;
 exports.installLockExitHandlers = installLockExitHandlers;
 exports.withAuthLock = withAuthLock;
 exports.__resetUnknown401StreaksForTest = __resetUnknown401StreaksForTest;
@@ -88,12 +88,95 @@ function authLockPath() {
 function reauthFlagPath() {
     return node_path_1.default.join((0, runtime_js_1.getAuthConfigDir)(), 'needs-reauth.json');
 }
+/** The fatal signals the lock-release handler listens for, with their numbers. */
+const LOCK_RELEASE_SIGNALS = { SIGHUP: 1, SIGINT: 2, SIGTERM: 15 };
+/**
+ * How long a process whose own listeners took a fatal signal gets to shut down
+ * before it is exited anyway: bounded, so a cleanup that hangs cannot make the
+ * process unkillable, and longer than the longest cleanup a command registers.
+ *
+ * That is `skrr machines dedicated cp` cancelling an upload. It waits out the
+ * chunk in flight, which the server bounds at 30 s (a 20 s tool timeout plus a
+ * 10 s response grace, `DedicatedRuntimeMachineAccess.js`), and then sends one
+ * abort; 45 s leaves 15 s for that abort after a chunk of the full length. An
+ * abort that needs longer is going to a machine that has just failed to answer
+ * a chunk in time, and the daemon's stale-staging sweep removes what it leaves.
+ * `agents chat` waits 10 s for the cancelled run and then reads its record once.
+ *
+ * One constant rather than a bound each listener declares: every cleanup
+ * registered today fits under it, and a registry of bounds would be machinery
+ * for a second number nobody has needed.
+ */
+exports.LOCK_SIGNAL_FALLBACK_EXIT_MS = 45_000;
+/**
+ * How many of a signal's listeners belong to `signal-exit`.
+ *
+ * `proper-lockfile` loads signal-exit when it is imported, so every process that
+ * imports this module carries its SIGHUP/SIGINT/SIGTERM listeners. signal-exit
+ * is deferential by design: it acts only when it is the sole listener, and
+ * otherwise leaves the signal to whoever else is listening. Counted as an owner,
+ * it and this handler would each wait for the other and nothing would exit.
+ * v3 and v4 publish their loaded-instance counts on process-wide globals, which
+ * is how they recognise each other (v4 adds v3's count to its own); this reads
+ * the same two counts.
+ */
+function signalExitListenerCount() {
+    const count = (emitter) => typeof emitter?.count === 'number' ? emitter.count : 0;
+    const v3 = process
+        .__signal_exit_emitter__;
+    const v4 = globalThis[Symbol.for('signal-exit emitter')];
+    return count(v3) + count(v4);
+}
 /**
  * P1-6 — Register best-effort lock-release handlers on process exit
  * signals so a crash or SIGTERM during a refresh leaves the lock file
  * in a released state. Without this, a sibling process must wait up to
  * `LOCK_STALE_MS` (5 s) for `proper-lockfile` to declare the lock stale.
  *
+ * A signal handler here must see the lock released when the process ends, and
+ * otherwise get out of the way. It used to release and call `process.exit`
+ * synchronously, and because it is installed as soon as a CLI command loads,
+ * it ran before — and so instead of — every listener a command registered for
+ * its own cleanup: Ctrl-C during `skrr machines dedicated cp` left partial
+ * files behind (OSK-8708), `agents chat` never cancelled the run it said it
+ * would, and the daemon had to strip these listeners off to reach its own
+ * drain at all (OSK-2086). Now:
+ *
+ *   1. The lock is released only when the process actually ends: by the
+ *      `exit` listener, and immediately before a re-raise (dying by a signal
+ *      runs no `exit` listener). Never on the signal itself. A refresh already
+ *      inside `withAuthLock` keeps running while a command cleans up, and
+ *      releasing under it would let a sibling `skrr` take the lock and spend
+ *      the same refresh token — which rotates on use, so one of the two would
+ *      be signed out.
+ *   2. If anything else is listening for the signal — a command's cleanup —
+ *      that listener owns shutdown, and this handler does not exit.
+ *      signal-exit's listeners do not count (`signalExitListenerCount`).
+ *   3. Otherwise it does what Node does for an unhandled fatal signal: it
+ *      removes itself and re-raises the signal, so the process dies BY the
+ *      signal. That is more faithful than `exit(128 + n)`, which only imitates
+ *      the number: a parent can tell the two apart, and does. bash stops a
+ *      loop when a child is killed by SIGINT but carries on after one that
+ *      exited 130, and systemd counts death by SIGTERM as a clean stop but
+ *      exit status 143 as a failure. (signal-exit, when present, sees the
+ *      re-raised signal with no other listener and runs its exit callbacks
+ *      before re-raising it once more.) Not on Windows, where raising a
+ *      signal at yourself is TerminateProcess with status 1: Ctrl-C would exit
+ *      1 and no `exit` listener would run. There it exits `128 + n`.
+ *   4. While owners are shutting down, an unref'd fallback timer exits
+ *      `128 + n` after `fallbackExitMs`, and a second fatal signal exits as
+ *      soon as that signal's listeners have run — so an owner's handler for a
+ *      second signal gets its synchronous turn, and nothing more. The forced
+ *      exits use `process.exit`, not a re-raise, so `exit` listeners (this
+ *      lock release, a command's last synchronous cleanup) still run.
+ *
+ * The listener is PREPENDED, so it runs first and counts every other
+ * listener — including `once` listeners, which remove themselves when called
+ * and would otherwise be invisible to a handler that ran after them. A
+ * listener added LATER with `prependOnceListener` is the exception: it runs
+ * before this one and has removed itself by the time this one counts, so it
+ * is not seen as an owner. Register command cleanup with `on` or `once`.
+ *
  * Guards:
  *   - `_exitHandlersInstalled` (module-level): safe to call multiple
  *     times (e.g., from unit-test re-imports) — handlers are registered
@@ -107,10 +190,11 @@ function reauthFlagPath() {
  * next to `auth.lock`. It is synchronous so it runs safely in POSIX
  * signal handlers and `process.on('exit')`.
  */
-function installLockExitHandlers() {
+function installLockExitHandlers(options = {}) {
     if (_exitHandlersInstalled)
         return;
     _exitHandlersInstalled = true;
+    const fallbackExitMs = options.fallbackExitMs ?? exports.LOCK_SIGNAL_FALLBACK_EXIT_MS;
     function tryRelease() {
         try {
             proper_lockfile_1.default.unlockSync(authLockPath());
@@ -120,18 +204,46 @@ function installLockExitHandlers() {
         }
     }
     process.on('exit', tryRelease);
-    process.on('SIGTERM', () => {
-        tryRelease();
-        process.exit(0);
-    });
-    process.on('SIGINT', () => {
+    const exitStatus = (signal) => 128 + LOCK_RELEASE_SIGNALS[signal];
+    let deferred = false;
+    const listeners = new Map();
+    // `process.exit` runs the `exit` listener above, which releases the lock;
+    // releasing here as well costs nothing and does not depend on that.
+    const exitNow = (signal) => {
         tryRelease();
-        process.exit(130);
-    });
-    process.on('SIGHUP', () => {
+        process.exit(exitStatus(signal));
+    };
+    const onSignal = (signal) => {
+        if (deferred) {
+            // A later signal while owners are shutting down: stop waiting for them.
+            setImmediate(() => exitNow(signal));
+            return;
+        }
+        const owners = process.listenerCount(signal) - 1 - signalExitListenerCount();
+        if (owners > 0) {
+            deferred = true;
+            setTimeout(() => exitNow(signal), fallbackExitMs).unref();
+            return;
+        }
+        process.removeListener(signal, listeners.get(signal));
+        if (process.platform === 'win32') {
+            exitNow(signal);
+            return;
+        }
+        // Dying by the signal runs no `exit` listener, so release first.
         tryRelease();
-        process.exit(1);
-    });
+        try {
+            process.kill(process.pid, signal);
+        }
+        catch {
+            exitNow(signal);
+        }
+    };
+    for (const signal of Object.keys(LOCK_RELEASE_SIGNALS)) {
+        const listener = () => onSignal(signal);
+        listeners.set(signal, listener);
+        process.prependListener(signal, listener);
+    }
 }
 /**
  * Acquire the cross-process auth lock, run the body, release on `finally`.

package/dist/node_modules/@skrr-ai/auth-core/dist/esm/refresh.d.ts

@@ -1,12 +1,78 @@
 import { type ReauthState, type TokenPair } from './types.js';
 declare function authLockPath(): string;
 declare function reauthFlagPath(): string;
+/**
+ * How long a process whose own listeners took a fatal signal gets to shut down
+ * before it is exited anyway: bounded, so a cleanup that hangs cannot make the
+ * process unkillable, and longer than the longest cleanup a command registers.
+ *
+ * That is `skrr machines dedicated cp` cancelling an upload. It waits out the
+ * chunk in flight, which the server bounds at 30 s (a 20 s tool timeout plus a
+ * 10 s response grace, `DedicatedRuntimeMachineAccess.js`), and then sends one
+ * abort; 45 s leaves 15 s for that abort after a chunk of the full length. An
+ * abort that needs longer is going to a machine that has just failed to answer
+ * a chunk in time, and the daemon's stale-staging sweep removes what it leaves.
+ * `agents chat` waits 10 s for the cancelled run and then reads its record once.
+ *
+ * One constant rather than a bound each listener declares: every cleanup
+ * registered today fits under it, and a registry of bounds would be machinery
+ * for a second number nobody has needed.
+ */
+export declare const LOCK_SIGNAL_FALLBACK_EXIT_MS = 45000;
+export interface LockExitHandlerOptions {
+    /** Overrides LOCK_SIGNAL_FALLBACK_EXIT_MS. For tests. */
+    fallbackExitMs?: number;
+}
 /**
  * P1-6 — Register best-effort lock-release handlers on process exit
  * signals so a crash or SIGTERM during a refresh leaves the lock file
  * in a released state. Without this, a sibling process must wait up to
  * `LOCK_STALE_MS` (5 s) for `proper-lockfile` to declare the lock stale.
  *
+ * A signal handler here must see the lock released when the process ends, and
+ * otherwise get out of the way. It used to release and call `process.exit`
+ * synchronously, and because it is installed as soon as a CLI command loads,
+ * it ran before — and so instead of — every listener a command registered for
+ * its own cleanup: Ctrl-C during `skrr machines dedicated cp` left partial
+ * files behind (OSK-8708), `agents chat` never cancelled the run it said it
+ * would, and the daemon had to strip these listeners off to reach its own
+ * drain at all (OSK-2086). Now:
+ *
+ *   1. The lock is released only when the process actually ends: by the
+ *      `exit` listener, and immediately before a re-raise (dying by a signal
+ *      runs no `exit` listener). Never on the signal itself. A refresh already
+ *      inside `withAuthLock` keeps running while a command cleans up, and
+ *      releasing under it would let a sibling `skrr` take the lock and spend
+ *      the same refresh token — which rotates on use, so one of the two would
+ *      be signed out.
+ *   2. If anything else is listening for the signal — a command's cleanup —
+ *      that listener owns shutdown, and this handler does not exit.
+ *      signal-exit's listeners do not count (`signalExitListenerCount`).
+ *   3. Otherwise it does what Node does for an unhandled fatal signal: it
+ *      removes itself and re-raises the signal, so the process dies BY the
+ *      signal. That is more faithful than `exit(128 + n)`, which only imitates
+ *      the number: a parent can tell the two apart, and does. bash stops a
+ *      loop when a child is killed by SIGINT but carries on after one that
+ *      exited 130, and systemd counts death by SIGTERM as a clean stop but
+ *      exit status 143 as a failure. (signal-exit, when present, sees the
+ *      re-raised signal with no other listener and runs its exit callbacks
+ *      before re-raising it once more.) Not on Windows, where raising a
+ *      signal at yourself is TerminateProcess with status 1: Ctrl-C would exit
+ *      1 and no `exit` listener would run. There it exits `128 + n`.
+ *   4. While owners are shutting down, an unref'd fallback timer exits
+ *      `128 + n` after `fallbackExitMs`, and a second fatal signal exits as
+ *      soon as that signal's listeners have run — so an owner's handler for a
+ *      second signal gets its synchronous turn, and nothing more. The forced
+ *      exits use `process.exit`, not a re-raise, so `exit` listeners (this
+ *      lock release, a command's last synchronous cleanup) still run.
+ *
+ * The listener is PREPENDED, so it runs first and counts every other
+ * listener — including `once` listeners, which remove themselves when called
+ * and would otherwise be invisible to a handler that ran after them. A
+ * listener added LATER with `prependOnceListener` is the exception: it runs
+ * before this one and has removed itself by the time this one counts, so it
+ * is not seen as an owner. Register command cleanup with `on` or `once`.
+ *
  * Guards:
  *   - `_exitHandlersInstalled` (module-level): safe to call multiple
  *     times (e.g., from unit-test re-imports) — handlers are registered
@@ -20,7 +86,7 @@ declare function reauthFlagPath(): string;
  * next to `auth.lock`. It is synchronous so it runs safely in POSIX
  * signal handlers and `process.on('exit')`.
  */
-export declare function installLockExitHandlers(): void;
+export declare function installLockExitHandlers(options?: LockExitHandlerOptions): void;
 /**
  * Acquire the cross-process auth lock, run the body, release on `finally`.
  * Throws if the lock can't be acquired within

package/dist/node_modules/@skrr-ai/auth-core/dist/esm/refresh.js

@@ -72,12 +72,95 @@ function authLockPath() {
 function reauthFlagPath() {
     return path.join(getAuthConfigDir(), 'needs-reauth.json');
 }
+/** The fatal signals the lock-release handler listens for, with their numbers. */
+const LOCK_RELEASE_SIGNALS = { SIGHUP: 1, SIGINT: 2, SIGTERM: 15 };
+/**
+ * How long a process whose own listeners took a fatal signal gets to shut down
+ * before it is exited anyway: bounded, so a cleanup that hangs cannot make the
+ * process unkillable, and longer than the longest cleanup a command registers.
+ *
+ * That is `skrr machines dedicated cp` cancelling an upload. It waits out the
+ * chunk in flight, which the server bounds at 30 s (a 20 s tool timeout plus a
+ * 10 s response grace, `DedicatedRuntimeMachineAccess.js`), and then sends one
+ * abort; 45 s leaves 15 s for that abort after a chunk of the full length. An
+ * abort that needs longer is going to a machine that has just failed to answer
+ * a chunk in time, and the daemon's stale-staging sweep removes what it leaves.
+ * `agents chat` waits 10 s for the cancelled run and then reads its record once.
+ *
+ * One constant rather than a bound each listener declares: every cleanup
+ * registered today fits under it, and a registry of bounds would be machinery
+ * for a second number nobody has needed.
+ */
+export const LOCK_SIGNAL_FALLBACK_EXIT_MS = 45_000;
+/**
+ * How many of a signal's listeners belong to `signal-exit`.
+ *
+ * `proper-lockfile` loads signal-exit when it is imported, so every process that
+ * imports this module carries its SIGHUP/SIGINT/SIGTERM listeners. signal-exit
+ * is deferential by design: it acts only when it is the sole listener, and
+ * otherwise leaves the signal to whoever else is listening. Counted as an owner,
+ * it and this handler would each wait for the other and nothing would exit.
+ * v3 and v4 publish their loaded-instance counts on process-wide globals, which
+ * is how they recognise each other (v4 adds v3's count to its own); this reads
+ * the same two counts.
+ */
+function signalExitListenerCount() {
+    const count = (emitter) => typeof emitter?.count === 'number' ? emitter.count : 0;
+    const v3 = process
+        .__signal_exit_emitter__;
+    const v4 = globalThis[Symbol.for('signal-exit emitter')];
+    return count(v3) + count(v4);
+}
 /**
  * P1-6 — Register best-effort lock-release handlers on process exit
  * signals so a crash or SIGTERM during a refresh leaves the lock file
  * in a released state. Without this, a sibling process must wait up to
  * `LOCK_STALE_MS` (5 s) for `proper-lockfile` to declare the lock stale.
  *
+ * A signal handler here must see the lock released when the process ends, and
+ * otherwise get out of the way. It used to release and call `process.exit`
+ * synchronously, and because it is installed as soon as a CLI command loads,
+ * it ran before — and so instead of — every listener a command registered for
+ * its own cleanup: Ctrl-C during `skrr machines dedicated cp` left partial
+ * files behind (OSK-8708), `agents chat` never cancelled the run it said it
+ * would, and the daemon had to strip these listeners off to reach its own
+ * drain at all (OSK-2086). Now:
+ *
+ *   1. The lock is released only when the process actually ends: by the
+ *      `exit` listener, and immediately before a re-raise (dying by a signal
+ *      runs no `exit` listener). Never on the signal itself. A refresh already
+ *      inside `withAuthLock` keeps running while a command cleans up, and
+ *      releasing under it would let a sibling `skrr` take the lock and spend
+ *      the same refresh token — which rotates on use, so one of the two would
+ *      be signed out.
+ *   2. If anything else is listening for the signal — a command's cleanup —
+ *      that listener owns shutdown, and this handler does not exit.
+ *      signal-exit's listeners do not count (`signalExitListenerCount`).
+ *   3. Otherwise it does what Node does for an unhandled fatal signal: it
+ *      removes itself and re-raises the signal, so the process dies BY the
+ *      signal. That is more faithful than `exit(128 + n)`, which only imitates
+ *      the number: a parent can tell the two apart, and does. bash stops a
+ *      loop when a child is killed by SIGINT but carries on after one that
+ *      exited 130, and systemd counts death by SIGTERM as a clean stop but
+ *      exit status 143 as a failure. (signal-exit, when present, sees the
+ *      re-raised signal with no other listener and runs its exit callbacks
+ *      before re-raising it once more.) Not on Windows, where raising a
+ *      signal at yourself is TerminateProcess with status 1: Ctrl-C would exit
+ *      1 and no `exit` listener would run. There it exits `128 + n`.
+ *   4. While owners are shutting down, an unref'd fallback timer exits
+ *      `128 + n` after `fallbackExitMs`, and a second fatal signal exits as
+ *      soon as that signal's listeners have run — so an owner's handler for a
+ *      second signal gets its synchronous turn, and nothing more. The forced
+ *      exits use `process.exit`, not a re-raise, so `exit` listeners (this
+ *      lock release, a command's last synchronous cleanup) still run.
+ *
+ * The listener is PREPENDED, so it runs first and counts every other
+ * listener — including `once` listeners, which remove themselves when called
+ * and would otherwise be invisible to a handler that ran after them. A
+ * listener added LATER with `prependOnceListener` is the exception: it runs
+ * before this one and has removed itself by the time this one counts, so it
+ * is not seen as an owner. Register command cleanup with `on` or `once`.
+ *
  * Guards:
  *   - `_exitHandlersInstalled` (module-level): safe to call multiple
  *     times (e.g., from unit-test re-imports) — handlers are registered
@@ -91,10 +174,11 @@ function reauthFlagPath() {
  * next to `auth.lock`. It is synchronous so it runs safely in POSIX
  * signal handlers and `process.on('exit')`.
  */
-export function installLockExitHandlers() {
+export function installLockExitHandlers(options = {}) {
     if (_exitHandlersInstalled)
         return;
     _exitHandlersInstalled = true;
+    const fallbackExitMs = options.fallbackExitMs ?? LOCK_SIGNAL_FALLBACK_EXIT_MS;
     function tryRelease() {
         try {
             lockfile.unlockSync(authLockPath());
@@ -104,18 +188,46 @@ export function installLockExitHandlers() {
         }
     }
     process.on('exit', tryRelease);
-    process.on('SIGTERM', () => {
-        tryRelease();
-        process.exit(0);
-    });
-    process.on('SIGINT', () => {
+    const exitStatus = (signal) => 128 + LOCK_RELEASE_SIGNALS[signal];
+    let deferred = false;
+    const listeners = new Map();
+    // `process.exit` runs the `exit` listener above, which releases the lock;
+    // releasing here as well costs nothing and does not depend on that.
+    const exitNow = (signal) => {
         tryRelease();
-        process.exit(130);
-    });
-    process.on('SIGHUP', () => {
+        process.exit(exitStatus(signal));
+    };
+    const onSignal = (signal) => {
+        if (deferred) {
+            // A later signal while owners are shutting down: stop waiting for them.
+            setImmediate(() => exitNow(signal));
+            return;
+        }
+        const owners = process.listenerCount(signal) - 1 - signalExitListenerCount();
+        if (owners > 0) {
+            deferred = true;
+            setTimeout(() => exitNow(signal), fallbackExitMs).unref();
+            return;
+        }
+        process.removeListener(signal, listeners.get(signal));
+        if (process.platform === 'win32') {
+            exitNow(signal);
+            return;
+        }
+        // Dying by the signal runs no `exit` listener, so release first.
         tryRelease();
-        process.exit(1);
-    });
+        try {
+            process.kill(process.pid, signal);
+        }
+        catch {
+            exitNow(signal);
+        }
+    };
+    for (const signal of Object.keys(LOCK_RELEASE_SIGNALS)) {
+        const listener = () => onSignal(signal);
+        listeners.set(signal, listener);
+        process.prependListener(signal, listener);
+    }
 }
 /**
  * Acquire the cross-process auth lock, run the body, release on `finally`.