codex-multi-auth 2.17.0 → 2.17.3

package/dist/lib/oc-chatgpt-target-detection.d.ts

@@ -56,4 +56,3 @@ export declare function detectOcChatgptMultiAuthTarget(options?: {
     projectRoot?: string | null;
 }): OcChatgptTargetDetectionResult;
 export {};
-//# sourceMappingURL=oc-chatgpt-target-detection.d.ts.map

package/dist/lib/parallel-probe.d.ts

@@ -32,4 +32,3 @@ export declare function getTopCandidates(accountManager: AccountManager, modelFa
  */
 export declare function probeAccountsInParallel<T>(candidates: ProbeCandidate[], probeFn: (account: ManagedAccount, signal: AbortSignal) => Promise<T>, _options?: Partial<ParallelProbeOptions>): Promise<ProbeResult<T> | null>;
 export declare function createProbeCandidates(accounts: ManagedAccount[]): ProbeCandidate[];
-//# sourceMappingURL=parallel-probe.d.ts.map

package/dist/lib/policy/runtime-policy-cache.d.ts

@@ -0,0 +1,80 @@
+/**
+ * Hot-path caches for the runtime policy stores.
+ *
+ * `loadRuntimePolicyState` runs once per proxied request, and the proxy is a
+ * long-running process while the stores are mutated by separate CLI processes
+ * (`account pause`, `budget`, `routing profile`). The naive path re-read +
+ * re-parsed three JSON files and re-walked the project-root ancestor chain on
+ * every request. These caches keep semantics identical while reducing the
+ * steady-state cost to a handful of `statSync` calls:
+ *
+ * - Store entries are keyed by absolute file path and guarded by an
+ *   `mtimeMs:ctimeMs:size` fingerprint (same approach as
+ *   `lib/runtime/rotation-storage-meta.ts`): the store is only re-read when
+ *   the fingerprint changes. `ctimeMs` is part of the fingerprint because it
+ *   cannot be pinned back the way `mtimeMs` can — on POSIX every write bumps
+ *   it, and on Windows every rename-replacement produces a new file creation
+ *   time — so a rewrite that preserves mtime+size is still caught instead of
+ *   being served stale for the TTL. A fingerprint match is additionally only
+ *   trusted once the file's own mtime has settled past `MTIME_SETTLE_MS` —
+ *   two rapid writes can share a coarse mtime tick on some filesystems (FAT
+ *   2s, ~1s Windows/network volumes), so inside the settle window we always
+ *   re-read. `STORE_CACHE_TTL_MS` bounds staleness for the pathological case
+ *   where a rewrite leaves mtime, ctime and size unchanged, and
+ *   `STORE_CACHE_MAX_ENTRIES` bounds the map (tests rotate through many
+ *   per-test `CODEX_MULTI_AUTH_DIR` temp dirs).
+ *
+ *   Two failure modes get dedicated handling so they cannot poison the cache:
+ *   a file rewritten *while* the loader is reading it is detected by
+ *   re-statting after the load and only caching when the fingerprint is
+ *   stable across the read (an old parse is never stored under the new
+ *   file's fingerprint); and a read that resolves to the empty store while
+ *   bytes still exist on disk — exhausted EBUSY/EPERM retries or corrupt
+ *   JSON both surface as `emptyStore()` from the loaders — is served but
+ *   never cached, so a transient failure cannot hide a real policy for the
+ *   full TTL.
+ *
+ * - Project resolution (`findProjectRoot` + `resolveProjectStorageIdentityRoot`
+ *   + `getProjectStorageKey`) is cached per resolved startDir for
+ *   `PROJECT_RESOLUTION_TTL_MS` and guarded by two fingerprints: an
+ *   mtime/ctime/size fingerprint of the resolved root's `.git` entry — the file
+ *   whose contents drive worktree identity resolution — and the joined
+ *   fingerprints of every ancestor directory that could host a marker, whose
+ *   mtimes change when a marker file is created or deleted. Entries
+ *   therefore invalidate when the project context differs (different
+ *   startDir key, different resolved root), when the `.git` entry changes,
+ *   or when a marker appears/disappears in a watched ancestor — the TTL is
+ *   only the residual bound for coarse-mtime filesystems that report no
+ *   change at all.
+ *
+ * Values held in the caches are shared, mutable objects. Callers must treat
+ * returned values as read-only; `loadRuntimePolicyState` clones what it hands
+ * out.
+ */
+import { type AccountPolicyStore } from "../account-policy.js";
+import { type BudgetGuardStore } from "../budget-guard.js";
+import { type ProjectRoutingProfileContext } from "../routing-profiles.js";
+/**
+ * Cached variant of `loadAccountPolicyStore`. The returned store is shared
+ * cache state — treat as read-only.
+ */
+export declare function loadAccountPolicyStoreCached(): Promise<AccountPolicyStore>;
+/**
+ * Cached variant of `loadBudgetGuardStore`. The returned store is shared
+ * cache state — treat as read-only.
+ */
+export declare function loadBudgetGuardStoreCached(): Promise<BudgetGuardStore>;
+/**
+ * Cached variant of `resolveProjectRoutingProfile` for the per-request path.
+ * The project context (root/identity/key) comes from the bounded resolution
+ * cache; the profile itself is re-derived on every call from the
+ * fingerprint-guarded routing-profiles store, so profile edits are picked up
+ * as soon as the file's mtime/size changes and distinct project contexts can
+ * never observe each other's entries.
+ */
+export declare function resolveProjectRoutingProfileCached(startDir?: string): Promise<ProjectRoutingProfileContext>;
+/**
+ * Test-only: drop every cached store value and project resolution so each
+ * test starts from a clean read-from-disk state.
+ */
+export declare function resetRuntimePolicyCacheForTests(): void;

package/dist/lib/policy/runtime-policy-cache.js

@@ -0,0 +1,310 @@
+/**
+ * Hot-path caches for the runtime policy stores.
+ *
+ * `loadRuntimePolicyState` runs once per proxied request, and the proxy is a
+ * long-running process while the stores are mutated by separate CLI processes
+ * (`account pause`, `budget`, `routing profile`). The naive path re-read +
+ * re-parsed three JSON files and re-walked the project-root ancestor chain on
+ * every request. These caches keep semantics identical while reducing the
+ * steady-state cost to a handful of `statSync` calls:
+ *
+ * - Store entries are keyed by absolute file path and guarded by an
+ *   `mtimeMs:ctimeMs:size` fingerprint (same approach as
+ *   `lib/runtime/rotation-storage-meta.ts`): the store is only re-read when
+ *   the fingerprint changes. `ctimeMs` is part of the fingerprint because it
+ *   cannot be pinned back the way `mtimeMs` can — on POSIX every write bumps
+ *   it, and on Windows every rename-replacement produces a new file creation
+ *   time — so a rewrite that preserves mtime+size is still caught instead of
+ *   being served stale for the TTL. A fingerprint match is additionally only
+ *   trusted once the file's own mtime has settled past `MTIME_SETTLE_MS` —
+ *   two rapid writes can share a coarse mtime tick on some filesystems (FAT
+ *   2s, ~1s Windows/network volumes), so inside the settle window we always
+ *   re-read. `STORE_CACHE_TTL_MS` bounds staleness for the pathological case
+ *   where a rewrite leaves mtime, ctime and size unchanged, and
+ *   `STORE_CACHE_MAX_ENTRIES` bounds the map (tests rotate through many
+ *   per-test `CODEX_MULTI_AUTH_DIR` temp dirs).
+ *
+ *   Two failure modes get dedicated handling so they cannot poison the cache:
+ *   a file rewritten *while* the loader is reading it is detected by
+ *   re-statting after the load and only caching when the fingerprint is
+ *   stable across the read (an old parse is never stored under the new
+ *   file's fingerprint); and a read that resolves to the empty store while
+ *   bytes still exist on disk — exhausted EBUSY/EPERM retries or corrupt
+ *   JSON both surface as `emptyStore()` from the loaders — is served but
+ *   never cached, so a transient failure cannot hide a real policy for the
+ *   full TTL.
+ *
+ * - Project resolution (`findProjectRoot` + `resolveProjectStorageIdentityRoot`
+ *   + `getProjectStorageKey`) is cached per resolved startDir for
+ *   `PROJECT_RESOLUTION_TTL_MS` and guarded by two fingerprints: an
+ *   mtime/ctime/size fingerprint of the resolved root's `.git` entry — the file
+ *   whose contents drive worktree identity resolution — and the joined
+ *   fingerprints of every ancestor directory that could host a marker, whose
+ *   mtimes change when a marker file is created or deleted. Entries
+ *   therefore invalidate when the project context differs (different
+ *   startDir key, different resolved root), when the `.git` entry changes,
+ *   or when a marker appears/disappears in a watched ancestor — the TTL is
+ *   only the residual bound for coarse-mtime filesystems that report no
+ *   change at all.
+ *
+ * Values held in the caches are shared, mutable objects. Callers must treat
+ * returned values as read-only; `loadRuntimePolicyState` clones what it hands
+ * out.
+ */
+import { existsSync, statSync } from "node:fs";
+import { dirname, join, resolve } from "node:path";
+import { getAccountPolicyPath, loadAccountPolicyStore, } from "../account-policy.js";
+import { getBudgetGuardPath, loadBudgetGuardStore, } from "../budget-guard.js";
+import { getRoutingProfilesPath, loadRoutingProfileStore, } from "../routing-profiles.js";
+import { findProjectRoot, getProjectStorageKey, resolveProjectStorageIdentityRoot, } from "../storage/paths.js";
+// Mirrors MTIME_SHORTCIRCUIT_SETTLE_MS in rotation-storage-meta.ts: 2s
+// comfortably exceeds the coarsest mtime granularity we expect in practice.
+const MTIME_SETTLE_MS = 2_000;
+const STORE_CACHE_TTL_MS = 30_000;
+const STORE_CACHE_MAX_ENTRIES = 32;
+// Retries while the file's fingerprint keeps moving across a load (a writer
+// racing us). Beyond this bound the freshest value is returned uncached.
+const STORE_LOAD_MAX_ATTEMPTS = 3;
+const PROJECT_RESOLUTION_TTL_MS = 5_000;
+const PROJECT_RESOLUTION_MAX_ENTRIES = 64;
+const PROJECT_WATCH_MAX_ANCESTORS = 48;
+const ACCOUNT_POLICY_CACHE = new Map();
+const BUDGET_GUARD_CACHE = new Map();
+const ROUTING_PROFILES_CACHE = new Map();
+const PROJECT_RESOLUTION_CACHE = new Map();
+let statErrorSeq = 0;
+function statFile(path) {
+    try {
+        const stats = statSync(path);
+        return {
+            stat: {
+                mtimeMs: stats.mtimeMs,
+                ctimeMs: stats.ctimeMs,
+                size: stats.size,
+            },
+            fingerprint: `${stats.mtimeMs}:${stats.ctimeMs}:${stats.size}`,
+        };
+    }
+    catch (error) {
+        const code = error?.code;
+        if (code === "ENOENT" || code === "ENOTDIR") {
+            return { stat: null, fingerprint: null };
+        }
+        statErrorSeq += 1;
+        return { stat: null, fingerprint: `stat-error:${statErrorSeq}` };
+    }
+}
+function evictOldest(map, maxEntries) {
+    let excess = map.size - maxEntries;
+    for (const key of map.keys()) {
+        if (excess <= 0)
+            return;
+        map.delete(key);
+        excess -= 1;
+    }
+}
+/**
+ * mtime+ctime+size-fingerprinted wrapper around an existing store loader. On
+ * a fingerprint hit the cached store is returned WITHOUT re-reading or
+ * re-parsing the file; on a miss the real loader runs (preserving its retry,
+ * normalization, and warn-on-corrupt semantics) and the entry is keyed on a
+ * fingerprint that must be stable ACROSS the load — re-statting after the
+ * read catches a concurrent rewrite that would otherwise pin the old parse
+ * under the new file's fingerprint once the new mtime settles. A load that
+ * returns the empty store while the file still exists is a failed or
+ * undecodable read, never a cacheable "empty file" answer. The returned
+ * object is the cached instance — callers must not mutate it.
+ */
+async function loadStoreCached(input) {
+    const now = Date.now();
+    const sample = statFile(input.path);
+    const cached = input.cache.get(input.path);
+    if (cached &&
+        cached.fingerprint === sample.fingerprint &&
+        now - cached.loadedAt < STORE_CACHE_TTL_MS &&
+        (sample.stat === null || now - sample.stat.mtimeMs > MTIME_SETTLE_MS)) {
+        // Refresh recency for LRU eviction.
+        input.cache.delete(input.path);
+        input.cache.set(input.path, cached);
+        return cached.value;
+    }
+    for (let attempt = 0; attempt < STORE_LOAD_MAX_ATTEMPTS; attempt += 1) {
+        const before = statFile(input.path).fingerprint;
+        const value = await input.load();
+        const after = statFile(input.path);
+        if (before !== after.fingerprint) {
+            // The file moved under the read: `value` may predate the bytes the
+            // new fingerprint describes. Retry while the writer is still
+            // racing; on the last attempt the value is still a real read, it
+            // is simply not safe to cache.
+            if (attempt + 1 === STORE_LOAD_MAX_ATTEMPTS)
+                return value;
+            continue;
+        }
+        if (after.stat !== null && input.isEmptyStore(value)) {
+            // The loaders resolve exhausted EBUSY/EPERM reads and corrupt JSON
+            // to the empty store — indistinguishable from a legitimately empty
+            // file except that bytes still exist on disk. Serve it, but do
+            // not cache: the next request retries the read instead of hiding
+            // an existing policy for the full TTL.
+            return value;
+        }
+        input.cache.set(input.path, {
+            fingerprint: after.fingerprint,
+            loadedAt: Date.now(),
+            value,
+        });
+        evictOldest(input.cache, STORE_CACHE_MAX_ENTRIES);
+        return value;
+    }
+    // Unreachable: every iteration returns or continues past the bound.
+    throw new Error("runtime policy cache load attempts exhausted");
+}
+/**
+ * Cached variant of `loadAccountPolicyStore`. The returned store is shared
+ * cache state — treat as read-only.
+ */
+export function loadAccountPolicyStoreCached() {
+    return loadStoreCached({
+        path: getAccountPolicyPath(),
+        cache: ACCOUNT_POLICY_CACHE,
+        load: loadAccountPolicyStore,
+        isEmptyStore: (store) => Object.keys(store.accounts).length === 0,
+    });
+}
+/**
+ * Cached variant of `loadBudgetGuardStore`. The returned store is shared
+ * cache state — treat as read-only.
+ */
+export function loadBudgetGuardStoreCached() {
+    return loadStoreCached({
+        path: getBudgetGuardPath(),
+        cache: BUDGET_GUARD_CACHE,
+        load: loadBudgetGuardStore,
+        isEmptyStore: (store) => Object.keys(store.limits).length === 0,
+    });
+}
+function loadRoutingProfileStoreCached() {
+    return loadStoreCached({
+        path: getRoutingProfilesPath(),
+        cache: ROUTING_PROFILES_CACHE,
+        load: loadRoutingProfileStore,
+        isEmptyStore: (store) => Object.keys(store.profiles).length === 0,
+    });
+}
+function gitEntryFingerprint(projectRoot) {
+    return statFile(join(projectRoot, ".git")).fingerprint;
+}
+function watchDirsFingerprint(dirs) {
+    return dirs.map((dir) => statFile(dir).fingerprint).join("|");
+}
+/**
+ * Ancestor directories whose member changes can alter `findProjectRoot`'s
+ * answer for `startDir`: every level between startDir and the resolved root
+ * (inclusive) — a marker created below the current root outranks it — and,
+ * when the root was not found via `.git` (or no root exists at all), every
+ * level up to the filesystem root, because a `.git` appearing at any higher
+ * ancestor would take precedence over the current marker/rootless result.
+ * Directory mtimes change when entries are created or deleted, so new or
+ * removed markers invalidate the cached resolution on the next request.
+ */
+function ancestorWatchDirs(startDir, projectRoot) {
+    const stopAt = projectRoot !== null && existsSync(join(projectRoot, ".git"))
+        ? projectRoot
+        : null;
+    const dirs = [];
+    let current = resolve(startDir);
+    for (let depth = 0; depth < PROJECT_WATCH_MAX_ANCESTORS; depth += 1) {
+        dirs.push(current);
+        if (current === stopAt)
+            break;
+        const parent = dirname(current);
+        if (parent === current)
+            break;
+        current = parent;
+    }
+    return dirs;
+}
+function resolveProject(startDir) {
+    const projectRoot = findProjectRoot(startDir);
+    const identityRoot = projectRoot
+        ? resolveProjectStorageIdentityRoot(projectRoot)
+        : null;
+    const watchDirs = ancestorWatchDirs(startDir, projectRoot);
+    return {
+        projectRoot,
+        identityRoot,
+        projectKey: identityRoot ? getProjectStorageKey(identityRoot) : null,
+        gitFingerprint: projectRoot ? gitEntryFingerprint(projectRoot) : null,
+        watchDirs,
+        watchFingerprint: watchDirsFingerprint(watchDirs),
+        resolvedAt: Date.now(),
+    };
+}
+/**
+ * `findProjectRoot` + `resolveProjectStorageIdentityRoot` cached per resolved
+ * startDir. Hits require a fresh TTL, an unchanged `.git` fingerprint on the
+ * resolved root (editing the worktree pointer or re-creating `.git`
+ * re-resolves immediately), and unchanged ancestor-directory fingerprints
+ * (marker files created or deleted anywhere along the watched chain bump the
+ * parent dir's mtime and re-resolve immediately). The TTL remains the bound
+ * for filesystems too coarse to report any of those changes.
+ */
+function resolveProjectCached(startDir) {
+    const now = Date.now();
+    const cacheKey = resolve(startDir);
+    const cached = PROJECT_RESOLUTION_CACHE.get(cacheKey);
+    if (cached &&
+        now - cached.resolvedAt < PROJECT_RESOLUTION_TTL_MS &&
+        (!cached.projectRoot ||
+            gitEntryFingerprint(cached.projectRoot) === cached.gitFingerprint) &&
+        watchDirsFingerprint(cached.watchDirs) === cached.watchFingerprint) {
+        PROJECT_RESOLUTION_CACHE.delete(cacheKey);
+        PROJECT_RESOLUTION_CACHE.set(cacheKey, cached);
+        return cached;
+    }
+    const resolution = resolveProject(cacheKey);
+    PROJECT_RESOLUTION_CACHE.set(cacheKey, resolution);
+    evictOldest(PROJECT_RESOLUTION_CACHE, PROJECT_RESOLUTION_MAX_ENTRIES);
+    return resolution;
+}
+/**
+ * Cached variant of `resolveProjectRoutingProfile` for the per-request path.
+ * The project context (root/identity/key) comes from the bounded resolution
+ * cache; the profile itself is re-derived on every call from the
+ * fingerprint-guarded routing-profiles store, so profile edits are picked up
+ * as soon as the file's mtime/size changes and distinct project contexts can
+ * never observe each other's entries.
+ */
+export async function resolveProjectRoutingProfileCached(startDir = process.cwd()) {
+    const resolution = resolveProjectCached(startDir);
+    if (!resolution.projectRoot ||
+        !resolution.identityRoot ||
+        !resolution.projectKey) {
+        return {
+            startDir,
+            projectRoot: null,
+            identityRoot: null,
+            projectKey: null,
+            profile: null,
+        };
+    }
+    const store = await loadRoutingProfileStoreCached();
+    return {
+        startDir,
+        projectRoot: resolution.projectRoot,
+        identityRoot: resolution.identityRoot,
+        projectKey: resolution.projectKey,
+        profile: store.profiles[resolution.projectKey] ?? null,
+    };
+}
+/**
+ * Test-only: drop every cached store value and project resolution so each
+ * test starts from a clean read-from-disk state.
+ */
+export function resetRuntimePolicyCacheForTests() {
+    ACCOUNT_POLICY_CACHE.clear();
+    BUDGET_GUARD_CACHE.clear();
+    ROUTING_PROFILES_CACHE.clear();
+    PROJECT_RESOLUTION_CACHE.clear();
+}

package/dist/lib/policy/runtime-policy.d.ts

@@ -1,7 +1,7 @@
 import type { CapabilityPolicyStore } from "../capability-policy.js";
 import { type AccountPolicyStore } from "../account-policy.js";
 import { type BudgetGuardEvaluation, type BudgetGuardStore } from "../budget-guard.js";
-import { type ProjectRoutingProfileContext } from "../routing-profiles.js";
+import type { ProjectRoutingProfileContext } from "../routing-profiles.js";
 import { appendUsageLedgerRow, type UsageLedgerOperation, type UsageLedgerOutcome, type UsageLedgerSource, type UsageServiceTier } from "../usage/index.js";
 export interface RuntimePolicyAccount {
     index: number;
@@ -73,4 +73,3 @@ export declare function createRuntimeUsageRecorder(input: {
     startedAt?: number;
     append?: typeof appendUsageLedgerRow;
 }): RuntimeUsageRecorder;
-//# sourceMappingURL=runtime-policy.d.ts.map

package/dist/lib/policy/runtime-policy.js

@@ -1,15 +1,25 @@
 import { resolveEntitlementAccountKey } from "../entitlement-cache.js";
-import { getAccountPolicyKey, loadAccountPolicyStore, } from "../account-policy.js";
-import { evaluateBudgetGuard, getBudgetWindowStart, loadBudgetGuardStore, normalizeBudgetKey, } from "../budget-guard.js";
-import { resolveProjectRoutingProfile, } from "../routing-profiles.js";
-import { appendUsageLedgerRow, summarizeUsageLedger, } from "../usage/index.js";
+import { getAccountPolicyKey, } from "../account-policy.js";
+import { evaluateBudgetGuard, getBudgetWindowStart, normalizeBudgetKey, } from "../budget-guard.js";
+import { loadAccountPolicyStoreCached, loadBudgetGuardStoreCached, resolveProjectRoutingProfileCached, } from "./runtime-policy-cache.js";
+import { appendUsageLedgerRow, readUsageLedgerRows, summarizeUsageRows, } from "../usage/index.js";
 export async function loadRuntimePolicyState(startDir = process.cwd()) {
+    // Cached loaders: each proxied request costs a few statSync calls instead of
+    // three file reads + JSON parses + the project-root ancestor walk. Stores
+    // re-read whenever their file's mtime/size changes (or within the mtime
+    // settle window, or past the cache TTL), and the project context
+    // re-resolves when the startDir context or `.git` entry changes — so
+    // CLI-side writes are honored without per-request reparsing. See
+    // lib/policy/runtime-policy-cache.ts.
     const [accountPolicies, budgets, project] = await Promise.all([
-        loadAccountPolicyStore(),
-        loadBudgetGuardStore(),
-        resolveProjectRoutingProfile(startDir),
+        loadAccountPolicyStoreCached(),
+        loadBudgetGuardStoreCached(),
+        resolveProjectRoutingProfileCached(startDir),
     ]);
-    return { accountPolicies, budgets, project };
+    // The caches share store objects across calls. Every caller previously
+    // received a private parse, so hand out a private clone: a caller mutating
+    // its state must not poison the cache for the next request.
+    return structuredClone({ accountPolicies, budgets, project });
 }
 function normalizeToken(value) {
     const trimmed = value?.trim().toLowerCase();
@@ -49,19 +59,36 @@ async function evaluateBudgets(input) {
         if (budgetKey)
             keys.add(budgetKey);
     }
-    const evaluations = [];
+    const matchingLimits = [];
     for (const key of keys) {
         const limit = input.state.budgets.limits[key];
-        if (!limit)
-            continue;
-        const summary = await summarizeUsageLedger({
-            since: getBudgetWindowStart(limit.window, input.now),
-            until: input.now,
-            // Budget windows (e.g. monthly) can span a ledger rotation. Without archives,
-            // rotated-out rows are dropped from the sum, under-counting spend and letting
-            // usage exceed the limit within the active window (quota-forecast-03).
-            includeArchives: true,
-        });
+        if (limit)
+            matchingLimits.push(limit);
+    }
+    if (matchingLimits.length === 0)
+        return [];
+    // Read + parse the ledger ONCE per evaluation, not once per matching key —
+    // each summarizeUsageLedger call used to reparse every usage-ledger*.jsonl
+    // line, making the request path O(ledger rows x budget keys). Budget
+    // windows (e.g. monthly) can span a ledger rotation, so archives are
+    // included; without them rotated-out rows are dropped from the sum,
+    // under-counting spend and letting usage exceed the limit within the
+    // active window (quota-forecast-03). Distinct windows still need distinct
+    // `since` filters, so rows are summarized per window in memory — the same
+    // summarizeUsageRows that summarizeUsageLedger applied to the same rows
+    // and query produces an identical UsageSummary.
+    const rows = await readUsageLedgerRows({ includeArchives: true });
+    const summariesByWindow = new Map();
+    const evaluations = [];
+    for (const limit of matchingLimits) {
+        let summary = summariesByWindow.get(limit.window);
+        if (!summary) {
+            summary = summarizeUsageRows(rows, {
+                since: getBudgetWindowStart(limit.window, input.now),
+                until: input.now,
+            });
+            summariesByWindow.set(limit.window, summary);
+        }
         evaluations.push(evaluateBudgetGuard(limit, summary));
     }
     return evaluations;

package/dist/lib/preemptive-quota-scheduler.d.ts

@@ -64,4 +64,3 @@ export declare class PreemptiveQuotaScheduler {
     clearAll(): void;
     prune(now?: number): number;
 }
-//# sourceMappingURL=preemptive-quota-scheduler.d.ts.map

package/dist/lib/proactive-refresh.d.ts

@@ -63,4 +63,3 @@ export declare function refreshExpiringAccounts(accounts: ManagedAccount[], buff
 export declare function applyRefreshResult(account: ManagedAccount, result: Extract<TokenResult, {
     type: "success";
 }>): void;
-//# sourceMappingURL=proactive-refresh.d.ts.map

package/dist/lib/prompts/codex-host-bridge.d.ts

@@ -8,4 +8,3 @@
  * Token Count: ~450 tokens (~90% reduction vs full host prompt)
  */
 export declare const CODEX_HOST_BRIDGE = "# Codex Host Bridge\n\nYou are running Codex through a host terminal coding runtime. The host provides specific tools to help you work efficiently.\n\n## CRITICAL: Tool Usage\n\n<critical_rule priority=\"0\">\napply_patch/applyPatch are Codex names, but host tool names vary by version.\n- Inspect the actual tool list before editing.\n- If `edit` exists: use `edit` for precise in-place string replacements and hashline edits.\n- If `edit` is absent and `apply_patch` exists: use `apply_patch` for those precise/hashline edits in this plugin.\n- For diff-style or multi-line structural edits: use `patch` if available, otherwise use `apply_patch`.\n- In this plugin, `edit` / `apply_patch` also support hashline refs (`lineRef`, `endLineRef`, `operation`, `content`)\n</critical_rule>\n\n<critical_rule priority=\"0\">\nUPDATE_PLAN DOES NOT EXIST -> USE \"todowrite\" INSTEAD\n- NEVER use: update_plan, updatePlan, read_plan, readPlan\n- ALWAYS use: todowrite for task/plan updates, todoread to read plans\n- Before plan operations: Verify you're using \"todowrite\", NOT \"update_plan\"\n</critical_rule>\n\n## Available Host Tools\n\n**File Operations:**\n- `write`  - Create new files\n  - Overwriting existing files requires a prior Read in this session; default to ASCII unless the file already uses Unicode.\n- `edit`   - Modify existing files with string replacement (version-dependent)\n  - Requires a prior Read in this session; preserve exact indentation; ensure `oldString` uniquely matches or use `replaceAll`; edit fails if ambiguous or missing.\n  - Never pass unresolved template placeholders in `oldString` (e.g. `${TARGET_SNIPPET}`); `oldString` must be literal text copied from the current file.\n  - For complex multi-line changes: break into multiple sequential edit calls, each with unique oldString context.\n- `apply_patch` - May be the edit/patch tool name in newer host builds (version-dependent)\n  - In this plugin, `apply_patch` also accepts hashline edit args (`path`, `lineRef`, `endLineRef`, `operation`, `content`) when `edit` is not available.\n- `hashline_read` - Read file with hashline refs (`L<line>#<hash>`) for deterministic edits\n- `patch`  - Apply diff-style patches for multi-line updates (version-dependent)\n- `read`   - Read file contents\n\nNote: Tool naming is version-dependent. If `edit` is unavailable but `apply_patch` exists, use `apply_patch`.\n\nWhen available, prefer hashline workflow for reliability:\n1. Call `hashline_read` for target file and capture refs.\n2. Call `edit` or `apply_patch` with `lineRef` (and optional `endLineRef`) plus `operation` and `content`.\n3. Use legacy `oldString` / `newString` only when hashline refs are unavailable, and only with literal file text (no template placeholders).\n\n**Search/Discovery:**\n- `grep`   - Search file contents (tool, not bash grep); use `include` to filter patterns; set `path` only when not searching workspace root; for cross-file match counts use bash with `rg`.\n- `glob`   - Find files by pattern; defaults to workspace cwd unless `path` is set.\n- `list`   - List directories (requires absolute paths)\n\n**Execution:**\n- `bash`   - Run shell commands\n  - No workdir parameter; do not include it in tool calls.\n  - Always include a short description for the command.\n  - Do not use cd; use absolute paths in commands.\n  - Quote paths containing spaces with double quotes.\n  - Chain multiple commands with ';' or '&&'; avoid newlines.\n  - Use Grep/Glob tools for searches; only use bash with `rg` when you need counts or advanced features.\n  - Do not use `ls`/`cat` in bash; use `list`/`read` tools instead.\n  - For deletions (rm), verify by listing parent dir with `list`.\n\n**Network:**\n- `webfetch` - Fetch web content\n  - Use fully-formed URLs (http/https; http auto-upgrades to https).\n  - Always set `format` to one of: text | markdown | html; prefer markdown unless otherwise required.\n  - Read-only; short cache window.\n\n**Task Management:**\n- `todowrite` - Manage tasks/plans (REPLACES update_plan)\n- `todoread`  - Read current plan\n\n## Substitution Rules\n\nBase instruction says:    You MUST use instead:\napply_patch           ->   patch (preferred if available), otherwise edit/apply_patch based on actual tool list\nupdate_plan           ->   todowrite\nread_plan             ->   todoread\n\n**Path Usage:** Use per-tool conventions to avoid conflicts:\n- Tool calls: `read`, `edit`, `write`, `list` require absolute paths.\n- Searches: `grep`/`glob` default to the workspace cwd; prefer relative include patterns; set `path` only when a different root is needed.\n- Presentation: In assistant messages, show workspace-relative paths; use absolute paths only inside tool calls.\n- Tool schema overrides general path preferences-do not convert required absolute paths to relative.\n\n## Verification Checklist\n\nBefore file/plan modifications:\n1. Am I using the actual available edit tool name (`edit`, `patch`, or `apply_patch`)?\n2. Am I using \"todowrite\" NOT \"update_plan\"?\n3. Is this tool in the approved list above?\n4. Am I following each tool's path requirements?\n\nIf ANY answer is NO -> STOP and correct before proceeding.\n\n## Host Working Style\n\n**Communication:**\n- Send brief preambles (8-12 words) before tool calls, building on prior context\n- Provide progress updates during longer tasks\n\n**Execution:**\n- Keep working autonomously until query is fully resolved before yielding\n- Don't return to user with partial solutions\n\n**Code Approach:**\n- New projects: Be ambitious and creative\n- Existing codebases: Surgical precision - modify only what's requested unless explicitly instructed to do otherwise\n\n**Testing:**\n- If tests exist: Start specific to your changes, then broader validation\n\n## Advanced Tools\n\n**Task Tool (Sub-Agents):**\n- Use the Task tool (functions.task) to launch sub-agents\n- Check the Task tool description for current agent types and their capabilities\n- Useful for complex analysis, specialized workflows, or tasks requiring isolated context\n- The agent list is dynamically generated - refer to tool schema for available agents\n\n**Parallelization:**\n- When multiple independent tool calls are needed, use multi_tool_use.parallel to run them concurrently.\n- Reserve sequential calls for ordered or data-dependent steps.\n\n**MCP Tools:**\n- Model Context Protocol servers provide additional capabilities\n- MCP tools are prefixed: `mcp__<server-name>__<tool-name>`\n- Check your available tools for MCP integrations\n- Use when the tool's functionality matches your task needs\n\n## What Remains from Codex\n \nSandbox policies, approval mechanisms, final answer formatting, git commit protocols, and file reference formats all follow Codex instructions. In approval policy \"never\", never request escalations.\n\n## Approvals & Safety\n- Assume workspace-write filesystem, network enabled, approval on-failure unless explicitly stated otherwise.\n- When a command fails due to sandboxing or permissions, retry with escalated permissions if allowed by policy, including a one-line justification.\n- Treat destructive commands (e.g., `rm`, `git reset --hard`) as requiring explicit user request or approval.\n- Never run `git reset --hard`, `git checkout --`, or force deletes unless the user explicitly asked for that exact action.\n- `request_user_input` is Plan-mode only; do not call it in Default mode.\n- When uncertain, prefer non-destructive verification first (e.g., confirm file existence with `list`, then delete with `bash`).";
-//# sourceMappingURL=codex-host-bridge.d.ts.map