pullfrog 0.1.96 → 0.1.97

package/dist/internal.js

@@ -8,7 +8,7 @@ var __export = (target, all) => {
 // package.json
 var package_default = {
   name: "pullfrog",
-  version: "0.1.96",
+  version: "0.1.97",
   cliContractVersion: "1",
   type: "module",
   bin: {
@@ -14932,6 +14932,15 @@ var providers = {
         openRouterEffort: [],
         openRouterResolve: "openrouter/qwen/qwen3.8-flash"
       },
+      // Zen lists Mistral Large 4 at half its list price for launch, level with
+      // the routers. hidden until a published `pullfrog` resolves it, as there.
+      "mistral-large": {
+        displayName: "Mistral Large",
+        resolve: "opencode/mistral-large-4",
+        effort: ["none", "high"],
+        openRouterResolve: "openrouter/mistralai/mistral-large-4-0",
+        hidden: true
+      },
       "gpt-5-nano": {
         displayName: "GPT Nano",
         resolve: "opencode/gpt-5.4-nano",
@@ -14980,12 +14989,12 @@ var providers = {
         fallback: "opencode/big-pickle"
       },
       // Zen's FREE stealth preview (listed 2026-09-23), the third after
-      // big-pickle and union-alpha. OpenRouter's listing: prompts and
-      // completions may be retained by the provider, not trained on. unlike the
-      // first two it publishes an effort ladder, so the gate mirrors one here.
+      // big-pickle and union-alpha. Zen's docs: zero retention, no training.
+      // unlike the first two it publishes an effort ladder, so the gate
+      // mirrors one here.
       "space-bunny": {
         displayName: "Space Bunny",
-        description: "Stealth preview; prompts may be retained",
+        description: "Stealth preview, free for a limited time",
         resolve: "opencode/space-bunny-free",
         effort: ["low", "medium", "high", "xhigh", "max"],
         // free to run, still gated on the provider's own OPENCODE_API_KEY —
@@ -15003,17 +15012,30 @@ var providers = {
         // see the big-pickle note above (#1077).
         isFree: true
       },
-      // Zen's FREE stealth preview (listed 2026-10-01), the fifth promo. Zen
-      // has not published its data terms yet, so the description claims none.
+      // Zen's FREE stealth preview (listed 2026-10-01), the fifth promo. Zen's
+      // docs: data may be used to improve the model during the free period.
       "fledge-alpha": {
         displayName: "Fledge Alpha",
-        description: "Stealth preview, free for a limited time",
+        description: "Stealth preview; data may be used to improve it",
         resolve: "opencode/fledge-alpha-free",
         effort: ["low", "high", "max"],
         // free to run, still gated on the provider's own OPENCODE_API_KEY —
         // see the big-pickle note above (#1077).
         isFree: true
       },
+      // Zen's FREE preview (listed 2026-10-06), the sixth promo, on Fledge
+      // Alpha's terms. hidden until a published `pullfrog` resolves it.
+      exo: {
+        displayName: "Exo",
+        description: "Preview; data may be used to improve it",
+        resolve: "opencode/exo-free",
+        // Zen publishes a single rung.
+        effort: ["high"],
+        // free to run, still gated on the provider's own OPENCODE_API_KEY —
+        // see the big-pickle note above (#1077).
+        isFree: true,
+        hidden: true
+      },
       // Zen's live free MiMo, and the second free row in a menu that big-pickle
       // was alone in since `mimo-v2-pro-free` lost its model.
       mimo: {
@@ -15469,6 +15491,17 @@ var providers = {
         resolve: "openrouter/meta/muse-spark-1.3-contributor",
         effort: ["minimal", "low", "medium", "high", "xhigh", "max"],
         openRouterResolve: "openrouter/meta/muse-spark-1.3-contributor"
+      },
+      // Mistral's flagship (public preview, 2026-10-06), on the routers only:
+      // the catalog carries no direct Mistral provider. out of the pickers
+      // until a published `pullfrog` resolves the slug; see "A new alias
+      // reaches the picker at merge".
+      "mistral-large": {
+        displayName: "Mistral Large",
+        resolve: "openrouter/mistralai/mistral-large-4-0",
+        effort: ["none", "high"],
+        openRouterResolve: "openrouter/mistralai/mistral-large-4-0",
+        hidden: true
       }
     }
   }),
@@ -15560,6 +15593,13 @@ var providers = {
         displayName: "Muse Spark",
         resolve: "vercel/meta/muse-spark-1.3",
         effort: ["minimal", "low", "medium", "high", "xhigh"]
+      },
+      // hidden until a published `pullfrog` resolves it, as on OpenRouter.
+      "mistral-large": {
+        displayName: "Mistral Large",
+        resolve: "vercel/mistral/mistral-large-4",
+        effort: ["none", "low", "medium", "high"],
+        hidden: true
       }
     }
   })
@@ -15852,17 +15892,16 @@ var REVIEWER_AGENT_NAME = "reviewfrog";
 // modes.ts
 var PR_SUMMARY_FORMAT = `### Default format
 
-The body has at most three parts, in this order:
+The body has at most two parts, in this order:
 
 1. **Reviewed changes preamble** \u2014 a bolded \`**Reviewed changes**\` lead-in with one sentence on what was reviewed in this run (for \`IncrementalReview\`: what changed since the prior pullfrog review), then a bullet list of the substantive changes \u2014 short bolded title, one sentence each. A reviewer should understand the full reviewed scope from this list alone. Close the preamble with the metadata comment below.
 2. **Cross-cutting issue sections** (zero or more) \u2014 one \`### {emoji} {what's wrong, not what to do}\` heading per concern.
-3. **\`### \u2139\uFE0F Nitpicks\`** at the very bottom, if any \u2014 a flat bullet list, no technical-details block. Only for what has no runtime effect: a stale or wrong comment or doc, a misleading name, a typo, dead code, a missing test. Never formatting or whitespace.
 
 **Inline vs. body.** Concerns that anchor to a specific line go inline (the \`comments\` parameter), even when their implications are broad. Body \`### \` sections are reserved for concerns that have **no line to anchor to** \u2014 *absence* (something the diff should have done but didn't), *sequencing* (rollout / deletion / migration order), *design decisions only the human can make*, or *scope questions the diff raises but doesn't address*. With no non-anchorable concerns, the body is just the preamble + metadata.
 
 **Severity emoji** on every \`### \` heading, and nowhere else: \u{1F6A8} critical (blocks merge \u2014 data loss, security, broken core flow) \xB7 \u26A0\uFE0F important (must address before merging) \xB7 \u2139\uFE0F informational (mergeable as-is).
 
-**Behavior decides placement, not fix size.** A finding that changes what the code does \u2014 a wrong value or message, a crash, a race, a leak, a missed cleanup, a slow path \u2014 gets its own inline comment (or a \`### \` section if no line anchors it) at its real severity, however small the fix. Never put it in Nitpicks: before submitting, re-read each Nitpicks bullet and move any that fails this test inline.
+**Behavior decides placement, not fix size.** A finding that changes what the code does \u2014 a wrong value or message, a crash, a race, a leak, a missed cleanup, a slow path \u2014 gets its own inline comment (or a \`### \` section if no line anchors it) at its real severity, however small the fix.
 
 **Blank line between every block-level element.** GitHub's markdown parser requires one before and after HTML tags (\`<details>\`, \`<summary>\`, \`<sub>\`, \`<br/>\`) \u2014 without it GitHub treats what follows as a continuation of the HTML block and renders your markdown as literal text. This is a parser quirk, not a style preference, and it permanently breaks the posted review.
 
@@ -16011,8 +16050,6 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 3. **triage**: orient yourself on the PR \u2014 identify *what kind of thing this is* (domain it touches, seams it crosses, external contracts it depends on, user-facing surfaces it changes). pull as much context as you need to render a confident, well-grounded review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths, fetch related GitHub state. **you are the synthesizer** \u2014 never delegate understanding to subagents.
 
-   when the diff adds or changes a test, check that it can actually fail: a test that would still pass with the bug present is theatre, not coverage. the usual tell is a loose assertion standing where an exact one belongs \u2014 \`>=\` or a truthiness check over an expected value, or a snapshot that absorbs whatever it is handed. read the assertion against the behavior it claims to pin, not against whether it currently passes.
-
    skip the deeper pass and submit a \`No new issues found.\` review per step 7 only when the diff has **no behavioral surface at all** \u2014 doc typos, whitespace/formatting, lockfile or generated-code regeneration, a mechanical rename whose only effect is import-path updates. line count is not the signal: a one-line change to auth, money, SQL, a comparison operator, a redirect, or a config default is not trivial.
 
 4. **specialist decision**: after reading the complete diff, name the questions you still cannot answer confidently yourself, and dispatch one \`${REVIEWER_AGENT_NAME}\` specialist per question. a question qualifies only when a specialist could return evidence that **changes your disposition** on the PR \u2014 generic requests for another look, extra confidence, or polish do not. most reviews need zero or one; some need several.
@@ -16036,8 +16073,6 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
 
 6. **aggregate & draft**: when specialist results land, merge findings; de-dup overlaps (two specialists catching the same issue = higher-confidence signal); trace each finding yourself before accepting it. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the PR (heuristic: if the finding's root cause lives in lines this PR added or modified, it's in scope; otherwise drop unless the PR plausibly introduced or amplified the regression), and anything not actionable. also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or worse, degrades elegance to nominally improve correctness) makes the codebase worse, not better.
 
-   **Hunt for non-anchored concerns before drafting.** After collecting your anchored findings, deliberately scan for concerns that have no specific line to point at \u2014 typically: deletion / cleanup plans for code the diff replaces or shadows; rollout sequencing (what happens to in-flight state during deploy / revert?); scope questions that only the human can answer (e.g. is the legacy path going away or is this a long-term dual track?); architectural risks the diff opens up that aren't a single-line bug.
-
    for surviving findings, draft inline comments with NEW line numbers from the diff \u2014 attach a \`<details>Technical details</details>\` block to any inline comment whose fix is non-trivial or has cross-file implications (see Inline technical details in the format below). every comment must be actionable, 2-3 sentences max in the visible part, one per root cause \u2014 name its other sites in that comment rather than repeating it. use GitHub permalink format for code references. for impact-analysis findings (stale references after rename/remove), report them in the review body ordered by severity (runtime breakage > incorrect docs > stale comments) rather than as inline comments unless they're anchored to a specific line.
 
 7. **submit**: ALWAYS submit exactly one review via \`${t("create_pull_request_review")}\`. Do NOT call \`report_progress\` \u2014 the review is the final record and the progress comment will be cleaned up automatically.
@@ -16059,7 +16094,7 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`
      \`approved: false\`. Body opens with \`> [!CAUTION]\\n> This PR introduces ...\`, followed by the PR summary. Include all inline comments via \`comments\`.
    - **must-address non-critical findings** (real consequences if shipped \u2014 incorrect behavior in non-critical paths, missing validation on user input, regressions the author should fix before merge):
      \`approved: false\`. Body opens with \`> [!IMPORTANT]\\n> ...\`, followed by the PR summary. Reserve this tier for findings with concrete fallout \u2014 do NOT use \`[!IMPORTANT]\` for nits, style preferences, or "consider also" suggestions. Include all inline comments via \`comments\`.
-   - **minor suggestions only** (low-stakes findings, or Nitpicks only):
+   - **minor suggestions only** (low-stakes findings):
      \`approved: false\`. Body opens with \`> \u2139\uFE0F No critical issues \u2014 minor suggestions inline.\\n\\n\` followed by the PR summary. Include all inline comments via \`comments\`. Vary the wording after the emoji to fit the review (e.g. "Minor suggestions only.", "Two rough edges worth a look."), but always keep the \u2139\uFE0F prefix and keep it short.
    - **informational observations** (mergeable as-is, nothing actionable \u2014 e.g. prior feedback addressed cleanly, calling out something noteworthy without recommending a change):
      \`approved: true\`. Body opens with \`> \u2705 No new issues found.\\n\\n\` followed by the PR summary. Do NOT include inline \`comments\` \u2014 the \u2705 signals "no action needed", which contradicts an actionable anchor; if a point is concrete enough to anchor to a line, downgrade the whole review to "minor suggestions only" (\`approved: false\`) instead.
@@ -16102,8 +16137,6 @@ ${PR_SUMMARY_FORMAT}`
 
 5. **triage**: orient on the *incremental* changes \u2014 domain, seams, external contracts, user-facing surfaces. pull as much context as you need to render a confident review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths. **you are the synthesizer.**
 
-   a test added or changed in this delta must be able to fail \u2014 one that would still pass with the bug present is theatre, not coverage. the tell is a loose assertion where an exact one belongs (\`>=\` or a truthiness check over an expected value, a snapshot that absorbs whatever it is handed).
-
    skip the deeper pass and jump to step 10's non-substantive path (do NOT submit a review) only when the incremental changes have **no behavioral surface at all** \u2014 formatting, comment tweaks, import reordering, lockfile regen, a mechanical rename of import paths. line count is not the signal: a one-line change to auth, money, SQL, a comparison operator, a redirect, or a config default is not trivial.
 
 6. **specialist decision**: after covering the incremental and full diffs, name the questions about the new changes that you still cannot answer confidently yourself, and dispatch one \`${REVIEWER_AGENT_NAME}\` specialist per question. a question qualifies only when a specialist could return evidence that **changes your disposition** on the PR \u2014 generic requests for another look, extra confidence, or polish do not. most incremental reviews need zero or one, especially thread-reply re-reviews; some need several.
@@ -16127,11 +16160,9 @@ ${PR_SUMMARY_FORMAT}`
 
 8. **aggregate, draft, self-critique**: merge findings (yours + output from every specialist you dispatched); de-dup overlaps; trace each finding yourself. drop praise, style preferences, speculative/unverified claims, findings about pre-existing code unrelated to the new commits, anything not actionable, and anything that re-states prior review feedback (heuristic: if the finding's root cause lives in lines the *new commits* added or modified, it's in scope; otherwise drop). also drop **bloat-shaped findings** \u2014 proposed fixes that would add defensive checks for cases that can't happen, abstractions used once, comments restating obvious code, tests asserting tautologies, or "just-in-case" guards. subagents are fallible and bias toward recommending changes; the bar for an actionable inline comment is sound + correct + elegant. recommending a change that improves only one of the three (or degrades elegance to nominally improve correctness) makes the codebase worse, not better. To compute "lines the new commits added or modified": if \`incrementalDiffPath\` from step 2 is present, use it directly. Otherwise, take the prior Pullfrog review's \`commit_id\` (returned alongside each entry from \`${t("list_pull_request_reviews")}\` in step 4) and run \`git diff <prior-review-sha>..HEAD\` to isolate the lines added since that review.
 
-   **Hunt for non-anchored concerns before drafting.** After collecting your anchored findings, deliberately scan for concerns that have no specific line to point at \u2014 typically: deletion / cleanup plans for code the new commits replace or shadow; rollout sequencing (what happens to in-flight state during deploy / revert?); scope questions that only the human can answer (e.g. is the legacy path going away or is this a long-term dual track?); architectural risks the new commits open up that aren't a single-line bug.
-
    draft inline comments with NEW line numbers from the full PR diff \u2014 attach a \`<details>Technical details</details>\` block to any inline comment whose fix is non-trivial or has cross-file implications (see Inline technical details in the format below). every comment must be actionable, 2-3 sentences max in the visible part, one per root cause \u2014 name its other sites in that comment rather than repeating it.
 
-9. **build the review body**: use the same default format as Review mode (preamble + optional cross-cutting \`### \` sections + optional \`### \u2139\uFE0F Nitpicks\`) \u2014 scoped to the **incremental delta**, not the full PR. The "Reviewed changes" bullets describe what changed since the prior pullfrog review (each bullet starts with a past-tense verb, e.g. \`- Extracted shared CLI runtime into a single module\`). Do NOT include a separate "Prior review feedback" checklist \u2014 that's tracked in the rolling PR summary snapshot for the next agent run, and surfacing it in the user-facing body is noise (changes that addressed prior feedback are already covered by the Reviewed-changes bullets). In some cases you may receive a complete diff for the whole PR instead of an incremental one; when this happens, determine what changed since Pullfrog's most recent review yourself before drafting bullets.
+9. **build the review body**: use the same default format as Review mode (preamble + optional cross-cutting \`### \` sections) \u2014 scoped to the **incremental delta**, not the full PR. The "Reviewed changes" bullets describe what changed since the prior pullfrog review (each bullet starts with a past-tense verb, e.g. \`- Extracted shared CLI runtime into a single module\`). Do NOT include a separate "Prior review feedback" checklist \u2014 that's tracked in the rolling PR summary snapshot for the next agent run, and surfacing it in the user-facing body is noise (changes that addressed prior feedback are already covered by the Reviewed-changes bullets). In some cases you may receive a complete diff for the whole PR instead of an incremental one; when this happens, determine what changed since Pullfrog's most recent review yourself before drafting bullets.
 
 10. Submit \u2014 every run must end with EXACTLY ONE of \`${t("create_pull_request_review")}\` (substantive review) or \`${t("report_progress")}\` (no-review acknowledgement). do NOT call \`create_issue_comment\` for review output.
 
@@ -16142,7 +16173,7 @@ ${PR_SUMMARY_FORMAT}`
    - IF NO NEW ISSUES, NON-SUBSTANTIVE CHANGES ONLY (trivial formatting, import reordering, comment tweaks): do NOT submit a review. Instead call \`${t("report_progress")}\` with \`no_review_needed: true\` and a 1-2 sentence note explaining no review was warranted (e.g. "No new issues. Changes since last review are formatting-only."). this leaves a visible signal that the run completed.
    - ELSE IF NEW CRITICAL ISSUES (blocks merge \u2014 bugs, security, data loss, broken core flows): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!CAUTION]\\n> This PR introduces ...\`, followed by the PR summary using the default format below.
    - ELSE IF NEW MUST-ADDRESS NON-CRITICAL FINDINGS (real consequences if shipped \u2014 incorrect behavior, missing validation, regressions the author should fix before merge): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> [!IMPORTANT]\\n> ...\`, followed by the PR summary using the default format below. Do NOT use this tier for nits, style preferences, or "consider also" suggestions.
-   - ELSE IF NEW MINOR SUGGESTIONS ONLY (low-stakes findings, or Nitpicks only): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> \u2139\uFE0F No critical issues \u2014 minor suggestions inline.\\n\\n\` (vary the wording after \u2139\uFE0F to fit the review), followed by the PR summary using the default format below.
+   - ELSE IF NEW MINOR SUGGESTIONS ONLY (low-stakes findings): call \`${t("create_pull_request_review")}\` with \`approved: false\`, all comments, and the review body. body opens with \`> \u2139\uFE0F No critical issues \u2014 minor suggestions inline.\\n\\n\` (vary the wording after \u2139\uFE0F to fit the review), followed by the PR summary using the default format below.
    - ELSE IF INFORMATIONAL OBSERVATIONS (mergeable as-is, but worth surfacing \u2014 e.g. prior feedback addressed cleanly, or a noteworthy positive observation): call \`${t("create_pull_request_review")}\` with \`approved: true\`, NO inline comments, and the review body. body opens with \`> \u2705 No new issues found.\\n\\n\` (or similar friendly green opener), followed by the PR summary using the default format below. If a point is concrete enough to anchor to a line, downgrade the whole review to "minor suggestions only" (\`approved: false\`) instead \u2014 the \u2705 signals "no action needed", which contradicts an actionable anchor.
    - ELSE IF NO NEW ISSUES, SUBSTANTIVE CHANGES (new functionality, behavior changes, or fixes to prior review feedback): call \`${t("create_pull_request_review")}\` to create a PR review. If all previous reviews have been properly addressed and no new issues were discovered, set \`approved: true\`. body opens with \`> \u2705 No new issues found.\\n\\n\`, followed by the PR summary using the default format below.
 
@@ -16851,7 +16882,13 @@ var PROVIDER_ERROR_PATTERNS = [
   // …/settings/credits`) matched neither this nor `requires more credits`, so
   // the one run in that episode that was a genuinely empty wallet rendered with
   // no CTA at all while runs 1-6 rendered correctly.
-  { regex: /Insufficient (?:balance|credits)/i, label: PROVIDER_BILLING_EXHAUSTED_LABEL },
+  // `account funds` is Zen's (#1474).
+  {
+    regex: /Insufficient (?:balance|credits|account funds)/i,
+    label: PROVIDER_BILLING_EXHAUSTED_LABEL
+  },
+  // OpenAI's `You have no credits remaining` (#1474).
+  { regex: /no credits remaining/i, label: PROVIDER_BILLING_EXHAUSTED_LABEL },
   { regex: /credit balance is too low/i, label: PROVIDER_BILLING_EXHAUSTED_LABEL },
   // "spending cap" (Gemini) and "spending limit" (xAI, #1076) are the same
   // condition in two house styles — a configured ceiling was reached.

package/dist/mcp/checkout.d.ts

@@ -61,6 +61,8 @@ export type PrData = {
 };
 type CheckoutPrBranchParams = GitContext & {
     beforeSha?: string | undefined;
+    /** aborts the in-flight fetch (SIGTERM, so git removes its own locks) when the tool deadline fires */
+    signal: AbortSignal;
 };
 /**
  * Shared helper to checkout a PR branch and configure fork remotes.

package/dist/utils/apiKeys.d.ts

@@ -1,3 +1,5 @@
+import type { CredentialCandidate } from "./subscriptionCredentials.ts";
+import type { ProbeVerdict } from "./subscriptionProbe.ts";
 /** shared sentence in the four `resolveSlug` routing-slug throws. */
 export declare const BYOK_SLUG_MARKER = "env var is required when the model is set to";
 /** shared sentence in the four `validate*Setup` throws. */
@@ -49,6 +51,12 @@ export declare const ROUTER_UNFUNDED_MARKER = "your Pullfrog Router balance is e
  * hand that agent the ability to suppress every other error body.
  */
 export declare const CREDENTIAL_REJECTED_MARKER = "was rejected by its provider";
+/**
+ * marker for the credential pool's refusal: every configured credential for the
+ * model was rejected or exhausted. verbatim for the same reason as
+ * `CREDENTIAL_REJECTED_MARKER` — each bullet quotes the probe's verdict.
+ */
+export declare const CREDENTIAL_POOL_REFUSED_MARKER = "No configured credential can serve this run";
 /**
  * Three ways to arrive at "the runner has no key", each with a different CTA:
  * we couldn't read the key you stored, your Router wallet ran dry and you have
@@ -184,6 +192,24 @@ export declare function buildRejectedCredentialError(params: {
     /** stored in Pullfrog (console / `pullfrog auth`) rather than a GitHub Actions secret. */
     inPullfrogStore: boolean;
 }): string;
+export type RefusedCredential = {
+    name: string;
+    source: CredentialCandidate["source"] | "workflow";
+    verdict: Extract<ProbeVerdict, {
+        status: "rejected" | "exhausted";
+    }>;
+};
+/**
+ * The credential pool probed every credential configured for the model and
+ * none can serve it. One bullet per credential: the probe's own verdict, quoted,
+ * plus the remedy its kind and status call for — never inferred from the prose.
+ */
+export declare function buildCredentialPoolRefusedError(params: {
+    model: string;
+    refused: RefusedCredential[];
+    owner: string;
+    name: string;
+}): string;
 /**
  * Friendly Markdown summary for both the missing-key and invalid-key cases.
  * Used in the catch / result-failure paths in `main.ts` to overwrite the raw

package/dist/utils/changeImpact.d.ts

@@ -6,6 +6,7 @@ type CreateChangeImpactParams = {
     pullNumber: number;
     baseSha: string;
     headSha: string;
+    signal: AbortSignal;
 };
 type ChangeImpactResult = {
     path: string;

package/dist/utils/codexHome.d.ts

@@ -1,3 +1,5 @@
+/** the data dir a subscription was installed into this run, which opencode's XDG_DATA_HOME must name. */
+export declare function getSubscriptionDataHome(): string | undefined;
 export declare function clearInstalledSubscription(name: "CODEX_AUTH_JSON" | "GROK_AUTH_JSON"): void;
 /** sandbox-hidden home for pullfrog-managed on-disk secrets in CI. bash via
  * MCP shell tmpfs-overlays this path; opencode's internal auth module
@@ -11,8 +13,6 @@ export interface InstalledCodexAuth {
     /** absolute path of the auth.json we wrote — caller passes this to the
      * post-hook via core.saveState for refresh-detection later. */
     authPath: string;
-    /** value to set as XDG_DATA_HOME for the OpenCode subprocess. */
-    xdgDataHome: string;
     /** refresh_token from the env at materialization time. post-hook
      * compares against the on-disk file after the run to detect whether
      * OpenCode refreshed during the session (only happens on long runs
@@ -31,15 +31,13 @@ export interface InstalledCodexAuth {
  * caller treats null as "no codex auth, fall through to API key flow".
  *
  * The env value is server-side guaranteed fresh by `maybeRotateCodexSecret`
- * in the run-context endpoint. We parse + write it here and set
- * `process.env.XDG_DATA_HOME` so every opencode subprocess discovers the
+ * in the run-context endpoint. We parse + write it here and record the dir
+ * (`getSubscriptionDataHome`) so every opencode subprocess discovers the
  * auth.json; no refresh, no DB interaction. */
 export declare function installCodexAuth(): InstalledCodexAuth | null;
 export interface InstalledXaiAuth {
     /** absolute path of the auth.json we wrote — the post-hook diffs it. */
     authPath: string;
-    /** value to set as XDG_DATA_HOME for the OpenCode subprocess. */
-    xdgDataHome: string;
     /** refresh_token at materialization time. opencode's XaiAuthPlugin rotates
      * in-process on a long run, so the post-hook compares against this to decide
      * whether anything needs writing back. */

package/dist/utils/gitAuth.d.ts

@@ -22,6 +22,7 @@ type GitAuthOptions = {
      * when present, an auth-class failure is retried ONCE with a fresh token.
      */
     refreshGitToken?: ((stale: string) => Promise<string>) | undefined;
+    signal?: AbortSignal | undefined;
 };
 /**
  * installation-token 401s on git. GitHub intermittently mints a token its git

package/dist/utils/oauthWriteback.d.ts

@@ -6,6 +6,8 @@
  * post-hook's stdlib-only import graph and bring back #815. Keep the two in
  * sync by hand; `entryPost.stdlibOnly.test.ts` guards the reason they differ. */
 export declare const OAUTH_WRITEBACK_STATE = "oauth_writeback";
+/** GHA state key for the run's subscription data dir (codexHome.ts); `entryPost.ts` spells it literally too. */
+export declare const SUBSCRIPTION_DATA_DIR_STATE = "subscription_data_dir";
 /**
  * Persist any OAuth refresh chain the run rotated, back into Pullfrog's own
  * secret store.
@@ -22,6 +24,9 @@ export declare const OAUTH_WRITEBACK_STATE = "oauth_writeback";
  * to write them back from inside a job — so a token stashed there silently
  * goes stale on the first refresh and the next run fails. See wiki/codex-auth.md.
  *
+ * Then removes the run's subscription data dir (codexHome.ts), which holds the
+ * auth.json diffed here.
+ *
  * Best-effort throughout: a missed write-back costs the user one
  * `pullfrog auth codex` re-run, while a throw here would fail a workflow whose
  * agent already succeeded.

package/dist/utils/openCodeModels.d.ts

@@ -1,3 +1,14 @@
+/**
+ * HOME and XDG dirs for every opencode subprocess, all inside this run. the runner user's own
+ * are shared by every run on a self-hosted host, and so is opencode's SQLite db in them (#1475).
+ */
+export declare function openCodeHomeEnv(tmpdir: string): {
+    HOME: string;
+    XDG_CONFIG_HOME: string;
+    XDG_DATA_HOME: string;
+    XDG_CACHE_HOME: string;
+    XDG_STATE_HOME: string;
+};
 /**
  * Why the last `opencode models` came back empty, in opencode's own words.
  *
@@ -9,11 +20,17 @@
 export declare function getModelsFailure(): string | undefined;
 /** Snapshot the set of models OpenCode can serve from the current env, BEFORE
  * Pullfrog-stored credentials are merged in. Call once early in `main.ts`. */
-export declare function captureBaselineModels(cliPath: string): void;
+export declare function captureBaselineModels(params: {
+    cliPath: string;
+    tmpdir: string;
+}): void;
 /** Snapshot the set of models OpenCode can serve AFTER dbSecrets +
  * Codex auth.json are in place. Logs the diff against the baseline as
  * `» BYOK auth enabled N model(s): …`. */
-export declare function captureAuthorizedModels(cliPath: string): void;
+export declare function captureAuthorizedModels(params: {
+    cliPath: string;
+    tmpdir: string;
+}): void;
 /** A model whose credential the pool just probed. Added directly: a second
  * `opencode models` would run inside the checkout and load the repo's own
  * `.opencode` plugins, which can outlast its timeout and empty the set. */

package/dist/utils/providerErrors.d.ts

@@ -7,7 +7,8 @@ export declare const PROVIDER_NO_ENDPOINTS_LABEL = "provider no routable endpoin
  * `PROVIDER_BILLING_EXHAUSTED_LABEL`: that label routes to a body whose CTA is
  * "Top up your provider balance", and a capped ChatGPT or Zen plan has no
  * balance to top up — it resets on its own. This label carries the cause into
- * the headline and lets the generic body stand.
+ * the hang headline and lets the generic body stand; a turn it ends directly
+ * gets its own wait-or-raise copy in `renderRunError` (#1474).
  */
 export declare const PROVIDER_USAGE_LIMIT_LABEL = "provider usage limit reached";
 export declare function findAnthropicSpendCap(text: string): {
@@ -35,6 +36,8 @@ export declare function isRouterKeylimitExhaustedError(text: string): boolean;
  * is the user's own provider account.
  */
 export declare function isProviderBillingExhausted(text: string): boolean;
+/** A capped subscription window or a configured usage limit — see `PROVIDER_USAGE_LIMIT_LABEL`. */
+export declare function isProviderUsageLimit(text: string): boolean;
 /**
  * OpenRouter accepted the request and found nowhere to send it: the account's
  * data policy or guardrail settings exclude every provider serving the picked

package/dist/utils/runErrorRenderer.d.ts

@@ -13,19 +13,28 @@
  *      "key budget exhausted" string mid-run. Both render via
  *      `formatBillingErrorSummary` so the user sees actionable copy.
  *
+ *   1a. Pre-rendered bodies — a throw site that already built the markdown
+ *      (`MODEL_ACCESS_MARKER`, `SECRETS_UNAVAILABLE_MARKER`,
+ *      `ROUTER_UNFUNDED_MARKER`, `CREDENTIAL_REJECTED_MARKER`,
+ *      `CREDENTIAL_POOL_REFUSED_MARKER`) passes through verbatim on both surfaces.
+ *
  *   2. BYOK provider billing-exhausted (#835) — DeepSeek "Insufficient
  *      Balance", Anthropic "credit balance is too low", OpenCode Zen
  *      `CreditsError`, Gemini "spending cap". Checked before api-key auth
  *      because billing-exhausted responses often carry 401 status codes
  *      that `isApiKeyAuthError` would otherwise mis-classify.
  *
+ *   2a. Provider usage limit (#1474) — a capped subscription window or a
+ *      configured workspace limit; "wait or raise it", never "top up".
+ *
  *   3. API-key auth error — `isApiKeyAuthError` sniffs the raw error string
  *      (or the activity-timeout hang body when present, since that's where
  *      the underlying provider error often lands); `formatApiKeyErrorSummary`
  *      renders provider + console-link copy.
  *
- *   4. ProviderModelNotFoundError — configured model id no longer in the
- *      OpenCode catalog; renders a nudge to pick a different model.
+ *   4. ProviderModelNotFoundError — configured model id not in the OpenCode
+ *      catalog (opencode ≥1.18 words it `Model not found: <id>`, #1470);
+ *      renders a nudge to pick a different model.
  *
  *   4a. No-provider-available (#1077) — the model IS in the catalog but the
  *      provider declines to route it on this account's plan (OpenCode Zen's
@@ -60,17 +69,24 @@
  *      event counts and a benign stderr tail are operator-grade detail that
  *      only alarm the average user.
  *
- *   6. Default — the job summary gets a plain-English lead sentence plus the
+ *   6. Unclassified provider error (#1474) — `errorMessage` starts with
+ *      `provider error: `. opencode prefixes every provider-side turn failure
+ *      with the provider's text; claude-code (a zero-event exit) and codex (no
+ *      turn error, no stderr) prefix only our classifier label. Either names
+ *      something the user can act on, so both surfaces get a lead line plus the
+ *      raw text in a fenced block.
+ *
+ *   7. Default — the job summary gets a plain-English lead sentence plus the
  *      raw error in a fenced code block under the `### ❌ Pullfrog failed`
  *      banner; the PR comment collapses to the same one-line logs link as
  *      the hang case, since the raw internal string helps nobody on the PR.
  *
- * Net: the actionable classifications (billing, API-key, model-not-found,
- * no-provider-available, context-overflow, run time limit, transient-upstream)
- * render identical bodies on both surfaces; the non-actionable ones (unexplained hang,
- * generic) keep the forensics in the Actions job summary and show a calm
- * one-liner in the PR comment, whose footer already carries Pullfrog
- * branding + rerun links.
+ * Net: the actionable classifications (billing, usage limit, API-key,
+ * model-not-found, no-provider-available, context-overflow, run time limit,
+ * transient-upstream, unclassified provider error) render identical bodies on
+ * both surfaces; the non-actionable ones (unexplained hang, generic) keep the
+ * forensics in the Actions job summary and show a calm one-liner in the PR
+ * comment, whose footer already carries Pullfrog branding + rerun links.
  */
 import type { AgentDiagnostic } from "./agentHangReport.ts";
 export type RenderedRunError = {

package/dist/utils/subprocess.d.ts

@@ -51,6 +51,7 @@ export interface SpawnOptions {
     killGroup?: boolean;
     retain?: RetainMode;
     maxRetainedBytes?: number;
+    signal?: AbortSignal | undefined;
 }
 /**
  * Bounded string accumulator that keeps the tail of appended chunks.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pullfrog",
-  "version": "0.1.96",
+  "version": "0.1.97",
   "cliContractVersion": "1",
   "type": "module",
   "bin": {