@skrr-ai/cli 0.1.48 → 0.1.50

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

@@ -0,0 +1,164 @@
+import { createHash } from 'node:crypto';
+/**
+ * Server-attested tool approval (OSK-11975 follow-up to the `manual` mode
+ * refusal on `daemon:tool:request`).
+ *
+ * A daemon category in `manual` mode means "a PERSON approves each call". On
+ * the harness-session path the daemon asks through the permission bridge; on
+ * the daemon-tool path a cloud agent's call used to be refused outright,
+ * because the request carried no approval and there was no channel back to a
+ * person. The attested-approval protocol closes that gap without weakening
+ * the guarantee:
+ *
+ *   1. The daemon announces `daemon_tool_attested_approval_v1` and its
+ *      resolved per-category posture (`toolPermissionModes`) at register time.
+ *   2. Before proxying a call, the server reads the announced posture for the
+ *      tool's category. `manual` means it must ask first — through the same
+ *      permission surface (`canUseTool` → `permission:request`) an in-process
+ *      SDK turn would have used — and only then dispatch, carrying an
+ *      `attestedApproval` object on the request.
+ *   3. The daemon verifies the attestation's SHAPE and BINDING — it is bound
+ *      to this exact (toolUseId, toolName, toolInput digest) and expires
+ *      quickly — and allows the call. A missing or malformed attestation gets
+ *      the same named refusal as before.
+ *
+ * What the daemon verifies is the binding, not the server's honesty: the
+ * request already arrives over the daemon's authenticated server channel, so
+ * the field IS the attestation. What the binding buys is that the model —
+ * which authors `toolInput` — cannot mint an approval, and an approval for
+ * one call cannot be replayed onto another.
+ */
+/** Announced by a daemon that honours `attestedApproval` on daemon:tool:request. */
+export const DAEMON_TOOL_ATTESTED_APPROVAL_CAPABILITY = 'daemon_tool_attested_approval_v1';
+/**
+ * Announced by a daemon that honours `toolPosture: 'read_only'` on
+ * daemon:tool:request — the daemon-tool-path expression of the wire `plan`
+ * session mode: reads run, every mutating category is refused with a named
+ * reason. Carries INTENT like `browserPolicy: 'read_only'` — the daemon owns
+ * what read-only means, so the server cannot widen the fence by shipping a
+ * wider value.
+ */
+export const DAEMON_TOOL_READ_ONLY_CAPABILITY = 'daemon_tool_read_only_v1';
+export const DAEMON_TOOL_CATEGORIES = [
+    'read',
+    'write',
+    'bash',
+    'browser',
+    'claude_session',
+    'native_ui',
+];
+/** Map a tool name to its category. Unknown tools take the restrictive answer. */
+export function categoryForDaemonTool(toolName) {
+    switch (String(toolName || '').toLowerCase()) {
+        case 'read':
+        case 'glob':
+        case 'grep':
+        case 'filetransferread':
+            return 'read';
+        case 'write':
+        case 'edit':
+        case 'multiedit':
+        case 'apply_patch':
+        case 'filetransferwrite':
+            return 'write';
+        // Reading or stopping a background command is part of running it.
+        case 'bash':
+        case 'taskoutput':
+        case 'taskstop':
+            return 'bash';
+        case 'browser':
+            return 'browser';
+        case 'native':
+            return 'native_ui';
+        case 'claude_session':
+        case 'claude-session':
+            return 'claude_session';
+        default:
+            return 'write';
+    }
+}
+// ---------------------------------------------------------------------------
+// Attested approval
+// ---------------------------------------------------------------------------
+/**
+ * How long an attestation stays valid. Short: it answers ONE person, about
+ * THIS call, moments ago — it is not a standing grant. The server asks and
+ * dispatches back-to-back, so the window only has to outlive publish latency.
+ */
+export const ATTESTED_TOOL_APPROVAL_TTL_MS = 60 * 1000;
+/**
+ * Deterministic serialization for the input digest: objects sort keys
+ * recursively, arrays keep order, non-JSON values normalize the way
+ * `JSON.stringify` would emit them (undefined/functions in objects drop, in
+ * arrays become null). Both runtimes must digest the SAME bytes — the server
+ * mints and the daemon verifies — so this lives here, once.
+ */
+function canonicalJson(value) {
+    if (value === null || typeof value !== 'object') {
+        if (value === undefined || typeof value === 'function' || typeof value === 'symbol') {
+            return 'null';
+        }
+        return JSON.stringify(value);
+    }
+    if (Array.isArray(value)) {
+        return `[${value.map((entry) => canonicalJson(entry)).join(',')}]`;
+    }
+    const record = value;
+    const keys = Object.keys(record).filter((key) => record[key] !== undefined &&
+        typeof record[key] !== 'function' &&
+        typeof record[key] !== 'symbol');
+    keys.sort();
+    return `{${keys.map((key) => `${JSON.stringify(key)}:${canonicalJson(record[key])}`).join(',')}}`;
+}
+/** The digest both sides compute over `toolInput`. */
+export function canonicalToolInputDigest(toolInput) {
+    return createHash('sha256')
+        .update(canonicalJson(toolInput ?? {}))
+        .digest('hex');
+}
+/** Server side: mint the attestation after a person approved THIS call. */
+export function mintAttestedToolApproval(args) {
+    const now = args.now ?? Date.now();
+    return {
+        v: 1,
+        toolUseId: args.toolUseId,
+        toolName: args.toolName,
+        inputSha256: canonicalToolInputDigest(args.toolInput),
+        decidedBy: 'user',
+        issuedAt: now,
+        expiresAt: now + (args.ttlMs ?? ATTESTED_TOOL_APPROVAL_TTL_MS),
+    };
+}
+/**
+ * Daemon side: verify an attestation against the call it claims to approve.
+ * Untrusted wire input — every field is checked, and any mismatch is a plain
+ * "no approval", never a partial credit. `reason` is for daemon logs; the
+ * refusal text stays generic so a probing caller learns nothing new.
+ */
+export function verifyAttestedToolApproval(approval, call) {
+    if (approval === undefined || approval === null)
+        return { ok: false, reason: 'absent' };
+    if (typeof approval !== 'object' || Array.isArray(approval)) {
+        return { ok: false, reason: 'malformed' };
+    }
+    const a = approval;
+    if (a.v !== 1 ||
+        typeof a.toolUseId !== 'string' ||
+        typeof a.toolName !== 'string' ||
+        typeof a.inputSha256 !== 'string' ||
+        a.decidedBy !== 'user' ||
+        typeof a.issuedAt !== 'number' ||
+        typeof a.expiresAt !== 'number') {
+        return { ok: false, reason: 'malformed' };
+    }
+    const now = call.now ?? Date.now();
+    if (a.expiresAt <= now || a.issuedAt > now + 30_000) {
+        return { ok: false, reason: 'expired' };
+    }
+    if (a.toolUseId !== call.toolUseId ||
+        a.toolName.toLowerCase() !== String(call.toolName).toLowerCase() ||
+        a.inputSha256 !== canonicalToolInputDigest(call.toolInput)) {
+        return { ok: false, reason: 'binding' };
+    }
+    return { ok: true };
+}

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

@@ -223,7 +223,7 @@ export declare function firstPartyHarnessManifestFile(provider?: string): string
  * The update feed ORIGIN. Not a product name, and not moved by this identity:
  * a feed host sits inside signed manifests (naming map §2 "Update feed").
  */
-export declare const FIRST_PARTY_HARNESS_FEED_ORIGIN = "https://updates.oversky.ai";
+export declare const FIRST_PARTY_HARNESS_FEED_ORIGIN = "https://updates.skrr.ai";
 /** Object-key prefix for one spelling's feed, e.g. `skrr-code/`. */
 export declare function firstPartyHarnessFeedPrefix(provider?: string): string;
 /**

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

@@ -304,7 +304,7 @@ export function firstPartyHarnessManifestFile(provider = FIRST_PARTY_HARNESS.pro
  * The update feed ORIGIN. Not a product name, and not moved by this identity:
  * a feed host sits inside signed manifests (naming map §2 "Update feed").
  */
-export const FIRST_PARTY_HARNESS_FEED_ORIGIN = 'https://updates.oversky.ai';
+export const FIRST_PARTY_HARNESS_FEED_ORIGIN = 'https://updates.skrr.ai';
 /** Object-key prefix for one spelling's feed, e.g. `skrr-code/`. */
 export function firstPartyHarnessFeedPrefix(provider = FIRST_PARTY_HARNESS.provider) {
     return `${provider}/`;

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

@@ -40,6 +40,6 @@ export * from './firstPartyHarness.js';
 export { FIRST_PARTY_HARNESS_PREVIOUS_SUFFIX, FIRST_PARTY_HARNESS_PROVENANCE_SUFFIX, firstPartyHarnessBinDir, firstPartyHarnessHomeDir, firstPartyHarnessInstalledBinaryPath, linkFirstPartyHarnessAliases, migrateFirstPartyHarnessHome, type FirstPartyHarnessHomeFs, type FirstPartyHarnessHomeMigration, } from './firstPartyHarnessHome.js';
 export { DEFAULT_FIRST_PARTY_HARNESS_CHANNEL, FIRST_PARTY_HARNESS_CHANNELS, firstPartyHarnessChannelPrefix, firstPartyHarnessFeedBase, firstPartyHarnessFeedCandidates, isFirstPartyHarnessChannel, resolveChannelManifestUrl, resolveFirstPartyHarnessChannel, type FirstPartyHarnessChannel, type FirstPartyHarnessFeedCandidate, } from './firstPartyHarnessChannels.js';
 export { OVERSKY_RELEASE_PUBLIC_KEYS, type ReleaseKey } from './releaseKeys.js';
-export { MAX_SIGS, buildArtifactMessage, buildManifestMessage, getDeltaFor, verifyArtifact, verifyManifest, type DaemonVersionManifest, type DeltaDescriptor, type ManifestSignature, type PlatformArtifact, type VerifyResult, } from './releaseManifest.js';
+export { MAX_SIGS, TRUSTED_FEED_ORIGINS, buildArtifactMessage, buildManifestMessage, getDeltaFor, isTrustedArtifactOrigin, verifyArtifact, verifyManifest, type DaemonVersionManifest, type DeltaDescriptor, type ManifestSignature, type PlatformArtifact, type VerifyResult, } from './releaseManifest.js';
 export { resolveConfigRoot, configRootPath, isConfigRootOverridden } from './configRoot.js';
 export { PROFILES_SEGMENT, SUPERSEDED_MARKER_SUFFIX, SUPERSEDED_COPY_SUFFIX, profileStateDir, legacyProfileStateDir, resolveProfileStateDir, resolveProfileStateFile, profileStateFileLocations, profileStateFilePathsToClear, consolidateProfileState, type ResolvedProfileStateDir, type ConsolidationSpec, type ConsolidationStatus, type ConsolidationOutcome, } from './profileStateDir.js';

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

@@ -161,7 +161,7 @@ export { DEFAULT_FIRST_PARTY_HARNESS_CHANNEL, FIRST_PARTY_HARNESS_CHANNELS, firs
 // same manifest against the same root. See releaseManifest.ts for why a mirror
 // would be the wrong shape here.
 export { OVERSKY_RELEASE_PUBLIC_KEYS } from './releaseKeys.js';
-export { MAX_SIGS, buildArtifactMessage, buildManifestMessage, getDeltaFor, verifyArtifact, verifyManifest, } from './releaseManifest.js';
+export { MAX_SIGS, TRUSTED_FEED_ORIGINS, buildArtifactMessage, buildManifestMessage, getDeltaFor, isTrustedArtifactOrigin, verifyArtifact, verifyManifest, } from './releaseManifest.js';
 // The one definition of the skrr root, shared by `skrr` and `skrrd`. See the
 // module for why re-deriving it kept producing divergences.
 export { resolveConfigRoot, configRootPath, isConfigRootOverridden } from './configRoot.js';

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

@@ -1,4 +1,4 @@
-export type AuthFailureReason = 'REFRESH_INVALID' | 'REFRESH_REUSED' | 'REFRESH_EXPIRED' | 'SESSION_REVOKED' | 'TOKEN_EXPIRED' | 'TOKEN_INVALID' | 'UNKNOWN_401' | 'UNKNOWN';
+export type AuthFailureReason = 'REFRESH_INVALID' | 'REFRESH_REUSED' | 'REFRESH_EXPIRED' | 'SESSION_REVOKED' | 'DEVICE_KEY_MISMATCH' | 'TOKEN_EXPIRED' | 'TOKEN_INVALID' | 'UNKNOWN_401' | 'UNKNOWN';
 /**
  * The command that recovers this process from a re-auth latch.
  *
@@ -11,8 +11,13 @@ export type AuthFailureReason = 'REFRESH_INVALID' | 'REFRESH_REUSED' | 'REFRESH_
  * something the other did not describe (OSK-10224).
  *
  * The binary is whatever the consumer registered with
- * `configureAuthCore({ binaryName })` — the binary the user actually typed —
- * and `--device` is added only when there is no TTY to open a browser from.
+ * `configureAuthCore({ binaryName })` — the binary the user actually typed.
+ *
+ * No flag. This used to append `--device` whenever stdout was not a TTY, which
+ * is always true for a daemon under launchd/systemd — and neither `skrrd login`
+ * nor `skrr login` has a `--device` option, so the one command the latch line
+ * named failed with `unknown option '--device'` (OSK-12056). Both logins already
+ * fall back to a paste-a-code arm when no browser can be opened.
  */
 export declare function reauthCommand(): string;
 export declare function formatReauthMessage(reason: AuthFailureReason | string): string;

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

@@ -12,6 +12,7 @@ const REASON_HUMAN = {
     REFRESH_REUSED: 'Your session was ended for security reasons (token replay detected).',
     REFRESH_EXPIRED: 'Your session has expired.',
     SESSION_REVOKED: 'Your session was ended (you signed out elsewhere or your password changed).',
+    DEVICE_KEY_MISMATCH: "This computer's device key no longer matches the one skrr registered for it, so its session cannot be renewed.",
     TOKEN_EXPIRED: 'Your access token has expired.',
     TOKEN_INVALID: 'Your saved credentials are no longer valid.',
     UNKNOWN_401: 'skrr needs you to sign in again.',
@@ -29,12 +30,16 @@ const REASON_HUMAN = {
  * something the other did not describe (OSK-10224).
  *
  * The binary is whatever the consumer registered with
- * `configureAuthCore({ binaryName })` — the binary the user actually typed —
- * and `--device` is added only when there is no TTY to open a browser from.
+ * `configureAuthCore({ binaryName })` — the binary the user actually typed.
+ *
+ * No flag. This used to append `--device` whenever stdout was not a TTY, which
+ * is always true for a daemon under launchd/systemd — and neither `skrrd login`
+ * nor `skrr login` has a `--device` option, so the one command the latch line
+ * named failed with `unknown option '--device'` (OSK-12056). Both logins already
+ * fall back to a paste-a-code arm when no browser can be opened.
  */
 export function reauthCommand() {
-    const bin = getAuthBinaryName();
-    return process.stdout.isTTY ? `${bin} login` : `${bin} login --device`;
+    return `${getAuthBinaryName()} login`;
 }
 export function formatReauthMessage(reason) {
     const norm = REASON_HUMAN[reason] || REASON_HUMAN.UNKNOWN;

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

@@ -25,6 +25,7 @@ import fs from 'node:fs';
 import path from 'node:path';
 import lockfile from 'proper-lockfile';
 import { getAuthLogger, getAuthConfigDir, emitAuthTelemetry, notifyResponseObserver, } from './runtime.js';
+import { permanentReasonForRefreshCode } from './refreshClassification.js';
 import { PermanentAuthFailure, TransientAuthFailure, } from './types.js';
 /**
  * P1-6: Reduced from 30 s to 5 s.
@@ -804,14 +805,12 @@ async function doRefresh(serverUrl, currentRefreshToken, daemonId, options = {})
         catch {
             /* ignore */
         }
-        const code = parsedBody.code;
-        const permanent = [
-            'REFRESH_INVALID',
-            'REFRESH_REUSED',
-            'REFRESH_EXPIRED',
-            'SESSION_REVOKED',
-        ];
-        if (code && permanent.includes(code)) {
+        // The server's code, mapped through the one table the stateless classifier
+        // reads too — so a permanent refusal that is not spelled as a reason name
+        // (DEVICE_PROOF_THUMBPRINT_MISMATCH) latches instead of riding the
+        // unknown-401 budget forever (OSK-12056).
+        const code = permanentReasonForRefreshCode(parsedBody.code);
+        if (code) {
             // A KNOWN credential-death code is genuinely permanent — latch
             // immediately, exactly as before. It is NOT routed through the
             // unknown-401 budget.
@@ -841,7 +840,7 @@ async function doRefresh(serverUrl, currentRefreshToken, daemonId, options = {})
         }
         // Unknown-shape 401 — unknown code, missing code, or unparseable body.
         // By construction this is NOT a daemon's actual refresh-family burn
-        // (those arrive as one of the four KNOWN codes above); it most likely
+        // (those arrive as one of the KNOWN codes above); it most likely
         // came from infra OverSky does not fully control — a proxy/middleware
         // regression, a clock-skew replay rejection (DEVICE_PROOF_REPLAYED),
         // or a half-rolled-out server route.

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

@@ -36,6 +36,12 @@ export interface ClassifiedRefreshFailure {
     failure: PermanentAuthFailure | TransientAuthFailure;
 }
 export type ClassifiedRefreshResult = ClassifiedRefreshSuccess | ClassifiedRefreshFailure;
+/**
+ * The permanent reason a 401 refresh refusal's `code` names, or `null` when the
+ * code is missing or unrecognised (an unknown-shape 401). The ONE mapping both
+ * this classifier and the daemon's `refresh.ts` read.
+ */
+export declare function permanentReasonForRefreshCode(code: string | undefined | null): PermanentAuthReason | null;
 /**
  * Classify an HTTP response from /api/auth/refresh (or /api/daemons/token/refresh)
  * into a discriminated union of success or failure.

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

@@ -33,6 +33,33 @@ const PERMANENT_CODE_SET = new Set([
     'REFRESH_EXPIRED',
     'SESSION_REVOKED',
 ]);
+/**
+ * Server refusal codes that are permanent but are not themselves reason names.
+ *
+ * `DEVICE_PROOF_THUMBPRINT_MISMATCH` (`daemonRefreshTokens.verifyDeviceProofPinForRow`)
+ * means the proof was signed by a key other than the one enrolled on the daemon's
+ * row. Every retry is signed by the same key, so it can never succeed — but
+ * because it was not in the set above it fell through to the unknown-401 path,
+ * where a daemon retrying on a five-minute cadence never exhausted its budget:
+ * one laptop logged 741 "transient, retrying" refusals over four days, and the
+ * reason it eventually surfaced was `UNKNOWN_401` (OSK-12056).
+ */
+const PERMANENT_CODE_ALIASES = {
+    REFRESH_MISSING: 'REFRESH_INVALID',
+    DEVICE_PROOF_THUMBPRINT_MISMATCH: 'DEVICE_KEY_MISMATCH',
+};
+/**
+ * The permanent reason a 401 refresh refusal's `code` names, or `null` when the
+ * code is missing or unrecognised (an unknown-shape 401). The ONE mapping both
+ * this classifier and the daemon's `refresh.ts` read.
+ */
+export function permanentReasonForRefreshCode(code) {
+    if (!code)
+        return null;
+    if (PERMANENT_CODE_SET.has(code))
+        return code;
+    return PERMANENT_CODE_ALIASES[code] ?? null;
+}
 /**
  * Classify an HTTP response from /api/auth/refresh (or /api/daemons/token/refresh)
  * into a discriminated union of success or failure.
@@ -65,17 +92,12 @@ export function classifyRefreshResponse(status, body) {
     }
     // 401 — auth failure; check for known permanent code
     if (status === 401) {
-        if (body?.code === 'REFRESH_MISSING') {
-            return {
-                kind: 'failure',
-                failure: new PermanentAuthFailure('REFRESH_INVALID', body.message ?? 'Refresh token missing'),
-            };
-        }
-        const code = body?.code;
-        if (code && PERMANENT_CODE_SET.has(code)) {
+        const reason = permanentReasonForRefreshCode(body?.code);
+        if (reason) {
+            const fallback = body?.code === 'REFRESH_MISSING' ? 'Refresh token missing' : reason;
             return {
                 kind: 'failure',
-                failure: new PermanentAuthFailure(code, body?.message ?? code),
+                failure: new PermanentAuthFailure(reason, body?.message ?? fallback),
             };
         }
         // Unknown-shape 401 (no code, or a code we don't recognise). This is NOT a

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

@@ -159,3 +159,41 @@ export declare function verifyManifest(manifest: DaemonVersionManifest, keys?: r
  * against the signed `artifact.sha256`, not from this metadata).
  */
 export declare function getDeltaFor(artifact: PlatformArtifact, fromVersion: string): DeltaDescriptor | null;
+/**
+ * Origins an artifact may be served from, beyond the feed base this run used.
+ *
+ * WHY A SET AND NOT THE ONE ORIGIN
+ * --------------------------------
+ * The pin used to require the artifact origin to EQUAL the feed base's
+ * origin. That is correct with one host and unsatisfiable with two, which the
+ * skrr rename creates:
+ *
+ *   - a shipped daemon/CLI has `updates.oversky.ai` compiled in, so a manifest
+ *     advertising skrr.ai artifacts is refused and it can never self-update
+ *     again — including to the build that would have fixed it;
+ *   - a new build shipping `updates.skrr.ai` refuses the SAME manifest for the
+ *     mirror-image reason.
+ *
+ * One manifest of absolute URLs therefore cannot serve both, and the update
+ * path is the one thing that must not break: a client that cannot update
+ * cannot be repaired remotely.
+ *
+ * Widening to a small, closed set of origins we publish keeps the property the
+ * pin exists for: with keys pinned the ed25519 signature already binds the
+ * URL, and this is defence-in-depth for when verification is disabled —
+ * stopping a manifest-integrity failure from redirecting a download to an
+ * ARBITRARY origin serving a hash-matching payload. An attacker gains nothing
+ * from a second origin that is also ours.
+ *
+ * Both entries are removed down to one when no shipped client uses the old
+ * host, per the add -> verify -> remove ordering.
+ */
+export declare const TRUSTED_FEED_ORIGINS: readonly string[];
+/**
+ * True when `candidate` may serve an artifact for a feed rooted at `feedBase`.
+ *
+ * The feed base's own origin always passes, so an override
+ * (OVERSKY_DAEMON_UPDATE_FEED_BASE, a canary, a test server) keeps working
+ * without being listed here.
+ */
+export declare function isTrustedArtifactOrigin(candidate: string, feedBase: string): boolean;

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

@@ -225,3 +225,67 @@ export function getDeltaFor(artifact, fromVersion) {
     }
     return d;
 }
+// ---------------------------------------------------------------------------
+// Trusted artifact origins
+// ---------------------------------------------------------------------------
+/**
+ * Origins an artifact may be served from, beyond the feed base this run used.
+ *
+ * WHY A SET AND NOT THE ONE ORIGIN
+ * --------------------------------
+ * The pin used to require the artifact origin to EQUAL the feed base's
+ * origin. That is correct with one host and unsatisfiable with two, which the
+ * skrr rename creates:
+ *
+ *   - a shipped daemon/CLI has `updates.oversky.ai` compiled in, so a manifest
+ *     advertising skrr.ai artifacts is refused and it can never self-update
+ *     again — including to the build that would have fixed it;
+ *   - a new build shipping `updates.skrr.ai` refuses the SAME manifest for the
+ *     mirror-image reason.
+ *
+ * One manifest of absolute URLs therefore cannot serve both, and the update
+ * path is the one thing that must not break: a client that cannot update
+ * cannot be repaired remotely.
+ *
+ * Widening to a small, closed set of origins we publish keeps the property the
+ * pin exists for: with keys pinned the ed25519 signature already binds the
+ * URL, and this is defence-in-depth for when verification is disabled —
+ * stopping a manifest-integrity failure from redirecting a download to an
+ * ARBITRARY origin serving a hash-matching payload. An attacker gains nothing
+ * from a second origin that is also ours.
+ *
+ * Both entries are removed down to one when no shipped client uses the old
+ * host, per the add -> verify -> remove ordering.
+ */
+export const TRUSTED_FEED_ORIGINS = [
+    'https://updates.oversky.ai',
+    'https://updates.skrr.ai',
+];
+/**
+ * True when `candidate` may serve an artifact for a feed rooted at `feedBase`.
+ *
+ * The feed base's own origin always passes, so an override
+ * (OVERSKY_DAEMON_UPDATE_FEED_BASE, a canary, a test server) keeps working
+ * without being listed here.
+ */
+export function isTrustedArtifactOrigin(candidate, feedBase) {
+    let feedOrigin;
+    try {
+        feedOrigin = new URL(feedBase).origin;
+    }
+    catch {
+        return false;
+    }
+    // Callers hand over either a bare origin (the daemon's self-updater) or a
+    // full artifact URL (the CLI installer) — both spell the same check.
+    let candidateOrigin = candidate;
+    try {
+        candidateOrigin = new URL(candidate).origin;
+    }
+    catch {
+        /* not a URL — compare raw; it will not match anything */
+    }
+    if (candidateOrigin === feedOrigin)
+        return true;
+    return TRUSTED_FEED_ORIGINS.includes(candidateOrigin);
+}

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

@@ -0,0 +1,81 @@
+/**
+ * Session permission authority — the ONE rule that decides whether a session's
+ * execution contract governs the run's permissions, shared by the server and
+ * the daemon (OSK-11975 introduced it; it was implemented twice — the server
+ * read `kind !== 'commitment'`, the daemon read the `permissionSource` marker —
+ * which is exactly how a new contract kind or a new source value would drift
+ * them apart).
+ *
+ * The wire model:
+ *
+ *   - The contract is closed (`hasOnlyKeys` on the daemon), so "whose
+ *     permissions govern" can never ride INSIDE it. It is a top-level session
+ *     field: `permissionSource`.
+ *   - `'agent'` means the Agent's own configured permission mode, tool policy,
+ *     Grants, session env, MCP servers and machine consent govern the run,
+ *     exactly as for an unattended Task of the same Agent. Today only a
+ *     `commitment` contract may carry it.
+ *   - A `commitment` contract WITHOUT the marker (an older server mid-deploy)
+ *     still governs permissions — the marker is the version signal, so its
+ *     absence must keep the legacy fence, not silently lift it.
+ *   - `task_delivery` contracts always govern, marker or not.
+ *
+ * Server vs daemon asymmetry, on purpose: the server STAMPS the marker
+ * (`permissionSourceForContract`), so on its own side the predicate reduces to
+ * "a commitment never governs" — `contractGovernsPermissions(c,
+ * permissionSourceForContract(c))` is exactly `kind !== 'commitment'`. The
+ * daemon reads the marker it received, because it cannot distinguish "new
+ * server, agent permissions" from "old server, contract fence" any other way.
+ * Both call the same function; only the input differs.
+ */
+/** The wire vocabulary for `permissionSource`. Top-level session field. */
+export declare const SESSION_PERMISSION_SOURCES: readonly ["agent"];
+export type SessionPermissionSource = (typeof SESSION_PERMISSION_SOURCES)[number];
+/**
+ * The daemon capability that proves a build honours `permissionSource`. The
+ * server announces it in preflight and refuses to dispatch a Commitment Run to
+ * a daemon without it (`COMMITMENT_AGENT_PERMISSIONS_RUNTIME_UNSUPPORTED`), so
+ * the marker never reaches a daemon that would ignore it.
+ */
+export declare const COMMITMENT_AGENT_PERMISSIONS_CAPABILITY = "commitment_execution_contract_v2_agent_permissions";
+/**
+ * The minimal contract shape this rule reads. The predicate only ever needs
+ * `kind` — keeping the input structural means this module never imports the
+ * full `CommitmentExecutionContract` type, which lives daemon-side
+ * (`daemon/src/commitment-execution-contract.ts`) and server-side in the
+ * commitment services.
+ */
+export type PermissionContractKind = {
+    kind?: unknown;
+} | null | undefined;
+/**
+ * Untrusted wire input: anything but an exact vocabulary literal reads as
+ * absent. Never widen by coercion — an unrecognized future value must degrade
+ * to "contract governs", the conservative answer.
+ */
+export declare function normalizeSessionPermissionSource(value: unknown): SessionPermissionSource | undefined;
+/**
+ * What the server stamps on the wire for this contract. A `commitment`
+ * contract no longer carries permissions (OSK-11975); every other contract
+ * kind keeps its own authority and stamps nothing.
+ */
+export declare function permissionSourceForContract(contract: PermissionContractKind): SessionPermissionSource | undefined;
+/**
+ * Whether the contract is the run's PERMISSION authority — the single place
+ * this rule lives.
+ *
+ * True for a non-commitment contract regardless of marker, and for a
+ * commitment whose server did not declare agent permissions. False for no
+ * contract at all, and for a commitment carrying `permissionSource: 'agent'`,
+ * which then follows the Agent's own permissions exactly as a Task does while
+ * the contract keeps its non-permission roles (normalized shape, ephemeral
+ * worktree, result validation, `GIT_OPTIONAL_LOCKS`, provider restriction).
+ */
+export declare function contractGovernsPermissions(contract: PermissionContractKind, permissionSource: unknown): boolean;
+/**
+ * The contract when it governs permissions, else `undefined` — for the sites
+ * that used `executionContract` as "is this run permission-fenced".
+ */
+export declare function permissionGoverningContract<T extends {
+    kind?: unknown;
+}>(contract: T | null | undefined, permissionSource: unknown): T | undefined;

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

@@ -0,0 +1,80 @@
+/**
+ * Session permission authority — the ONE rule that decides whether a session's
+ * execution contract governs the run's permissions, shared by the server and
+ * the daemon (OSK-11975 introduced it; it was implemented twice — the server
+ * read `kind !== 'commitment'`, the daemon read the `permissionSource` marker —
+ * which is exactly how a new contract kind or a new source value would drift
+ * them apart).
+ *
+ * The wire model:
+ *
+ *   - The contract is closed (`hasOnlyKeys` on the daemon), so "whose
+ *     permissions govern" can never ride INSIDE it. It is a top-level session
+ *     field: `permissionSource`.
+ *   - `'agent'` means the Agent's own configured permission mode, tool policy,
+ *     Grants, session env, MCP servers and machine consent govern the run,
+ *     exactly as for an unattended Task of the same Agent. Today only a
+ *     `commitment` contract may carry it.
+ *   - A `commitment` contract WITHOUT the marker (an older server mid-deploy)
+ *     still governs permissions — the marker is the version signal, so its
+ *     absence must keep the legacy fence, not silently lift it.
+ *   - `task_delivery` contracts always govern, marker or not.
+ *
+ * Server vs daemon asymmetry, on purpose: the server STAMPS the marker
+ * (`permissionSourceForContract`), so on its own side the predicate reduces to
+ * "a commitment never governs" — `contractGovernsPermissions(c,
+ * permissionSourceForContract(c))` is exactly `kind !== 'commitment'`. The
+ * daemon reads the marker it received, because it cannot distinguish "new
+ * server, agent permissions" from "old server, contract fence" any other way.
+ * Both call the same function; only the input differs.
+ */
+/** The wire vocabulary for `permissionSource`. Top-level session field. */
+export const SESSION_PERMISSION_SOURCES = ['agent'];
+/**
+ * The daemon capability that proves a build honours `permissionSource`. The
+ * server announces it in preflight and refuses to dispatch a Commitment Run to
+ * a daemon without it (`COMMITMENT_AGENT_PERMISSIONS_RUNTIME_UNSUPPORTED`), so
+ * the marker never reaches a daemon that would ignore it.
+ */
+export const COMMITMENT_AGENT_PERMISSIONS_CAPABILITY = 'commitment_execution_contract_v2_agent_permissions';
+/**
+ * Untrusted wire input: anything but an exact vocabulary literal reads as
+ * absent. Never widen by coercion — an unrecognized future value must degrade
+ * to "contract governs", the conservative answer.
+ */
+export function normalizeSessionPermissionSource(value) {
+    return SESSION_PERMISSION_SOURCES.includes(value)
+        ? value
+        : undefined;
+}
+/**
+ * What the server stamps on the wire for this contract. A `commitment`
+ * contract no longer carries permissions (OSK-11975); every other contract
+ * kind keeps its own authority and stamps nothing.
+ */
+export function permissionSourceForContract(contract) {
+    return contract?.kind === 'commitment' ? 'agent' : undefined;
+}
+/**
+ * Whether the contract is the run's PERMISSION authority — the single place
+ * this rule lives.
+ *
+ * True for a non-commitment contract regardless of marker, and for a
+ * commitment whose server did not declare agent permissions. False for no
+ * contract at all, and for a commitment carrying `permissionSource: 'agent'`,
+ * which then follows the Agent's own permissions exactly as a Task does while
+ * the contract keeps its non-permission roles (normalized shape, ephemeral
+ * worktree, result validation, `GIT_OPTIONAL_LOCKS`, provider restriction).
+ */
+export function contractGovernsPermissions(contract, permissionSource) {
+    if (!contract)
+        return false;
+    return !(contract.kind === 'commitment' && normalizeSessionPermissionSource(permissionSource) === 'agent');
+}
+/**
+ * The contract when it governs permissions, else `undefined` — for the sites
+ * that used `executionContract` as "is this run permission-fenced".
+ */
+export function permissionGoverningContract(contract, permissionSource) {
+    return contract && contractGovernsPermissions(contract, permissionSource) ? contract : undefined;
+}