@wirecat/cli-base 0.65.2 → 0.65.4

package/CHANGELOG.md

@@ -8,6 +8,37 @@ Versions before 0.8.0 are in the [git tags](https://github.com/WireCatLabs/cli-b
 Every entry says what changed as a caller sees it, why, and what to watch for — the rules are
 [`docs/dev/CONVENTIONS.md`](docs/dev/CONVENTIONS.md#the-changelog).
 
+## 0.65.4 — 31.10.2026
+
+### Fixed
+
+- **A run with moved folders uses the app's own keyring entry again** ([WC-SECR-24](docs/standards/security.md#wc-secr-24--a-run-with-moved-folders-shares-the-owners-keyring-entry-and-never-deletes-it),
+  rewritten). `Credentials` with `isolated` reads and writes service `<app>`, not `<app>:<config folder>`, and no
+  longer saves to the moved folder's file first (the 0.65.1 redirect is gone). `keyringService` returns the app's
+  service whatever its other arguments say, so cli-core's sign-in key names the shared entry. Per-folder entries made
+  before are no longer read; they were copies made by throwaway runs. A secret 0.65.1 saved in a moved folder's file
+  is still read when the keyring has none.
+- **The handbook's statements about gcal match gcal-cli 0.2.0:** it has `session list`, its `api` checks
+  `events.notify` and `events.delete.series`, its `api` answers drop the passcode lines of a description and a
+  location, it serves MCP as `mcp serve`, it sets `requestMs` to 1.5 s, and it packs 144 files.
+
+### Security
+
+- **A moved run never deletes the owner's keyring entry.** A security review found that
+  `HOME=/tmp/x gcal personal session end` deleted the owner's real Google sign-in. With the system keyring,
+  `Credentials.remove` from a moved run keeps the entry, warns on stderr and leaves `"keyring"` out of what it
+  returns. A run counts as moved with `isolated`, or when the `env` it is given moves `HOME` or an XDG folder away from
+  the account's own home. The new `isMovedRun({ appName, prefix, env })` says the same for a CLI: pass it as
+  `isolated`, and check it before revoking a sign-in at the provider. A test with `memoryKeyring()` is unchanged.
+
+## 0.65.3 — 30.10.2026
+
+### Added
+
+- **A rule against per-call state in the command tree** (`WC-ARCH-22`, [Architecture](docs/standards/architecture.md)):
+  the tree is built once per process and a call's state lives in a per-call context. cli-core's `run()` still
+  rebuilds the tree per call and is the named exception until that is reworked.
+
 ## 0.65.2 — 29.10.2026
 
 ### Fixed

package/README.md

@@ -150,8 +150,8 @@ on macOS and Windows through `node-ci.yml` with `platforms: true`; here, Full va
 spawning `npm` and `tsc`). In every test the keyring is a fake, so no test reaches a real Keychain or Credential
 Manager.
 
-Two traps worth designing for: the keyring is global, so a throwaway config directory overwrites the real secret
-unless you pass `isolated: true`; and a locked Linux keyring can block on a prompt rather than fail.
+Two traps worth designing for: the keyring is global, so a throwaway config directory shares the owner's entry (pass
+`isolated: isMovedRun(…)` so it never deletes it); and a locked Linux keyring can block on a prompt rather than fail.
 
 ### Time, retries and deadlines
 

package/dist/credentials.d.ts

@@ -12,16 +12,12 @@ export interface CredentialsOptions {
     /** The keyring service name — the CLI's app name, e.g. `max-cli`, not its command word. */
     service: string;
     /**
-     * **True when the config directory came from the environment rather than the OS convention.**
+     * **True when the run's folders are not the owner's own** — pass `isMovedRun(…)`.
      *
-     * The OS keyring is global: an entry is addressed by service and account and knows nothing about
-     * which config directory asked for it. So a throwaway config directory looks isolated and is
-     * not — it overwrites the real secret for that account. In `brazecli` that destroyed two working
-     * keys on 2026-09-14, and a keyring entry cannot be read back out. Passing `true` here scopes the
-     * service name to the directory, making the isolation people already assume they have real.
-     *
-     * With the system keyring it also keeps new secrets out of it: they go to the file in the moved directory, so a test
-     * or worktree run leaves nothing in the owner's keyring (WC-SECR-24). A secret saved there before is still read.
+     * The run still uses the owner's keyring entry (`service`, the same account names): one sign-in per computer, not
+     * one per temp folder. With the system keyring, `remove` then keeps that entry instead of deleting it, so a test or
+     * worktree run cannot end the owner's real sign-in (WC-SECR-24). A moved `HOME` or XDG folder in `env` counts as
+     * moved even when this is false.
      */
     isolated?: boolean;
     /** Read before the keyring, for CI. */
@@ -33,7 +29,11 @@ export interface CredentialsOptions {
     /** Where the one-line warning goes when the keyring is unavailable. Never stdout. */
     warn?: (message: string) => void;
 }
-export declare const keyringService: (service: string, configDir: string, isolated?: boolean) => string;
+/**
+ * The keyring service a `Credentials` uses: the app's own, for a moved run too. The other two arguments are ignored
+ * and stay only so that callers written against 0.65.0 still compile.
+ */
+export declare const keyringService: (service: string, _configDir?: string, _isolated?: boolean) => string;
 /**
  * Environment first, then the OS keyring, then a file.
  *

package/dist/credentials.js

@@ -3,8 +3,13 @@ import { join } from "node:path";
 import { writeSecurely } from "./config.js";
 import { CliError } from "./errors.js";
 import { systemKeyring } from "./keyring.js";
+import { homeIsMoved } from "./paths.js";
 export const CREDENTIAL_STORAGE = ["auto", "keyring", "file"];
-export const keyringService = (service, configDir, isolated = false) => isolated ? `${service}:${configDir}` : service;
+/**
+ * The keyring service a `Credentials` uses: the app's own, for a moved run too. The other two arguments are ignored
+ * and stay only so that callers written against 0.65.0 still compile.
+ */
+export const keyringService = (service, _configDir, _isolated) => service;
 /**
  * Environment first, then the OS keyring, then a file.
  *
@@ -21,7 +26,7 @@ export class Credentials {
     #envVar;
     #fileName;
     #warn;
-    #fileFirst;
+    #keepsSharedEntry;
     #warned = false;
     constructor(options) {
         this.#configDir = options.configDir;
@@ -31,31 +36,24 @@ export class Credentials {
         this.#envVar = options.envVar;
         this.#fileName = options.fileName ?? "credentials.json";
         this.#warn = options.warn ?? ((message) => process.stderr.write(`${message}\n`));
-        this.#service = keyringService(options.service, options.configDir, options.isolated);
-        this.#fileFirst = options.isolated === true && this.#keyring === systemKeyring;
+        this.#service = options.service;
+        this.#keepsSharedEntry =
+            this.#keyring === systemKeyring && (options.isolated === true || homeIsMoved({ env: this.#env }));
     }
     read(account) {
         const fromEnv = this.#envVar ? this.#env[this.#envVar]?.trim() : undefined;
         if (fromEnv)
             return { secret: fromEnv, source: "environment" };
-        const fromFile = () => {
-            const secret = this.#readFile()?.[account]?.secret;
-            return secret ? { secret, source: "file" } : undefined;
-        };
-        if (this.#fileFirst) {
-            const found = fromFile();
-            if (found)
-                return found;
-        }
         if (this.#storage !== "file") {
             const fromKeyring = this.#tryKeyring(() => this.#keyring.get(this.#service, account));
             if (fromKeyring)
                 return { secret: fromKeyring, source: "keyring" };
         }
-        return this.#fileFirst ? undefined : fromFile();
+        const secret = this.#readFile()?.[account]?.secret;
+        return secret ? { secret, source: "file" } : undefined;
     }
     write(account, secret) {
-        if (this.#storage !== "file" && !this.#fileFirst) {
+        if (this.#storage !== "file") {
             const stored = this.#tryKeyring(() => {
                 this.#keyring.set(this.#service, account, secret);
                 return true;
@@ -74,7 +72,11 @@ export class Credentials {
     }
     remove(account) {
         const removed = [];
-        if (this.#storage !== "file" && this.#tryKeyring(() => this.#keyring.delete(this.#service, account))) {
+        if (this.#storage !== "file" && this.#keepsSharedEntry) {
+            this.#warn(`kept ${account} in the OS keyring: it is the owner's sign-in, shared with every run, and a run with moved ` +
+                "folders never removes it");
+        }
+        else if (this.#storage !== "file" && this.#tryKeyring(() => this.#keyring.delete(this.#service, account))) {
             removed.push("keyring");
         }
         const store = this.#readFile();

package/dist/index.d.ts

@@ -10,7 +10,7 @@ export { brokenKeyring, type KeyringStore, memoryKeyring, systemKeyring } from "
 export type { Logger } from "./logger.js";
 export { createRecordLog, logRecordOf, NOT_ALLOWED, REDACTED_FIELDS, type RecordInput, type RecordLogOptions, } from "./logging.js";
 export { createOutputBuffer, type OutputBuffer, type OutputBufferOptions } from "./output-buffer.js";
-export { configFilePath, type Paths, type PathsOptions, pathsAreOverridden, resolvePaths } from "./paths.js";
+export { configFilePath, isMovedRun, type Paths, type PathsOptions, pathsAreOverridden, resolvePaths } from "./paths.js";
 export { indent, type PrettyOptions, renderPretty } from "./pretty.js";
 export { createRenderer, RENDER_FORMATS, type Renderer, type RendererOptions, type RenderFormat, } from "./renderer.js";
 export { fieldsOf, projectFields } from "./result-fields.js";

package/dist/index.js

@@ -8,7 +8,7 @@ export { catchCrashes, errorObjectOf, errorRecordOf, exitCodeOfAnswer, exitCodeO
 export { brokenKeyring, memoryKeyring, systemKeyring } from "./keyring.js";
 export { createRecordLog, logRecordOf, NOT_ALLOWED, REDACTED_FIELDS, } from "./logging.js";
 export { createOutputBuffer } from "./output-buffer.js";
-export { configFilePath, pathsAreOverridden, resolvePaths } from "./paths.js";
+export { configFilePath, isMovedRun, pathsAreOverridden, resolvePaths } from "./paths.js";
 export { indent, renderPretty } from "./pretty.js";
 export { createRenderer, RENDER_FORMATS, } from "./renderer.js";
 export { fieldsOf, projectFields } from "./result-fields.js";

package/dist/paths.d.ts

@@ -31,4 +31,21 @@ export declare const defaultPaths: ({ appName, env, platform }: PathsOptions) =>
 export declare const resolvePaths: (options: PathsOptions) => Paths;
 /** Whether any of the three directories came from the environment rather than the OS convention. */
 export declare const pathsAreOverridden: ({ appName, prefix, env }: PathsOptions) => boolean;
+/**
+ * Whether `HOME` or an XDG (or Windows) folder in `env` puts the default folders anywhere but under the account's own
+ * home, which comes from the user database: `os.homedir()` returns `$HOME` and would miss exactly this. An account with
+ * no home entry counts as moved.
+ */
+export declare const homeIsMoved: ({ env, platform, home, }?: {
+    env?: NodeJS.ProcessEnv;
+    platform?: NodeJS.Platform;
+    home?: string | undefined;
+}) => boolean;
+/**
+ * **A run whose folders are not the owner's own**: a `<PREFIX>_*_DIR` override, or a moved `HOME` or XDG folder.
+ * It still shares the owner's keyring entry, so it must not delete or revoke it (WC-SECR-24).
+ */
+export declare const isMovedRun: (options: PathsOptions & {
+    home?: string | undefined;
+}) => boolean;
 export declare const configFilePath: (configDir: string, fileName?: string) => string;

package/dist/paths.js

@@ -1,4 +1,4 @@
-import { homedir } from "node:os";
+import { homedir, userInfo } from "node:os";
 import { join, posix, win32 } from "node:path";
 export const PATH_KINDS = ["config", "state", "cache"];
 const OVERRIDES = { config: "CONFIG_DIR", state: "STATE_DIR", cache: "CACHE_DIR" };
@@ -41,4 +41,30 @@ export const resolvePaths = (options) => {
 };
 /** Whether any of the three directories came from the environment rather than the OS convention. */
 export const pathsAreOverridden = ({ appName, prefix, env = process.env }) => PATH_KINDS.some((kind) => env[overrideName(appName, prefix, kind)] !== undefined);
+const accountHome = () => {
+    try {
+        return userInfo().homedir;
+    }
+    catch {
+        return undefined;
+    }
+};
+/**
+ * Whether `HOME` or an XDG (or Windows) folder in `env` puts the default folders anywhere but under the account's own
+ * home, which comes from the user database: `os.homedir()` returns `$HOME` and would miss exactly this. An account with
+ * no home entry counts as moved.
+ */
+export const homeIsMoved = ({ env = process.env, platform = process.platform, home = accountHome(), } = {}) => {
+    if (home === undefined)
+        return true;
+    const appName = "app";
+    const actual = defaultPaths({ appName, env, platform });
+    const owners = defaultPaths({ appName, env: { HOME: home, USERPROFILE: home }, platform });
+    return PATH_KINDS.some((kind) => actual[kind] !== owners[kind]);
+};
+/**
+ * **A run whose folders are not the owner's own**: a `<PREFIX>_*_DIR` override, or a moved `HOME` or XDG folder.
+ * It still shares the owner's keyring entry, so it must not delete or revoke it (WC-SECR-24).
+ */
+export const isMovedRun = (options) => pathsAreOverridden(options) || homeIsMoved(options);
 export const configFilePath = (configDir, fileName = "config.json") => join(configDir, fileName);

package/docs/standards/README.md

@@ -34,7 +34,7 @@ the four steps that need a person. A new CLI is ready for its first release when
 | [MCP](mcp.md) | `MCP` | 13 | The MCP tools, how they come from commands, what each permission shows |
 | [Accounts](accounts.md) | `ACCT` | 12 | The explicit profile, reads across accounts, scope flags, linked identities, sign-in commands |
 | [Permissions](permissions.md) | `PERM` | 22 | Levels, keys, defaults, hard limits, the write guard and its journal |
-| [Architecture](architecture.md) | `ARCH` | 17 | Layers, dependency direction, vendor types, what goes in which package |
+| [Architecture](architecture.md) | `ARCH` | 18 | Layers, dependency direction, vendor types, what goes in which package, the command tree built once |
 | [Lifecycle](lifecycle.md) | `LIFE` | 15 | Opening late, who closes, deadlines, long-running commands, the `serve` relay, resumable syncs and their request budget, the run log |
 | [Store](store.md) | `STORE` | 14 | Store areas, account scope, migrations, test isolation |
 | [Data model](data-model.md) | `DATA` | 9 | Core entities, entities and source records, `external_id`, field names, links and duplicates, files, calendar entries |

package/docs/standards/accounts.md

@@ -180,7 +180,6 @@ Every CLI that signs in has four commands under `session`:
   - tg, max and wa have `session start` and `session end`, no `session status`, and list their profiles with
     `account list` instead of `session list`.
   - drive has `session start`, `session list` and `session end`, and no `session status`.
-  - gcal has `session start`, `session status` and `session end`, and no `session list`.
   - zm has `session start` and `session status`, and no `session end` or `session list`.
   - memo signs in per mail account with `mail add` and has no `session` group.
 

package/docs/standards/architecture.md

@@ -230,6 +230,25 @@ out of search and listed under `skipped`, with the hint to run that CLI once.
 - **Applies to:** cli-core and every CLI with a provider of its own. **Since:** cli-base 0.53.0. **Rulings:** none
   (Wave 3 requirements 3.2).
 
+### WC-ARCH-22 · Build the command tree once; keep each call's state out of it
+
+The Commander tree — commands, options, help, actions — describes the CLI and is the same for every call, so it is
+built once per process. What belongs to one call (its streams, signal, deadline, environment, profile and parsed
+options, its hooks) lives in a per-call context that the action receives, never on the `Command` objects.
+
+- **Why:** state written into a shared tree leaks into the next call. Commander restores option values to what they
+  were before the *first* parse, so a profile set on the tree before parsing becomes every later call's starting
+  value, and a hook added per call runs once more each time. Building a fresh tree per call avoids the leak but costs
+  an MCP server ~16 ms per tool call for tg.
+- **Enforced by:** review only.
+- **Example:** a check that always gives the same answer for the same definition (`defineQuery`'s examples,
+  `assertSharedContracts`) runs once per definition, not per build. A new per-call value goes into the call's context,
+  not into `setOptionValue`, `hook` or `provide` on the tree.
+- **Exceptions:** cli-core's `run()` still builds a fresh tree per call, because it writes the call's environment,
+  a `preAction` hook and the profile into it; moving that to a per-call context is
+  [CORE-41](https://github.com/WireCatLabs/cli-core/blob/main/docs/dev/BACKLOG_LATER.md). New code does not add to it.
+- **Applies to:** cli-core's command skeleton and every CLI built on it. **Since:** cli-base 0.65.3. **Rulings:** none.
+
 ## Sources
 
 These documents explain the rules on this page in more detail. Where one of them disagrees with this page, this page

package/docs/standards/lifecycle.md

@@ -23,10 +23,10 @@ and [WC-SECR-2](security.md#wc-secr-2--a-log-keeps-only-known-attribute-keys-and
 - **WC-LIFE-15:** tg, max, wa, gcal and the template. drive, memo and zm do not keep runs yet; each is adding them on a
   `feat/runs` branch (2026-10-25). zm's `resolveSettings` also returns `keepFailedRuns: false`, which turns off the
   failure log cli-core's `run` would keep.
-- **WC-LIFE-16:** cli-core's shared calendar `sync`, from cli-core 0.464.0 (cli-core #2118); gcal gets it when it
-  moves up from cli-core 0.459.0. The deadlines of WC-LIFE-5 come with the same release. The other syncs
-  (`messages sync` in tg, max and wa, drive's `sync`, memo's mail import, zm's `recordings sync`) are cooperative but
-  spend no request budget yet, and gcal sets no `requestMs` of its own, so it uses the 2 s default.
+- **WC-LIFE-16:** cli-core's shared calendar `sync`, from cli-core 0.464.0 (cli-core #2118); gcal has it. The
+  deadlines of WC-LIFE-5 come with the same release. The other syncs (`messages sync` in tg, max and wa, drive's
+  `sync`, memo's mail import, zm's `recordings sync`) are cooperative but spend no request budget yet. gcal sets
+  `requestMs` to 1.5 s.
 
 ## One-shot commands
 
@@ -271,7 +271,7 @@ status command answers how far it is
   and the run loses its round; with one, every run ends with an answer, saves its work and says how to go on. One
   `requestMs` per CLI, in one place, keeps the arithmetic the same in every sync of that CLI.
 - **Enforced by:** `cli-core: src/background/budget.test.ts` · `cli-core: src/calendar/testing/sync-contract.ts`.
-- **Example:** `gcal personal sync` over MCP has 45 s: margin 6.75 s, so with the 2 s default about 19 requests. It
+- **Example:** `gcal personal sync` over MCP has 45 s: margin 6.75 s, so with gcal's 1.5 s about 25 requests. It
   answers `state: "partial"`, `stopped: "requests"`, `progress: { calendars, calendarsDone, requests, saved }`, and
   `next` with `gcal personal sync`; `gcal personal status` shows each calendar's progress. cli-core builds the budget
   with `runBudgetOf(command, maxPages)` from `@wirecat/cli-core/cli` over `runBudget` in

package/docs/standards/mcp.md

@@ -19,9 +19,8 @@ tg, max and wa serve cli-core's personal server (`<cli> <profile> mcp serve`) an
 `mcp serve --profiles` ([WC-MCP-9](#wc-mcp-9--a-server-serves-the-profiles-it-is-told-with-one-connection-for-each)) is not
 built yet: cli-core serves one named profile.
 zoom serves the three shared tools over its own commands from zoom-cli 0.35.0 (`zm <profile> mcp serve`, cli-core's
-`toolsFromCommands` and `runCommandForAgent`), and gcal does the same (`gcal <profile> mcp`; it moves to `mcp serve`
-when it takes cli-core 0.463.0). memo and drive have their own servers: memo has hand-written tools, and
-drive builds one tool per command from its command tree and skips commands through its own list. Those two are known
+`toolsFromCommands` and `runCommandForAgent`), and gcal does the same (`gcal <profile> mcp serve`). memo and drive have their own servers: memo has hand-written
+tools, and drive builds one tool per command from its command tree and skips commands through its own list. Those two are known
 gaps against these rules.
 
 WC-MCP-2 and WC-MCP-8 need cli-core 0.321.0, which tg, max and wa pin.

package/docs/standards/permissions.md

@@ -346,8 +346,7 @@ A messenger's keys come from its resources (`messages`, `chats`). Any other CLI
 - **Exceptions:** known gaps, as of 2026-10-27:
   - cli-core's `CALENDAR_WRITE_DEFAULTS` (`src/calendar/writer.ts`) still has `events create`, `update` and
     `respond` at `ask`.
-  - gcal's generated `api` commands default every write to `ask`, ordinary changes included, and check neither
-    `events.notify` nor `events.delete.series`.
+  - gcal's generated `api` commands default every write to `ask`, ordinary changes included.
   - drive keeps its own policy and `--read-only` flag, zoom reads its own `remote-meetings` key with `levelFor`, and
     memo uses cli-core's permissions for the shared commands only. None of them declares `commandPermissions` yet.
 - **Applies to:** every CLI that writes and is not a messenger. **Since:** cli-base 0.64.0 (the levels and the shared

package/docs/standards/releases.md

@@ -196,8 +196,9 @@ fixtures, `scripts/`, `.github/`, `bin/release`, `config/`, `lint/`, `contracts/
   `@wirecat/cli-base/release` fails on any path in `npm pack --dry-run` outside `allowed`. It checks the pack against
   the list it is given, not against this rule: a CLI that passes its own `files` list as `allowed`, as the template's
   `scripts/smoke.ts` does, checks only that npm packs what `files` says, and cannot fail on a wrong `files` list.
-  `npm pack --dry-run` in gcal-cli (2026-10-27) packs 256 files, `src/`, `scripts/`, `.github/`, `config/`,
-  `contracts/`, `lint/` and `template.json` among them, because its `files` list names them; its check cannot see it. The check this rule needs
+  `npm pack --dry-run` in gcal-cli packed 256 files on 2026-10-27, `src/`, `scripts/`, `.github/`, `config/`,
+  `contracts/`, `lint/` and `template.json` among them, because its `files` list named them; its check could not see
+  it. On 2026-10-31 (gcal-cli 0.2.0) it packs 144. The check this rule needs
   refuses the forbidden paths above whatever `files` says; it belongs in cli-template, so every CLI gets it by
   `upgrade` ([cli-template#77](https://github.com/WireCatLabs/cli-template/issues/77)).
 - **Exceptions:** cli-template's own package ships the skeleton's sources and configs, since `new` copies them; the

package/docs/standards/security.md

@@ -68,11 +68,10 @@ name. Any other top-level key is written as `[not allowed]`. A key that names co
 
 cli-base's `Credentials` reads the environment variable first (for CI), then the OS keyring, then a file with mode
 `0600`. The keyring service is the CLI's app name, `appName` in its identity (`max-cli`, `gcal-cli`, `cli-memo`), not
-the command word people type (`max`, `gcal`). When the config directory comes from the environment, the service name
-is scoped to that directory (`isolated: true`).
+the command word people type (`max`, `gcal`). A run with moved folders uses the same entry and never deletes it
+([WC-SECR-24](#wc-secr-24--a-run-with-moved-folders-shares-the-owners-keyring-entry-and-never-deletes-it)).
 
-- **Why:** the keyring is the safest store on the computer, and a throwaway config directory must not overwrite the
-  owner's real keyring entry.
+- **Why:** the keyring is the safest store on the computer.
 - **Enforced by:** `src/credentials.test.ts`.
 - **Example:** a bot token is read from `MAX_BOT_TOKEN`, then the keyring entry `bot:<profile>`, then the file.
 - **Exceptions:** `auto` storage tries the keyring and, when it fails, warns once on stderr and uses the file. A
@@ -322,28 +321,29 @@ store and runs no search. A CLI declares its provider and may replace any step.
   the provider and never touched the store: a generic API command removes the provider's passcode fields (Google's
   `conferenceData.entryPoints[].passcode`, `pin`, `accessCode`, `password`), the query of every join link and the
   dial sequence after a phone number, and the passcode lines of a description or a location.
-- **Exceptions:** a title that names a PIN or a password is kept: it is the meeting's name. Known gap, as of
-  2026-10-27: gcal's `api` answers drop the conference entry points' secrets (`src/conference.ts`) but keep the
-  description and location as Google sent them.
+- **Exceptions:** a title that names a PIN or a password is kept: it is the meeting's name.
 - **Applies to:** cli-core and every CLI that stores or shows meetings or calendar entries. **Since:** cli-base 0.57.1
   (output and agent answers: cli-base 0.65.0). **Rulings:** none (Wave 3 requirements 3.4).
 
-### WC-SECR-24 · A run with moved folders never writes the owner's system keyring
-
-- **Why:** with its folders moved (`<PREFIX>_CONFIG_DIR`, `<PREFIX>_STATE_DIR`, a throwaway `HOME` or `XDG_*`),
-  `Credentials` keys the keyring by `<app>:<config folder>` (`keyringService`, `isolated`). Each test run, agent check
-  or worktree that signs in then leaves its own copy of a sign-in in the owner's keyring, and nothing removes it.
-- **Enforced by:** `src/credentials.test.ts`.
-- **Example:** a test passes `memoryKeyring()`. An agent checking a built CLI signs in with file storage inside its
-  temp folder (`session start --credential-storage file`), or does not sign in. A run against the owner's real data
-  keeps the default folders, so it reads the owner's existing entry (`<app>` / `oauth:<provider>:<profile>`) instead
-  of making a new one. A throwaway `HOME` does not hide the keyring, which is reached over D-Bus: a run that must not
-  see it also runs with `DBUS_SESSION_BUS_ADDRESS` removed. With `isolated` and the system keyring, `Credentials`
-  saves new secrets to the private file in the moved config folder and only reads the keyring, for a secret saved
-  there before.
-- **Exceptions:** none.
-- **Applies to:** every CLI, its tests and every agent that runs a CLI. **Since:** the next cli-base release. **Rulings:** owner,
-  2026-10-29 (sign-ins copied per work folder should have reused the existing entry).
+### WC-SECR-24 · A run with moved folders shares the owner's keyring entry and never deletes it
+
+- **Why:** a per-folder keyring entry (`<app>:<config folder>`) left one copy of a sign-in for every test run, agent
+  check or worktree, about 1,500 of them in the owner's keyring, and nothing removed them. One entry per computer is
+  enough. But a moved run then reaches the owner's real sign-in: `HOME=/tmp/x gcal personal session end` deleted the
+  owner's Google sign-in, because only `<PREFIX>_*_DIR` counted as moved (a security review, 2026-10-30).
+- **Enforced by:** `src/credentials.test.ts` · `src/paths.test.ts`.
+- **Example:** a run is moved when `isMovedRun({ appName, prefix, env })` is true: a `<PREFIX>_CONFIG_DIR`,
+  `_STATE_DIR` or `_CACHE_DIR` override, or a `HOME` or XDG folder that puts the default folders anywhere but under
+  the account's own home. A CLI passes that as `isolated`. `Credentials` then reads and writes the app's own entry
+  (`<app>` / `oauth:<provider>:<profile>`), as a run with the default folders does. With the system keyring, its
+  `remove` keeps that entry, warns on stderr and leaves `"keyring"` out of what it returns; a moved `HOME` or XDG
+  folder in its `env` counts even when `isolated` is false. A CLI checks `isMovedRun` before it revokes a sign-in at
+  the provider, and says so when `session end` removed nothing. A test passes `memoryKeyring()`; a run that must not
+  see the keyring at all also runs with `DBUS_SESSION_BUS_ADDRESS` removed, since the keyring is reached over D-Bus.
+- **Exceptions:** a write from a moved run, such as `session start` in a worktree, replaces the owner's entry.
+- **Applies to:** every CLI, its tests and every agent that runs a CLI. **Since:** cli-base 0.65.4.
+  **Rulings:** owner, 2026-10-29 (sign-ins copied per work folder should have reused the existing entry); owner,
+  2026-10-30 (share the keyring entry, do not multiply it).
 
 ## Sources
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wirecat/cli-base",
-  "version": "0.65.2",
+  "version": "0.65.4",
   "description": "The parts every command line tool needs: output modes, terminal rendering, error model, exit codes, credentials, clocks",
   "license": "Apache-2.0",
   "author": "Viacheslav Ptsarev",