@askalf/dario 3.31.12 → 3.31.14

package/README.md

@@ -160,7 +160,7 @@ OAuth-backed Claude Max, billed against your plan instead of the API. Activated
 - **Drift detection** (v3.17). On startup dario probes the installed `claude` binary and compares against the captured template. Mismatch triggers a forced refresh and prints a one-line warning. Users never silently sit on a stale template again.
 - **Compat matrix** (v3.17, bumped in v3.19.5). `SUPPORTED_CC_RANGE` is encoded in code; installed CC outside the band prints a warn (untested above) or fail (below min) — zero-dep dotted-numeric comparator, no `semver` import per the dep policy.
 - **Billing tag** reconstructed using CC's own algorithm: `x-anthropic-billing-header: cc_version=<version>.<build_tag>; cc_entrypoint=cli; cch=<5-char-hex>;` where `build_tag = SHA-256(seed + chars[4,7,20] of user message + version).slice(0,3)`.
-- **OAuth config auto-detection** from the installed CC binary. When Anthropic rotates `client_id`, authorize URL, or scopes, dario picks up the new values on the next run without needing a release. Cache at `~/.dario/cc-oauth-cache-v4.json`, keyed by the CC binary fingerprint.
+- **OAuth config auto-detection** from the installed CC binary. When Anthropic rotates `client_id`, authorize URL, or scopes, dario picks up the new values on the next run without needing a release. Cache at `~/.dario/cc-oauth-cache-v6.json`, keyed by the CC binary fingerprint. Cache path bumps each time the canonical OAuth config shape changes so stale caches regenerate automatically on upgrade.
 - **Multi-account pool mode** — see [Multi-account pool mode](#multi-account-pool-mode). Automatic when 2+ accounts are configured.
 - **Framework scrubbing** — known third-party identity markers (`OpenClaw`, `sessions_*` prefixes, orchestration tags) stripped from system prompt and message content before the request leaves your machine.
 - **Atomic cache writes + cache corruption recovery** (v3.17). Template cache writes go through pid-qualified `.tmp` + `rename`, so an OS crash mid-write doesn't leave a half-written file. Unparseable cache files get quarantined to `cc-template.live.json.bad-<timestamp>` and dario self-heals on the next capture.
@@ -202,6 +202,8 @@ dario accounts list
 dario proxy
 ```
 
+If you already have a single-account `dario login` set up and run `dario accounts add <alias>` for the first time, dario **back-fills** your existing login credentials into the pool under the reserved alias `login` before running OAuth for the new alias. Net effect: your first `accounts add` gives you two pool accounts (login + new alias), pool mode activates immediately. Back-fill is one-shot, idempotent, and never touches your existing `credentials.json` — if you later `dario accounts remove` below the 2+ threshold, single-account mode reads it unchanged. Skipped if you explicitly pick `login` as the new alias — your intent wins.
+
 Each request picks the account with the highest headroom:
 
 ```
@@ -334,11 +336,13 @@ A version marker (`<!-- dario-sub-agent-version: X -->`) embedded in the markdow
 |---|---|
 | `dario login [--manual]` | Log in to the Claude backend. Detects CC credentials or runs its own OAuth flow. `--manual` (v3.20) mirrors CC's code-paste flow for SSH / container setups without a browser. |
 | `dario proxy` | Start the local API proxy on port 3456 |
-| `dario doctor` | Aggregated health report — dario / Node / runtime-TLS / CC binary + compat / template + drift / OAuth / pool / backends / sub-agent |
+| `dario doctor [--probe] [--auth-check] [--json]` | Aggregated health report — dario / Node / runtime-TLS / CC binary + compat / template + drift / OAuth / pool / backends / sub-agent. `--probe` (v3.31.7) hits the live `claude.ai/oauth/authorize` endpoint and surfaces the verdict, so scope-policy drift is catchable from a user's machine (not just CI). `--auth-check` (v3.31.9) opens a one-shot `x-api-key` listener and classifies whatever a client actually sends (match / mismatch / no-auth / timeout), with only redacted previews in output. `--json` (v3.31.8) emits structured output for claude-bridge's `/status`, deepdive's health probes, and CI scrapers. |
+| `dario config [--json]` | Prints the effective dario configuration with credentials redacted. Complementary to `doctor` — doctor answers *is it working?*, config answers *what IS it?* (v3.31.10) |
+| `dario upgrade` | Safe wrapper over `npm install -g @askalf/dario@latest` — probes npm for the `@latest` version first (3s timeout, 60s cache), refuses to run if already on latest, fails with a clear hint if npm is missing. (v3.31.10) |
 | `dario status` | Show Claude backend OAuth token health and expiry |
 | `dario refresh` | Force an immediate Claude token refresh |
 | `dario logout` | Delete stored Claude credentials |
-| `dario accounts list` / `add <alias>` / `remove <alias>` | Multi-account pool management |
+| `dario accounts list` / `add <alias>` / `remove <alias>` | Multi-account pool management. `add <alias>` on a fresh pool auto back-fills your existing `dario login` credentials as `login`, so your first `add` trips the 2+ pool threshold on its own — see [Multi-account pool mode](#multi-account-pool-mode). |
 | `dario backend list` / `add <name> --key=<key> [--base-url=<url>]` / `remove <name>` | OpenAI-compat backend management |
 | `dario shim -- <cmd> [args...]` | Run a child process with the in-process fetch patch (see [Shim mode](#shim-mode)) |
 | `dario subagent install` / `remove` / `status` | CC sub-agent lifecycle (v3.26 — see [sub-agent hook](#claude-code-sub-agent-hook-v326)) |
@@ -760,8 +764,19 @@ Yes — anything that speaks the OpenAI Chat Completions API. Groq, OpenRouter,
 **Something's wrong. Where do I start?**
 `dario doctor`. One command, one aggregated report — dario version, Node, platform, runtime/TLS classification, CC binary compat, template source + age + drift, OAuth status, pool state, backends, sub-agent install state, home dir. Exit code 1 if any check fails. Paste the output when you file an issue. (If you're inside Claude Code, `dario subagent install` once and then ask CC to "use the dario sub-agent to run doctor" — same output, no context switch.)
 
+**OpenClaw returns 401 after I set `DARIO_API_KEY` (or upgrade past v3.30.6).**
+If you run `dario proxy --host=0.0.0.0` (non-loopback), dario requires `DARIO_API_KEY` to be set so it's not an open subscription relay. OpenClaw 2026.2.17+ prefers `~/.openclaw/agents/main/agent/auth-profiles.json` over `openclaw.json`'s `apiKey` field or the `ANTHROPIC_API_KEY` env var — so if you have a stale Anthropic token in `auth-profiles.json` from an earlier setup, OpenClaw sends *that* token instead of `dario`, and dario rejects the request with `Authorization present but value mismatch` (visible under `dario proxy -v`, added in v3.31.2).
+
+Three fixes, in order of simplicity:
+
+1. **Use loopback.** `dario proxy --host=127.0.0.1` — auth only enforced on non-loopback binds, no `DARIO_API_KEY` required, no OpenClaw changes. Best if you don't actually need LAN reach to dario.
+2. **Delete the Anthropic auth profile.** Remove the `"anthropic:default"` entry from `~/.openclaw/agents/main/agent/auth-profiles.json`. OpenClaw then falls back through the config chain and picks up `ANTHROPIC_API_KEY=dario` from the env. Confirmed working by [@tetsuco in #97](https://github.com/askalf/dario/issues/97).
+3. **Overwrite the auth profile.** `openclaw models auth paste-token --provider anthropic` and paste `dario`. Replaces whatever key was in there — keep a backup if you use it elsewhere.
+
+Diagnose with `dario proxy -v` — the reject log (v3.31.2+) reports header-name only (never the value, since it may be a real credential you mistyped) and tells you which of the three configs is actually being hit.
+
 **What happens when Anthropic rotates the OAuth config?**
-Dario auto-detects OAuth config from the installed Claude Code binary. When CC ships a new version with rotated values, dario picks them up on the next run. Cache at `~/.dario/cc-oauth-cache-v4.json`, keyed by the CC binary fingerprint. (Path bumped from v3 → v4 in v3.19.4 to invalidate stale caches across the scope-list change that broke the authorize flow between CC v2.1.104 and v2.1.107.)
+Dario auto-detects OAuth config from the installed Claude Code binary. When CC ships a new version with rotated values, dario picks them up on the next run. Cache at `~/.dario/cc-oauth-cache-v6.json`, keyed by the CC binary fingerprint. The cache path version bumps each time the canonical OAuth config shape changes so stale caches regenerate automatically on upgrade — v3 → v4 in v3.19.4 (scope-list flip CC v2.1.104 → v2.1.107), v4 → v5 in v3.31.3 (authorize URL `claude.com/cai/` → `claude.ai/` host normalization), v5 → v6 in v3.31.4 (6-scope restore after CC v2.1.116).
 
 If Anthropic rotates the values before the detector is updated, you can temporarily override any field with env vars (`DARIO_OAUTH_CLIENT_ID`, `DARIO_OAUTH_AUTHORIZE_URL`, `DARIO_OAUTH_TOKEN_URL`, `DARIO_OAUTH_SCOPES`) or by writing `~/.dario/oauth-config.override.json`:
 
@@ -779,6 +794,9 @@ Env vars win over the file. Set `DARIO_OAUTH_DISABLE_OVERRIDE=1` to force pure a
 **What happens when Anthropic changes the CC request template?**
 Dario extracts the live request template from your installed Claude Code binary on startup — the system prompt, tool schemas, user-agent, beta flags, header insertion order, static header values, and top-level request-body key order — and uses those to replay requests instead of a version pinned into dario itself. When CC ships a new version with a tweaked template, the next `dario proxy` run picks it up automatically. Drift detection forces a refresh when the installed CC version changes under dario, and the nightly `cc-drift-watch` workflow catches upstream rotations (client_id, URLs, tool set, version) the day they ship on npm.
 
+**Why does `dario accounts list` show an account called `login` I never added?**
+That's your existing `dario login` credentials, back-filled into the pool automatically on your first `dario accounts add <alias>`. Pool mode activates at 2+ accounts in `~/.dario/accounts/`, and the single-account `credentials.json` store lives outside that directory — so without the back-fill, one `accounts add` would leave you at 1 pool entry and your login account orphaned. The `login` alias is reserved for this path. Safe to `dario accounts remove login` if you don't want it pooled; the original `credentials.json` is untouched by the back-fill, so single-account mode resumes reading it after removal drops you below the 2+ threshold. See [Multi-account pool mode](#multi-account-pool-mode) for the full picture.
+
 **First time setup on a fresh Claude account.**
 If dario is the first thing you run against a brand-new Claude account, prime the account with a few real Claude Code commands first:
 ```bash

package/dist/accounts.d.ts

@@ -23,3 +23,37 @@ export declare function _accountRefreshesInFlightSizeForTest(): number;
  */
 export declare function addAccountViaOAuth(alias: string): Promise<AccountCredentials>;
 export declare function getAccountsDir(): string;
+/**
+ * Alias reserved for credentials auto-migrated from the single-account
+ * `dario login` store. Named `login` so it's semantically obvious where
+ * the entry came from and unlikely to collide with user-chosen aliases
+ * like `work`, `personal`, etc. If a user specifically requests `login`
+ * as the alias for `dario accounts add`, the caller falls back to
+ * `default` so the migration doesn't step on the user's intent.
+ */
+export declare const MIGRATED_LOGIN_ALIAS = "login";
+/**
+ * Promote the user's existing single-account `dario login` credentials
+ * (`~/.dario/credentials.json`, `~/.claude/.credentials.json`, or OS
+ * keychain — whichever `loadCredentials` finds) into the pool under a
+ * reserved alias.
+ *
+ * Why: the pool activation threshold is 2+ accounts in `~/.dario/accounts/`.
+ * A user with one `dario login` account + one `dario accounts add bar`
+ * ends up with only one account in `accounts/` (bar), pool mode never
+ * trips, and the login account is effectively orphaned while pool is off.
+ * Calling this on the first `dario accounts add` back-fills the login
+ * account into the pool so the second `add` crosses the threshold.
+ *
+ * Idempotent: no-op if `accounts/` already has any entry, no-op if no
+ * credentials are reachable anywhere. Returns the alias written to, or
+ * `null` when nothing happened.
+ *
+ * The source `credentials.json` (if present) is left untouched — single-
+ * account mode still reads it if the user later `accounts remove`s down
+ * below the pool threshold. Migration is copy-only, never destructive.
+ *
+ * @param preferredAlias caller may request a specific alias. If it's
+ *   already the reserved `login` (or collides), falls back to `default`.
+ */
+export declare function ensureLoginCredentialsInPool(alias?: string): Promise<string | null>;

package/dist/accounts.js

@@ -2,10 +2,15 @@
  * Multi-account credential storage.
  *
  * Accounts live at `~/.dario/accounts/<alias>.json`. Single-account dario
- * still uses `~/.dario/credentials.json` and does not touch this module.
- * When `~/.dario/accounts/` contains 2+ files the proxy activates pool mode
- * (see pool.ts). Each account has its own independent OAuth lifecycle and
- * can refresh without affecting the others.
+ * uses `~/.dario/credentials.json` (plus the CC file + OS keychain fallback
+ * paths in oauth.ts). When `~/.dario/accounts/` contains 2+ files the proxy
+ * activates pool mode (see pool.ts). Each account has its own independent
+ * OAuth lifecycle and can refresh without affecting the others.
+ *
+ * `ensureLoginCredentialsInPool` (below) bridges the two stores on the
+ * first `dario accounts add` — it promotes the user's existing login
+ * credentials into the pool under a reserved alias so that adding a
+ * second account actually trips the 2+ threshold and activates pooling.
  *
  * OAuth config (client_id, scopes, authorize URL, token URL) comes from
  * dario's cc-oauth-detect scanner — the same source the single-account
@@ -17,6 +22,7 @@ import { homedir } from 'node:os';
 import { randomUUID, randomBytes, createHash } from 'node:crypto';
 import { createServer } from 'node:http';
 import { detectCCOAuthConfig } from './cc-oauth-detect.js';
+import { loadCredentials } from './oauth.js';
 const DARIO_DIR = join(homedir(), '.dario');
 const ACCOUNTS_DIR = join(DARIO_DIR, 'accounts');
 /**
@@ -308,3 +314,61 @@ export async function addAccountViaOAuth(alias) {
 export function getAccountsDir() {
     return ACCOUNTS_DIR;
 }
+/**
+ * Alias reserved for credentials auto-migrated from the single-account
+ * `dario login` store. Named `login` so it's semantically obvious where
+ * the entry came from and unlikely to collide with user-chosen aliases
+ * like `work`, `personal`, etc. If a user specifically requests `login`
+ * as the alias for `dario accounts add`, the caller falls back to
+ * `default` so the migration doesn't step on the user's intent.
+ */
+export const MIGRATED_LOGIN_ALIAS = 'login';
+/**
+ * Promote the user's existing single-account `dario login` credentials
+ * (`~/.dario/credentials.json`, `~/.claude/.credentials.json`, or OS
+ * keychain — whichever `loadCredentials` finds) into the pool under a
+ * reserved alias.
+ *
+ * Why: the pool activation threshold is 2+ accounts in `~/.dario/accounts/`.
+ * A user with one `dario login` account + one `dario accounts add bar`
+ * ends up with only one account in `accounts/` (bar), pool mode never
+ * trips, and the login account is effectively orphaned while pool is off.
+ * Calling this on the first `dario accounts add` back-fills the login
+ * account into the pool so the second `add` crosses the threshold.
+ *
+ * Idempotent: no-op if `accounts/` already has any entry, no-op if no
+ * credentials are reachable anywhere. Returns the alias written to, or
+ * `null` when nothing happened.
+ *
+ * The source `credentials.json` (if present) is left untouched — single-
+ * account mode still reads it if the user later `accounts remove`s down
+ * below the pool threshold. Migration is copy-only, never destructive.
+ *
+ * @param preferredAlias caller may request a specific alias. If it's
+ *   already the reserved `login` (or collides), falls back to `default`.
+ */
+export async function ensureLoginCredentialsInPool(alias = MIGRATED_LOGIN_ALIAS) {
+    if (!safeAliasPath(alias))
+        return null;
+    const existing = await listAccountAliases();
+    if (existing.length > 0)
+        return null;
+    const creds = await loadCredentials();
+    const tok = creds?.claudeAiOauth;
+    if (!tok?.accessToken || !tok?.refreshToken)
+        return null;
+    const identity = (await detectClaudeIdentity()) ?? {
+        deviceId: randomUUID(),
+        accountUuid: randomUUID(),
+    };
+    await saveAccount({
+        alias,
+        accessToken: tok.accessToken,
+        refreshToken: tok.refreshToken,
+        expiresAt: tok.expiresAt,
+        scopes: tok.scopes ?? [],
+        deviceId: identity.deviceId,
+        accountUuid: identity.accountUuid,
+    });
+    return alias;
+}

package/dist/cc-authorize-probe.js

@@ -131,7 +131,11 @@ export function buildProbeAuthorizeUrl(cfg) {
         scope: cfg.scopes,
         code_challenge: pkceChallenge(),
         code_challenge_method: 'S256',
-        state: base64url(randomBytes(16)),
+        // 32 bytes — match what CC v2.1.116+ actually sends. See dario#71.
+        // Shorter states produce "Invalid request format" from Anthropic's
+        // authorize endpoint, which the probe classifier would otherwise mis-
+        // attribute to drift when it's actually our own request shape.
+        state: base64url(randomBytes(32)),
     });
     return `${cfg.authorizeUrl}?${params.toString()}`;
 }

package/dist/cc-template-data.json

@@ -1,6 +1,6 @@
 {
-  "_version": "2.1.118",
-  "_captured": "2026-04-23T15:14:02.377Z",
+  "_version": "2.1.119",
+  "_captured": "2026-04-24T13:28:12.469Z",
   "_source": "bundled",
   "_schemaVersion": 3,
   "agent_identity": "You are a Claude agent, built on Anthropic's Claude Agent SDK.",
@@ -484,7 +484,7 @@
     },
     {
       "name": "Monitor",
-      "description": "Start a background monitor that streams events from a long-running script. Each stdout line is an event — you keep working and notifications arrive in the chat. Events arrive on their own schedule and are not replies from the user, even if one lands while you're waiting for the user to answer a question.\n\nMonitor is for the **streaming** case: \"tell me every time X happens.\" For one-shot \"wait until X is done,\" use Bash with run_in_background instead — you'll get a completion notification when it exits.\n\nYour script's stdout is the event stream. Each line becomes a notification. Exit ends the watch.\n\n  # Each matching log line is an event\n  tail -f /var/log/app.log | grep --line-buffered \"ERROR\"\n\n  # Each file change is an event\n  inotifywait -m --format '%e %f' /watched/dir\n\n  # Poll GitHub for new PR comments and emit one line per new comment\n  last=$(date -u +%Y-%m-%dT%H:%M:%SZ)\n  while true; do\n    now=$(date -u +%Y-%m-%dT%H:%M:%SZ)\n    gh api \"repos/owner/repo/issues/123/comments?since=$last\" --jq '.[] | \"\\(.user.login): \\(.body)\"'\n    last=$now; sleep 30\n  done\n\n  # Node script that emits events as they arrive (e.g. WebSocket listener)\n  node watch-for-events.js\n\n**Script quality:**\n- Always use `grep --line-buffered` in pipes — without it, pipe buffering delays events by minutes.\n- In poll loops, handle transient failures (`curl ... || true`) — one failed request shouldn't kill the monitor.\n- Poll intervals: 30s+ for remote APIs (rate limits), 0.5-1s for local checks.\n- Write a specific `description` — it appears in every notification (\"errors in deploy.log\" not \"watching logs\").\n- Only stdout is the event stream. Stderr goes to the output file (readable via Read) but does not trigger notifications — for a command you run directly (e.g. `python train.py 2>&1 | grep --line-buffered ...`), merge stderr with `2>&1` so its failures reach your filter. (No effect on `tail -f` of an existing log — that file only contains what its writer redirected.)\n\n**Coverage — silence is not success.** When watching a job or process for an outcome, your filter must match every terminal state, not just the happy path. A monitor that greps only for the success marker stays silent through a crashloop, a hung process, or an unexpected exit — and silence looks identical to \"still running.\" Before arming, ask: *if this process crashed right now, would my filter emit anything?* If not, widen it.\n\n  # Wrong — silent on crash, hang, or any non-success exit\n  tail -f run.log | grep --line-buffered \"elapsed_steps=\"\n\n  # Right — one alternation covering progress + the failure signatures you'd act on\n  tail -f run.log | grep -E --line-buffered \"elapsed_steps=|Traceback|Error|FAILED|assert|Killed|OOM\"\n\nFor poll loops checking job state, emit on every terminal status (`succeeded|failed|cancelled|timeout`), not just success. If you cannot confidently enumerate the failure signatures, broaden the grep alternation rather than narrow it — some extra noise is better than missing a crashloop.\n\n**Output volume**: Every stdout line is a conversation message, so the filter should be selective — but selective means \"the lines you'd act on,\" not \"only good news.\" Never pipe raw logs; use `grep --line-buffered`, `awk`, or a wrapper that emits exactly the success and failure signals you care about. Monitors that produce too many events are automatically stopped; restart with a tighter filter if this happens.\n\nStdout lines within 200ms are batched into a single notification, so multiline output from a single event groups naturally.\n\nThe script runs in the same shell environment as Bash. Exit ends the watch (exit code is reported). Timeout → killed. Set `persistent: true` for session-length watches (PR monitoring, log tails) — the monitor runs until you call TaskStop or the session ends. Use TaskStop to cancel early.",
+      "description": "Start a background monitor that streams events from a long-running script. Each stdout line is an event — you keep working and notifications arrive in the chat. Events arrive on their own schedule and are not replies from the user, even if one lands while you're waiting for the user to answer a question.\n\nPick by how many notifications you need:\n- **One** (\"tell me when the server is ready / the build finishes\") → use **Bash with `run_in_background`** and a command that exits when the condition is true, e.g. `until grep -q \"Ready in\" dev.log; do sleep 0.5; done`. You get a single completion notification when it exits.\n- **One per occurrence, indefinitely** (\"tell me every time an ERROR line appears\") → Monitor with an unbounded command (`tail -f`, `inotifywait -m`, `while true`).\n- **One per occurrence, until a known end** (\"emit each CI step result, stop when the run completes\") → Monitor with a command that emits lines and then exits.\n\nYour script's stdout is the event stream. Each line becomes a notification. Exit ends the watch.\n\n  # Each matching log line is an event\n  tail -f /var/log/app.log | grep --line-buffered \"ERROR\"\n\n  # Each file change is an event\n  inotifywait -m --format '%e %f' /watched/dir\n\n  # Poll GitHub for new PR comments and emit one line per new comment\n  last=$(date -u +%Y-%m-%dT%H:%M:%SZ)\n  while true; do\n    now=$(date -u +%Y-%m-%dT%H:%M:%SZ)\n    gh api \"repos/owner/repo/issues/123/comments?since=$last\" --jq '.[] | \"\\(.user.login): \\(.body)\"'\n    last=$now; sleep 30\n  done\n\n  # Node script that emits events as they arrive (e.g. WebSocket listener)\n  node watch-for-events.js\n\n  # Per-occurrence with a natural end: emit each CI check as it lands, exit when the run completes\n  prev=\"\"\n  while true; do\n    s=$(gh pr checks 123 --json name,bucket)\n    cur=$(jq -r '.[] | select(.bucket!=\"pending\") | \"\\(.name): \\(.bucket)\"' <<<\"$s\" | sort)\n    comm -13 <(echo \"$prev\") <(echo \"$cur\")\n    prev=$cur\n    jq -e 'all(.bucket!=\"pending\")' <<<\"$s\" >/dev/null && break\n    sleep 30\n  done\n\n**Don't use an unbounded command for a single notification.** `tail -f`, `inotifywait -m`, and `while true` never exit on their own, so the monitor stays armed until timeout even after the event has fired. For \"tell me when X is ready,\" use Bash `run_in_background` with an `until` loop instead (one notification, ends in seconds). Note that `tail -f log | grep -m 1 ...` does *not* fix this: if the log goes quiet after the match, `tail` never receives SIGPIPE and the pipeline hangs anyway.\n\n**Script quality:**\n- Always use `grep --line-buffered` in pipes — without it, pipe buffering delays events by minutes.\n- In poll loops, handle transient failures (`curl ... || true`) — one failed request shouldn't kill the monitor.\n- Poll intervals: 30s+ for remote APIs (rate limits), 0.5-1s for local checks.\n- Write a specific `description` — it appears in every notification (\"errors in deploy.log\" not \"watching logs\").\n- Only stdout is the event stream. Stderr goes to the output file (readable via Read) but does not trigger notifications — for a command you run directly (e.g. `python train.py 2>&1 | grep --line-buffered ...`), merge stderr with `2>&1` so its failures reach your filter. (No effect on `tail -f` of an existing log — that file only contains what its writer redirected.)\n\n**Coverage — silence is not success.** When watching a job or process for an outcome, your filter must match every terminal state, not just the happy path. A monitor that greps only for the success marker stays silent through a crashloop, a hung process, or an unexpected exit — and silence looks identical to \"still running.\" Before arming, ask: *if this process crashed right now, would my filter emit anything?* If not, widen it.\n\n  # Wrong — silent on crash, hang, or any non-success exit\n  tail -f run.log | grep --line-buffered \"elapsed_steps=\"\n\n  # Right — one alternation covering progress + the failure signatures you'd act on\n  tail -f run.log | grep -E --line-buffered \"elapsed_steps=|Traceback|Error|FAILED|assert|Killed|OOM\"\n\nFor poll loops checking job state, emit on every terminal status (`succeeded|failed|cancelled|timeout`), not just success. If you cannot confidently enumerate the failure signatures, broaden the grep alternation rather than narrow it — some extra noise is better than missing a crashloop.\n\n**Output volume**: Every stdout line is a conversation message, so the filter should be selective — but selective means \"the lines you'd act on,\" not \"only good news.\" Never pipe raw logs; use `grep --line-buffered`, `awk`, or a wrapper that emits exactly the success and failure signals you care about. Monitors that produce too many events are automatically stopped; restart with a tighter filter if this happens.\n\nStdout lines within 200ms are batched into a single notification, so multiline output from a single event groups naturally.\n\nThe script runs in the same shell environment as Bash. Exit ends the watch (exit code is reported). Timeout → killed. Set `persistent: true` for session-length watches (PR monitoring, log tails) — the monitor runs until you call TaskStop or the session ends. Use TaskStop to cancel early.",
       "input_schema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",
@@ -973,7 +973,7 @@
   "anthropic_beta": "claude-code-20250219,interleaved-thinking-2025-05-14,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advisor-tool-2026-03-01,effort-2025-11-24,afk-mode-2026-01-31",
   "header_values": {
     "accept": "application/json",
-    "user-agent": "claude-cli/2.1.118 (external, sdk-cli)",
+    "user-agent": "claude-cli/2.1.119 (external, sdk-cli)",
     "x-stainless-arch": "x64",
     "x-stainless-lang": "js",
     "x-stainless-os": "Windows",
@@ -998,5 +998,5 @@
     "output_config",
     "stream"
   ],
-  "_supportedMaxTested": "2.1.118"
+  "_supportedMaxTested": "2.1.119"
 }

package/dist/cli.js

@@ -38,7 +38,7 @@ import { homedir } from 'node:os';
 import { startAutoOAuthFlow, startManualOAuthFlow, detectHeadlessEnvironment, getStatus, refreshTokens, loadCredentials } from './oauth.js';
 import { startProxy, sanitizeError } from './proxy.js';
 import { VALID_EFFORT_VALUES } from './cc-template.js';
-import { listAccountAliases, loadAllAccounts, addAccountViaOAuth, removeAccount } from './accounts.js';
+import { listAccountAliases, loadAllAccounts, addAccountViaOAuth, removeAccount, ensureLoginCredentialsInPool, MIGRATED_LOGIN_ALIAS } from './accounts.js';
 import { listBackends, saveBackend, removeBackend } from './openai-backend.js';
 const args = process.argv.slice(2);
 const command = args[0] ?? 'proxy';
@@ -463,6 +463,22 @@ async function accounts() {
             console.error(`[dario] Account "${alias}" already exists. Remove it first with \`dario accounts remove ${alias}\`.`);
             process.exit(1);
         }
+        // If the user has `dario login` credentials on disk or in the keychain
+        // and the pool is empty, migrate those credentials into the pool first.
+        // Otherwise the new account lives alone in accounts/, pool mode never
+        // trips the 2+ threshold, and the login account is orphaned from the
+        // pool until the user figures out they have to re-`accounts add` it.
+        // Skip silently when the user explicitly picks the reserved alias —
+        // their intent wins, they can run `accounts add` again for the login
+        // migration under a different alias.
+        if (existing.length === 0 && alias !== MIGRATED_LOGIN_ALIAS) {
+            const migrated = await ensureLoginCredentialsInPool();
+            if (migrated) {
+                console.log('');
+                console.log(`  Migrated your existing \`dario login\` account into the pool as "${migrated}".`);
+                console.log(`  (Pool mode activates on 2+ accounts — this back-fill plus "${alias}" crosses that.)`);
+            }
+        }
         console.log('');
         console.log(`  Adding account "${alias}" to the pool...`);
         console.log('');

package/dist/index.d.ts

@@ -9,7 +9,7 @@ export type { OAuthTokens, CredentialsFile } from './oauth.js';
 export { startProxy, sanitizeError } from './proxy.js';
 export { AccountPool, parseRateLimits } from './pool.js';
 export type { PoolAccount, PoolStatus, RateLimitSnapshot, AccountIdentity } from './pool.js';
-export { listAccountAliases, loadAccount, loadAllAccounts, saveAccount, removeAccount, refreshAccountToken, addAccountViaOAuth, getAccountsDir, } from './accounts.js';
+export { listAccountAliases, loadAccount, loadAllAccounts, saveAccount, removeAccount, refreshAccountToken, addAccountViaOAuth, ensureLoginCredentialsInPool, MIGRATED_LOGIN_ALIAS, getAccountsDir, } from './accounts.js';
 export type { AccountCredentials } from './accounts.js';
 export { Analytics } from './analytics.js';
 export type { RequestRecord, AnalyticsSummary } from './analytics.js';

package/dist/index.js

@@ -10,7 +10,7 @@ export { startProxy, sanitizeError } from './proxy.js';
 // contains 2+ accounts; see README for the progression from single-account
 // mode to pool mode).
 export { AccountPool, parseRateLimits } from './pool.js';
-export { listAccountAliases, loadAccount, loadAllAccounts, saveAccount, removeAccount, refreshAccountToken, addAccountViaOAuth, getAccountsDir, } from './accounts.js';
+export { listAccountAliases, loadAccount, loadAllAccounts, saveAccount, removeAccount, refreshAccountToken, addAccountViaOAuth, ensureLoginCredentialsInPool, MIGRATED_LOGIN_ALIAS, getAccountsDir, } from './accounts.js';
 export { Analytics } from './analytics.js';
 // Multi-provider backends (v3.6.0+). Secondary OpenAI-compat providers
 // (OpenAI, OpenRouter, Groq, local LiteLLM, etc.) configured via

package/dist/oauth.js

@@ -198,7 +198,10 @@ async function saveCredentials(creds) {
 export async function startAutoOAuthFlow() {
     const { createServer } = await import('node:http');
     const { codeVerifier, codeChallenge } = generatePKCE();
-    const state = base64url(randomBytes(16));
+    // 32 random bytes → 43-char base64url state. See dario#71 — Anthropic's
+    // authorize endpoint rejects shorter states with "Invalid request format";
+    // CC v2.1.116+ ships 32. Keep in lockstep with CC's entropy-per-state.
+    const state = base64url(randomBytes(32));
     return new Promise((resolve, reject) => {
         const server = createServer((req, res) => {
             const url = new URL(req.url || '', `http://${req.headers.host || 'localhost'}`);
@@ -387,7 +390,8 @@ export function detectHeadlessEnvironment() {
  */
 export async function startManualOAuthFlow() {
     const { codeVerifier, codeChallenge } = generatePKCE();
-    const state = base64url(randomBytes(16));
+    // 32 bytes — same reason as startAutoOAuthFlow. See dario#71.
+    const state = base64url(randomBytes(32));
     const cfg = await getOAuthConfig();
     const authUrl = buildManualAuthorizeUrl(cfg, codeChallenge, state);
     console.log('');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@askalf/dario",
-  "version": "3.31.12",
+  "version": "3.31.14",
   "description": "A local LLM router. One endpoint, every provider — Claude subscriptions, OpenAI, OpenRouter, Groq, local LiteLLM, any OpenAI-compat endpoint — your tools don't need to change.",
   "type": "module",
   "bin": {
@@ -69,7 +69,7 @@
     "node": ">=18.0.0"
   },
   "devDependencies": {
-    "@types/node": "^22.0.0",
+    "@types/node": "^25.6.0",
     "tsx": "^4.19.0",
     "typescript": "^5.7.0"
   }