residoo 0.8.3 → 0.8.5

package/README.md

@@ -97,7 +97,7 @@ while losing rows, then fixed in public against the classes it was losing
 
 ## What it does
 
-- Scans your local AI-agent session transcripts for 50 high-confidence
+- Scans your local AI-agent session transcripts for 56 high-confidence
   secret patterns: cloud provider keys, private key blocks, OAuth/API
   tokens, database connection strings, and more. See
   [`src/patterns.js`](src/patterns.js).
@@ -219,7 +219,7 @@ prompt. There is no recovery if you lose it, so pick one you keep.
 
 ## Sources supported today
 
-43 sources, real-install-verified for Claude Code and its config family,
+44 sources, real-install-verified for Claude Code and its config family,
 multi-source-corroborated for the rest (Cursor, Codex CLI, Cline, Windsurf,
 Gemini CLI, Copilot, and 30+ more). Full list, what "corroborated" means,
 and how to add one: [docs/sources.md](docs/sources.md).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "residoo",
-  "version": "0.8.3",
+  "version": "0.8.5",
   "description": "Find secrets leaking through your AI coding agent's session history. Zero network calls in the scan path, zero dependencies.",
   "license": "MIT",
   "author": "CloudRoam (https://cloudroam.io)",

package/src/patterns.js

@@ -46,6 +46,46 @@ const PATTERNS = [
   // paste sk_live at go-live.
   { id: "stripe_test_key", label: "Stripe API key (test mode)", confidence: "high",
     re: /\b(sk|rk)_test_[A-Za-z0-9]{20,250}\b/g },
+  // Stripe webhook signing secret. Found missing by reading TruffleHog's
+  // own open-issue tracker (trufflesecurity/trufflehog#4711 and #4609,
+  // both open, both unaddressed) -- a real, disclosed gap, not unique to
+  // residoo: neither TruffleHog nor gitleaks (checked gitleaks.toml
+  // directly) has this rule either, and no exact-length spec is published
+  // anywhere found (Stripe's own docs name the whsec_ prefix but not a
+  // length). Shipped anyway on the strength of the prefix alone: "whsec_"
+  // is distinctive enough on its own that a generous length bound carries
+  // negligible false-positive risk even without a confirmed exact count,
+  // unlike a short/generic prefix where that same generosity would matter.
+  { id: "stripe_webhook_secret", label: "Stripe webhook signing secret", confidence: "high",
+    re: /\bwhsec_[A-Za-z0-9]{24,64}\b/g },
+  // Azure AD (Entra ID) client secret. Found missing by cross-checking
+  // gitleaks' own open-issue tracker (gitleaks/gitleaks#1687), which
+  // asked for Azure coverage generally -- gitleaks itself already has a
+  // rule (id "azure-ad-client-secret" in its own gitleaks.toml), so this
+  // is adapted directly from that battle-tested pattern rather than
+  // designed from scratch: 2-4 chars, one digit, the literal "Q~"
+  // marker, then 28-36 more chars. No capture group (unlike gitleaks'
+  // Go regex), to match every other rule in this file using the whole
+  // match as the value; zero-width lookaround used instead of gitleaks'
+  // literal delimiter character classes for the same reason -- the
+  // charset includes non-word characters (~ .) that a plain \b boundary
+  // can't reliably bound. Azure Storage Account keys were investigated
+  // and NOT added: they're a bare, unprefixed base64 blob (~88 chars,
+  // confirmed via learn.microsoft.com), the same unsafe generic shape
+  // already excluded for Weights & Biases' classic key format.
+  { id: "azure_ad_client_secret", label: "Azure AD (Entra ID) client secret", confidence: "high",
+    re: /(?<![A-Za-z0-9_.~-])[A-Za-z0-9_.~]{2,4}\dQ~[A-Za-z0-9_.~-]{28,36}(?![A-Za-z0-9_.~-])/g },
+  // Tailscale auth key. Found missing via gitleaks/gitleaks#1778 (still
+  // open there too). No fully authoritative current spec found: Tailscale's
+  // own kb/1085/auth-keys page shows an older bare "tskey-<hex>" example,
+  // while more recent third-party usage consistently shows a newer
+  // "tskey-auth-<id>-<secret>" two-segment form -- genuine format
+  // evolution, not a single confirmed shape. Covers both on the strength
+  // of the "tskey-" prefix alone, which carries negligible false-positive
+  // risk regardless of which era's exact body shape is present, same
+  // reasoning as whsec_ above.
+  { id: "tailscale_auth_key", label: "Tailscale auth key", confidence: "high",
+    re: /\btskey-(?:auth-)?[A-Za-z0-9-]{15,80}\b/g },
   // The negative lookahead keeps this rule mutually exclusive with anthropic_key
   // and openrouter_key below — without it, "sk-ant-..." or "sk-or-v1-..." match
   // BOTH this pattern and the more specific one, and get reported twice under
@@ -272,6 +312,25 @@ const PATTERNS = [
   // than a doc-confirmed exact count.
   { id: "posthog_key", label: "PostHog personal API key", confidence: "high",
     re: /\bphx_[A-Za-z0-9]{40,}\b/g },
+  // Claude Code Remote Control session URL -- not a vendor API key, a URL
+  // that IS a bearer credential: opening it in a browser grants full
+  // read/write/execute access to a live local Claude Code session, no
+  // further auth. Anthropic's own docs (code.claude.com/docs/en/remote-control,
+  // fetched 2026-09-04) confirm this URL is printed directly into the
+  // conversation ("Claude Code also posts the session URL in the
+  // conversation") -- i.e. this genuinely lands in the exact transcripts
+  // this project scans, not a hypothetical risk. Found via a gitleaks
+  // open-issue request (gitleaks/gitleaks#2094) that proposed a
+  // `session_<id>` prefix as "illustrative," unconfirmed. That guess was
+  // checked against this project's own installed `claude` binary (macOS,
+  // `strings /usr/local/bin/claude`) rather than assumed correct: the
+  // literal web-URL template is `` `/code/${sessionId}` `` with NO prefix
+  // at all, and `sessionId:mqH.randomUUID()` confirms the ID is a
+  // standard UUID v4 -- both directly present in the shipped binary's own
+  // strings, not inferred. The gitleaks issue's proposed pattern would
+  // have MISSED every real instance of this URL.
+  { id: "claude_code_remote_control_url", label: "Claude Code Remote Control session URL", confidence: "high",
+    re: /\bclaude\.ai\/code\/[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\b/g },
   // LangSmith personal access token (lsv2_pt_) / service key (lsv2_sk_).
   // Found missing by cross-checking agentsweep's own open-issue tracker.
   // The first segment (32 hex, UUID-shaped) is consistent across every

package/src/rotation.js

@@ -203,6 +203,45 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "Test mode is not harmless: the key grants full API access to the sandbox account, and its leak marks a workflow that will handle live keys the same way.",
   },
+  // Fetched docs.stripe.com/webhooks (2026-09-04), "Roll endpoint signing
+  // secrets periodically" section: the exact steps below are quoted from
+  // that section, not inferred.
+  stripe_webhook_secret: {
+    label: "Stripe webhook signing secret",
+    consolePath: "dashboard.stripe.com/webhooks > select the endpoint",
+    steps: [
+      "Open the endpoint in the Webhooks tab of Workbench",
+      "Overflow menu (...) > Roll secret",
+      "Choose immediate expiration for a compromised secret, or up to 24h delay to migrate your verification code first (both secrets stay valid during that window)",
+    ],
+    revokeNote: "A leaked webhook secret alone can't drain funds or read data -- it only lets an attacker forge fake Stripe-Signature headers to a webhook endpoint that trusts them, so this is a spoofing/logic-bypass risk, not an account-access one. Still worth rolling promptly: it's what stands between a webhook handler and forged events.",
+  },
+  // Fetched learn.microsoft.com (2026-09-04), Azure App Registration
+  // secret management docs: steps below are the documented
+  // create-update-verify-delete rotation flow, not guessed.
+  azure_ad_client_secret: {
+    label: "Azure AD (Entra ID) client secret",
+    consolePath: "Microsoft Entra ID > App registrations > [app] > Certificates & secrets",
+    steps: [
+      "Create a new client secret on the same app registration first (New client secret)",
+      "Update whatever used the old one with the new value, and verify it works",
+      "Only then delete the leaked secret (trash icon next to it), to minimize downtime",
+    ],
+    revokeNote: "Deletion is immediate. Prefer create-then-delete over delete-then-create if the app can tolerate two live secrets briefly -- it avoids an outage window for whatever depends on this secret.",
+  },
+  // Fetched tailscale.com/kb/1085/auth-keys (2026-09-04): exact console
+  // path and the important revoke-vs-deauthorize distinction are quoted
+  // from that page, not inferred.
+  tailscale_auth_key: {
+    label: "Tailscale auth key",
+    consolePath: "console.tailscale.com/admin/settings/keys",
+    steps: [
+      "Open the Keys page of the admin console",
+      "Find the key in the table and select Revoke",
+      "If a node already used this key to join your tailnet, also delete that node from the Machines page -- revoking the key alone does not deauthorize nodes already using it",
+    ],
+    revokeNote: "Revoking is immediate for future use of the key, but any node it already authorized stays connected until separately removed from Machines -- the two are not the same action.",
+  },
   // help.openai.com articles 5112595 and 8304786 exist (surfaced by search)
   // but the help center serves HTTP 403 to this project's fetcher, so no URL
   // is shipped: unverifiable end to end fails the bar above.
@@ -772,6 +811,21 @@ const ROTATION_GUIDANCE = {
     ],
     revokeNote: "Deletion is immediate; the key stops authenticating on the next request.",
   },
+  // Not a vendor API key with a console to rotate it in -- a session URL
+  // that IS the credential. Steps below per code.claude.com/docs/en/
+  // remote-control (fetched 2026-09-04): disconnect terminates the URL's
+  // access immediately; there is no separate "revoke" step to perform
+  // afterward the way there is for a leaked API key.
+  claude_code_remote_control_url: {
+    label: "Claude Code Remote Control session URL",
+    consolePath: "the terminal running the session, or claude.ai/code's session list",
+    steps: [
+      "In the terminal running the session, run /remote-control again to disconnect (or use the status panel's disconnect option)",
+      "If you no longer have terminal access, end the local session entirely -- Remote Control access ends with it",
+      "Start a fresh Remote Control session if you still need one; it gets a new, unrelated URL",
+    ],
+    revokeNote: "Disconnecting invalidates the URL immediately -- your local session keeps running in the terminal either way, only the remote-access link is torn down. There is no separate token to also revoke at a vendor console.",
+  },
   // Fetched docs.langchain.com/langsmith/create-account-api-key
   // (2026-09-04): both personal access tokens and service keys are
   // created and managed from the workspace's own API Keys settings page.

package/src/sources/atlassian-rovo-dev.js

@@ -0,0 +1,179 @@
+"use strict";
+
+const fs = require("fs");
+const path = require("path");
+const os = require("os");
+
+/**
+ * Atlassian Rovo Dev CLI (`acli rovodev`) — Atlassian's terminal coding
+ * agent. Closed-source (part of the Atlassian CLI), so unlike continue.js
+ * this cannot be grounded in the project's own source code; grounded
+ * instead in Atlassian's own support docs, which is the strongest source
+ * available for a closed-source tool.
+ *
+ * VERIFICATION STATUS: not checked against a real install (no `acli` on
+ * this machine, no `~/.rovodev` directory). Confirmed via
+ * support.atlassian.com/rovo/docs/manage-sessions-in-rovo-dev-cli/
+ * (fetched 2026-09-04): "Sessions are stored by default at
+ * `~/.rovodev/sessions/`", with two named files per session:
+ * `session_context.json` ("full conversation history and context") and
+ * `metadata.json` ("session metadata like title, workspace, and fork
+ * information"). The docs page does not explicitly state whether these
+ * live directly under `sessions/` or one level down per session -- but
+ * since the same two filenames are named for every session, and a flat
+ * layout would mean every session's `session_context.json` collides on
+ * the same path, a per-session subdirectory
+ * (`sessions/<session-id>/session_context.json`) is the only layout
+ * consistent with the docs as written, not a guess pulled from nowhere.
+ * Ships on that reasoning per CONTRIBUTING.md rule 3; `available()`
+ * requires only the root `~/.rovodev` directory, so a wrong subdirectory
+ * assumption fails as "no sessions found," never a false "nothing here."
+ *
+ * The config file (`~/.rovodev/config.yml`, also documented) is not
+ * scanned: `--project`-mode-style config coverage is deliberately scoped
+ * to the handful of tools this project already has a dedicated config
+ * reader for, and a single YAML settings file is a small enough surface
+ * that adding it as a bespoke one-off here wasn't judged worth the
+ * inconsistency with how every other tool's config gets read.
+ */
+const ROOT = path.join(os.homedir(), ".rovodev");
+const SESSIONS_DIR = path.join(ROOT, "sessions");
+
+function id() { return "atlassian-rovo-dev"; }
+function label() { return "Atlassian Rovo Dev CLI"; }
+
+function available() {
+  try { return fs.statSync(ROOT).isDirectory(); } catch { return false; }
+}
+
+/** Same defensive symlink-following pattern used throughout src/sources -- see continue.js's docstring for the full reasoning. */
+function isKindFollowingSymlink(fullPath, dirent, checkFn) {
+  if (checkFn(dirent)) return true;
+  if (!dirent.isSymbolicLink()) return false;
+  try { return checkFn(fs.statSync(fullPath)); } catch { return false; }
+}
+const isDirFollowingSymlink = (p, d) => isKindFollowingSymlink(p, d, (x) => x.isDirectory());
+const isFileFollowingSymlink = (p, d) => isKindFollowingSymlink(p, d, (x) => x.isFile());
+
+function resolveDirState(dirPath) {
+  let lst;
+  try { lst = fs.lstatSync(dirPath); } catch { return "absent"; }
+  if (lst.isDirectory()) return "ok";
+  if (lst.isSymbolicLink()) {
+    try { return fs.statSync(dirPath).isDirectory() ? "ok" : "broken"; }
+    catch { return "broken"; }
+  }
+  return "absent";
+}
+
+function* yieldFileEntry(file, dirent) {
+  if (!dirent.isFile()) {
+    const resolved = isFileFollowingSymlink(file, dirent);
+    if (!resolved) {
+      if (dirent.isSymbolicLink()) yield { file, broken: true };
+      return;
+    }
+  }
+  let stat;
+  try { stat = fs.statSync(file); } catch { yield { file, broken: true }; return; }
+  yield { file, mtimeMs: stat.mtimeMs, sizeBytes: stat.size, broken: false };
+}
+
+/**
+ * Walks sessions/<session-id>/{session_context.json,metadata.json} per the
+ * inferred layout above. If a future/different real layout turns out to be
+ * flat instead, this also picks up session_context.json/metadata.json
+ * sitting directly in sessions/ itself (an entry that fails the
+ * is-a-directory check below is just skipped as "not a session dir", never
+ * reported broken), so the more conservative of the two guesses degrades
+ * gracefully rather than reporting a false all-clear.
+ */
+function* files() {
+  const state = resolveDirState(SESSIONS_DIR);
+  if (state === "broken") { yield { file: SESSIONS_DIR, broken: true }; return; }
+  if (state !== "ok") return; // no sessions/ yet — normal, not broken
+
+  let entries;
+  try { entries = fs.readdirSync(SESSIONS_DIR, { withFileTypes: true }); }
+  catch { yield { file: SESSIONS_DIR, broken: true }; return; }
+
+  for (const e of entries) {
+    const p = path.join(SESSIONS_DIR, e.name);
+
+    if (e.name === "session_context.json" || e.name === "metadata.json") {
+      yield* yieldFileEntry(p, e);
+      continue;
+    }
+
+    if (!isDirFollowingSymlink(p, e)) {
+      if (e.isSymbolicLink()) yield { file: p, broken: true };
+      continue; // some other stray entry — out of scope, not broken
+    }
+
+    let innerEntries;
+    try { innerEntries = fs.readdirSync(p, { withFileTypes: true }); }
+    catch { yield { file: p, broken: true }; continue; }
+
+    for (const ie of innerEntries) {
+      if (ie.name !== "session_context.json" && ie.name !== "metadata.json") continue;
+      yield* yieldFileEntry(path.join(p, ie.name), ie);
+    }
+  }
+}
+
+const MAX_JSON_DOC_BYTES = 512 * 1024 * 1024; // generous backstop, no real large example to size against — see continue.js's MAX_JSON_DOC_BYTES for the same admitted status
+const READ_TIMEOUT_MS = 60_000;
+
+/**
+ * Whole-document JSON read with the same streamed-read/timeout/size-cap
+ * discipline as every other whole-document reader in src/sources (see
+ * continue.js's readJsonDocumentFile for the full reasoning) — reused by
+ * pattern, not import, per this project's one-small-self-contained-file
+ * convention. A document that isn't valid JSON (corrupted, truncated, or a
+ * genuinely different real format than inferred above) is scanned as one
+ * raw line rather than discarded.
+ */
+async function readLines(file) {
+  let stat;
+  try { stat = fs.statSync(file); }
+  catch { return { lines: [], status: "failed", bytesRead: 0 }; }
+  if (stat.size > MAX_JSON_DOC_BYTES) return { lines: [], status: "too-large", bytesRead: 0 };
+
+  let text = "";
+  let tooLarge = false;
+  const stream = fs.createReadStream(file, { encoding: "utf-8" });
+  const timer = setTimeout(() => stream.destroy(new Error("read timed out")), READ_TIMEOUT_MS);
+
+  const readCleanly = await new Promise((resolve) => {
+    stream.on("data", (chunk) => {
+      text += chunk;
+      if (!tooLarge && Buffer.byteLength(text, "utf-8") > MAX_JSON_DOC_BYTES) {
+        tooLarge = true;
+        stream.destroy();
+      }
+    });
+    stream.once("end", () => resolve(true));
+    stream.once("error", () => resolve(false));
+  });
+  clearTimeout(timer);
+
+  if (tooLarge) return { lines: [], status: "too-large", bytesRead: 0 };
+
+  const bytesRead = Buffer.byteLength(text, "utf-8");
+  if (!readCleanly && bytesRead === 0) return { lines: [], status: "failed", bytesRead: 0 };
+  const status = readCleanly ? "complete" : "partial";
+  if (text.length === 0) return { lines: [], status, bytesRead };
+
+  try {
+    const parsed = JSON.parse(text);
+    // No confirmed internal schema for session_context.json's history
+    // shape (closed source, see header) -- scanned as one flattened
+    // document rather than decomposed per-message the way continue.js
+    // does, so nothing inside it is assumed about that isn't confirmed.
+    return { lines: [JSON.stringify(parsed)], status, bytesRead };
+  } catch {
+    return { lines: [text], status, bytesRead };
+  }
+}
+
+module.exports = { id, label, available, files, readLines };

package/src/sources/index.js

@@ -134,6 +134,12 @@ const antigravityCli = require("./antigravity-cli");
 const kimiCode = require("./kimi-code");
 const fx = require("./fx");
 
+const atlassianRovoDev = require("./atlassian-rovo-dev");
+// Sourcegraph Amp investigated and deliberately not included: its own docs
+// describe threads as syncing to ampcode.com "across devices," and no local
+// cache/offline copy of thread content is documented anywhere found — the
+// same cloud-only reasoning as Augment Code/CodeGPT above, not missed.
+
 const ALL_SOURCES = [
   claudeCode,
   agentConfigs,
@@ -178,6 +184,7 @@ const ALL_SOURCES = [
   antigravityCli,
   kimiCode,
   fx,
+  atlassianRovoDev,
 ];
 
 function availableSources() {