residoo 0.18.0 → 0.20.0

package/README.md

@@ -175,6 +175,13 @@ gap, none catches every case, and all are re-includable with
 certainty — true of every tool in this category, including the well-
 established ones.
 
+- **No mobile app.** Researched, not assumed: residoo's file-scanning
+  approach cannot port to stock iOS under Apple's own sandboxing model,
+  and every alternative mechanism checked (a keyboard extension, a local
+  VPN content filter) has a specific, disqualifying problem. See
+  [docs/platform-scope.md](docs/platform-scope.md) for the full technical
+  verdict and what would change it.
+
 ## Install
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "residoo",
-  "version": "0.18.0",
+  "version": "0.20.0",
   "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/cli.js

@@ -186,8 +186,8 @@ Watch:
                           same meaning as scan
   --no-notify             skip the OS desktop notification watch fires for
                           each genuinely new finding (macOS via osascript,
-                          Linux via notify-send if installed; no built-in
-                          mechanism on Windows -- disclosed, not attempted).
+                          Linux via notify-send if installed, Windows via
+                          System.Windows.Forms.NotifyIcon's balloon-tip API).
                           On by default in human-readable mode: watch's own
                           purpose is alerting you, and a background process
                           nobody is watching a terminal for needs more than
@@ -217,7 +217,15 @@ MCP:
 Cred:
   residoo cred set <name> --env <ENV_VAR_NAME> [--env <ENV_VAR_NAME_2> ...]
                           store a live credential in the OS keychain
-                          (macOS/Linux only), one or more env-var names
+                          (macOS/Linux only -- genuinely unsupported on
+                          Windows, not just undone yet: this needs a NAMED
+                          store you can write once and read back later,
+                          and Windows has none reachable without an extra
+                          dependency. Different from --seal --keychain
+                          below, which Windows DOES support via DPAPI --
+                          that one only ever needs to wrap/unwrap a key
+                          living inside its own vault directory, never a
+                          named lookup), one or more env-var names
                           mapped to hidden-typed values. Interactive TTY
                           only, no scripted entry: a live credential is
                           more sensitive than a vault passphrase and
@@ -338,10 +346,19 @@ Seal options (used with scan):
                           in the OS keychain instead of a typed passphrase.
                           Nothing to remember, and the key's strength no longer
                           depends on passphrase choice. macOS today; Linux when
-                          secret-tool (libsecret) is installed. TRADEOFF: a
-                          keychain-backed vault lives on THIS machine/account
+                          secret-tool (libsecret) is installed; Windows via
+                          DPAPI (a different mechanism, not a Windows Credential
+                          Manager entry -- cmdkey.exe is confirmed write-only,
+                          it can never read a stored password back out). TRADEOFF:
+                          a keychain-backed vault lives on THIS machine/account
                           only, unlike a passphrase, it is not portable to
-                          another machine.
+                          another machine. On Windows specifically, the DPAPI-
+                          wrapped key travels INSIDE the vault directory itself
+                          (there's no separate OS-level store to put it in,
+                          unlike macOS/Linux) -- still undecryptable without
+                          being logged in as the same Windows user on the same
+                          machine, but a real, disclosed difference from macOS/
+                          Linux's fully separate keychain entry.
   --vault-dir <dir>       where to create the vault (default: ./residoo-vault-<stamp>)
   --upload-cloudroam      ALSO upload the sealed vault to CloudRoam. One of two
                           opt-in features that touch the network (--verify
@@ -402,31 +419,70 @@ async function getPassphrase({ confirmNew }) {
  * sealFindings/deriveKey path a typed passphrase would use — scrypt on a
  * full 256-bit-entropy input is harmless extra defense, and reusing that
  * already-tested path means no change to sealcrypto.js/sealvault.js at all.
+ *
+ * `winKeyBlob` is Windows' equivalent of `vaultId`: there is no OS-level
+ * named credential store on Windows (see keychain.js's own
+ * wrapVaultKeyWindows docstring for exactly why, and why this is a
+ * DIFFERENT mechanism from `vaultId`'s macOS/Linux keychain.store(), not a
+ * Windows branch inside it), so instead of a lookup id, the caller gets
+ * back the actual DPAPI-wrapped key blob to persist itself once the vault
+ * directory exists — the one place on Windows with a rule-compliant
+ * reason to write it.
  */
 async function resolveSealSecret(args) {
   if (!args.includes("--keychain")) {
-    return { passphrase: await getPassphrase({ confirmNew: true }), vaultId: null };
+    return { passphrase: await getPassphrase({ confirmNew: true }), vaultId: null, winKeyBlob: null };
   }
+  const passphrase = crypto.randomBytes(32).toString("base64");
   const keychain = require("./keychain");
+  if (process.platform === "win32") {
+    if (!keychain.isVaultKeySupported()) throw new Error("--keychain: DPAPI is not available on this system.");
+    return { passphrase, vaultId: null, winKeyBlob: keychain.wrapVaultKeyWindows(passphrase) };
+  }
   if (!keychain.isSupported()) throw new Error(`--keychain: ${keychain.unsupportedReason()}`);
   const vaultId = crypto.randomUUID();
-  const passphrase = crypto.randomBytes(32).toString("base64");
   keychain.store(vaultId, passphrase);
-  return { passphrase, vaultId };
+  return { passphrase, vaultId, winKeyBlob: null };
 }
 
-/** The unsealing secret for `unseal`: a keychain-retrieved key, or a typed passphrase. */
+/**
+ * The unsealing secret for `unseal`: a keychain-retrieved key, or a typed
+ * passphrase. Checked by which MARKER FILE is actually present in the
+ * vault directory, not by the current machine's platform — a vault sealed
+ * on Windows carries `.keychain-key-win`, one sealed on macOS/Linux
+ * carries `.keychain-id`, and trying to unseal one on the wrong kind of
+ * machine should say so clearly rather than silently mis-routing.
+ */
 async function resolveUnsealSecret(args, vaultDir) {
   if (!args.includes("--keychain")) return getPassphrase({ confirmNew: false });
   const keychain = require("./keychain");
-  if (!keychain.isSupported()) throw new Error(`--keychain: ${keychain.unsupportedReason()}`);
+  const winKeyPath = path.join(vaultDir, ".keychain-key-win");
   const idPath = path.join(vaultDir, ".keychain-id");
+
+  if (fs.existsSync(winKeyPath)) {
+    if (!keychain.isVaultKeySupported()) {
+      throw new Error(
+        `This vault was sealed with --keychain on Windows (DPAPI-backed). DPAPI keys are tied to that ` +
+        `Windows user account and cannot be unwrapped on ${process.platform} — unseal it on that same Windows machine.`
+      );
+    }
+    try {
+      return keychain.unwrapVaultKeyWindows(fs.readFileSync(winKeyPath, "utf-8").trim());
+    } catch {
+      throw new Error(
+        "Could not decrypt this vault's key via Windows DPAPI. It may have been sealed under a different " +
+        "Windows user account or moved to a different machine — a keychain-backed vault is not portable."
+      );
+    }
+  }
+
   if (!fs.existsSync(idPath)) {
     throw new Error(
-      `No .keychain-id marker in ${vaultDir}: this vault was not sealed with --keychain, ` +
+      `No .keychain-id or .keychain-key-win marker in ${vaultDir}: this vault was not sealed with --keychain, ` +
       `or the marker file was moved separately from the vault. Try unsealing without --keychain.`
     );
   }
+  if (!keychain.isSupported()) throw new Error(`--keychain: ${keychain.unsupportedReason()}`);
   const vaultId = fs.readFileSync(idPath, "utf-8").trim();
   try {
     return keychain.retrieve(vaultId);
@@ -467,7 +523,7 @@ async function runSeal(result, args) {
 
   const stamp = new Date().toISOString().replace(/[:.]/g, "-").slice(0, 19);
   const vaultDir = argValue(args, "--vault-dir") || path.resolve(`residoo-vault-${stamp}`);
-  const { passphrase, vaultId } = await resolveSealSecret(args);
+  const { passphrase, vaultId, winKeyBlob } = await resolveSealSecret(args);
 
   process.stdout.write(`\nSealing ${filesWithFindings.length} file(s) with findings into ${vaultDir}\n`);
   const { entries } = await sealFindings({
@@ -479,6 +535,13 @@ async function runSeal(result, args) {
   // keychain lookup, never the key itself and never anything about what the
   // vault contains.
   if (vaultId) fs.writeFileSync(path.join(vaultDir, ".keychain-id"), vaultId, { mode: 0o600 });
+  // Windows' equivalent marker -- unlike .keychain-id, this DOES hold
+  // sensitive material (the DPAPI-wrapped key itself, not a lookup id),
+  // which is exactly the disclosed security-property trade-off
+  // keychain.js's wrapVaultKeyWindows docstring names: on Windows the
+  // wrapped key travels with the vault, decryptable only by the same
+  // Windows user account, rather than living in a fully separate store.
+  if (winKeyBlob) fs.writeFileSync(path.join(vaultDir, ".keychain-key-win"), winKeyBlob, { mode: 0o600 });
   const totalPlain = entries.reduce((s, e) => s + e.plainBytes, 0);
   const totalSealed = entries.reduce((s, e) => s + e.sealedBytes, 0);
   process.stdout.write(
@@ -1188,4 +1251,10 @@ async function main(argv) {
   return failOnFind && (secretGate || integrityWarnCount(integrity) > 0) ? 1 : 0;
 }
 
-module.exports = { main };
+// resolveSealSecret/resolveUnsealSecret are exported alongside `main`
+// specifically so tests/smoke.js can exercise their Windows (DPAPI) branch
+// directly: a spawned subprocess (this file's usual CLI-testing precedent)
+// always runs on the REAL host platform, so it can never exercise
+// win32-only logic on a non-Windows build machine -- calling these two
+// in-process, with process.platform mocked, is the only way to.
+module.exports = { main, resolveSealSecret, resolveUnsealSecret };

package/src/integrity.js

@@ -3,6 +3,12 @@
 const fs = require("fs");
 const path = require("path");
 const os = require("os");
+// Not destructured: kept as `cp.execFileSync(...)` at every call site so a
+// test can monkey-patch `require("child_process").execFileSync` (the same
+// shared module object) the way tests/smoke.js's notify.js tests already
+// do -- a destructured `const { execFileSync } = ...` would copy the
+// reference at import time and never see a later patch.
+const cp = require("child_process");
 const { PATTERNS, redact } = require("./patterns");
 
 /**
@@ -677,7 +683,59 @@ function checkIntegrity({ home = os.homedir(), cwd = process.cwd(), projectMode
     }
   }
 
-  // ---- 5. credential-vault file permissions (HOME only, POSIX only) ------
+  // Windows NTFS ACL check for one credential-vault file, the win32
+  // counterpart to the POSIX `stat.mode` check below -- Node's fs.Stats.mode
+  // on Windows does not reflect NTFS ACLs at all, so this shells out to
+  // PowerShell's Get-Acl instead, the same "invoke the OS's own tool"
+  // pattern keychain.js already uses for macOS's `security` and Linux's
+  // `secret-tool`. Verified against Microsoft's own Get-Acl documentation
+  // (learn.microsoft.com/powershell/module/microsoft.powershell.security/get-acl)
+  // and cross-checked against independent write-ups, not live-tested
+  // against a real Windows install -- disclosed the same way copilot-cli.js's
+  // own header discloses "corroborated but unverified against a real
+  // install" for a source built without one available. icacls was
+  // considered and rejected: research found it has no `/findsid` switch
+  // and its text output is not reliably parseable, unlike Get-Acl's typed
+  // object model.
+  //
+  // Every field is projected through an explicit PSCustomObject (never the
+  // raw IdentityReference/FileSystemRights/AccessControlType objects) so
+  // JSON serialization is forced to plain strings regardless of how those
+  // .NET types would otherwise serialize -- and the result is wrapped in an
+  // array via `-InputObject` (not piped) specifically because ConvertTo-Json
+  // collapses a single-item collection into a bare object rather than a
+  // one-element array when piped, a well-known PowerShell gotcha that would
+  // otherwise break parsing on the (common) case of a file with exactly one
+  // relevant ACE.
+  //
+  // English-locale principal names only (Everyone, BUILTIN\Users, NT
+  // AUTHORITY\Authenticated Users) -- a disclosed, not silent, gap: a
+  // non-English Windows install localizes these names (e.g. "Jeder" for
+  // Everyone in German) and would not match here, the same kind of named
+  // scope limit ibanValid's per-country-length gap and the OCR module's
+  // English-only wordlist already carry elsewhere in this project.
+  function checkWindowsCredentialAcl(file) {
+    const escaped = file.replace(/'/g, "''");
+    const script =
+      "$ErrorActionPreference='Stop'; " +
+      `$acl = Get-Acl -LiteralPath '${escaped}'; ` +
+      "$rules = @($acl.Access | ForEach-Object { [PSCustomObject]@{ " +
+      "Identity = $_.IdentityReference.Value; Rights = $_.FileSystemRights.ToString(); Type = $_.AccessControlType.ToString() } }); " +
+      "ConvertTo-Json -InputObject $rules -Compress";
+    const out = cp.execFileSync("powershell.exe", ["-NoProfile", "-NonInteractive", "-Command", script], { encoding: "utf-8" });
+    let rules;
+    try { rules = JSON.parse(out); } catch { return null; }
+    if (!Array.isArray(rules)) rules = [rules];
+    const BROAD_PRINCIPAL = /^(everyone|builtin\\users|nt authority\\authenticated users|users)$/i;
+    const READ_CAPABLE_RIGHTS = /fullcontrol|modify|read/i;
+    const hits = rules.filter((r) =>
+      r && typeof r.Identity === "string" && typeof r.Type === "string" && typeof r.Rights === "string" &&
+      r.Type === "Allow" && BROAD_PRINCIPAL.test(r.Identity.trim()) && READ_CAPABLE_RIGHTS.test(r.Rights));
+    if (hits.length === 0) return { tooOpen: false };
+    return { tooOpen: true, detail: hits.map((h) => `${h.Identity} (${h.Rights})`).join(", ") };
+  }
+
+  // ---- 5. credential-vault file permissions (HOME only, POSIX and win32) -
   // GitGuardian's "State of Secrets Sprawl 2026" (blog.gitguardian.com,
   // published 2026-03-17) found 24,008 unique secrets in MCP-related config
   // files on public GitHub, 8.8% of them still live -- these files
@@ -700,13 +758,14 @@ function checkIntegrity({ home = os.homedir(), cwd = process.cwd(), projectMode
   // naive backup restore, or a shared-volume container mount can each
   // silently widen a file's mode without the tool that wrote it ever
   // knowing, the same way SSH itself checks id_rsa's permissions rather
-  // than trusting whoever created it. Windows is skipped entirely, not
-  // approximated: Node's fs.Stats.mode on Windows does not reflect NTFS
-  // ACLs, so a POSIX-style bit check there would be meaningless rather than
-  // merely imprecise. Project mode is skipped too -- none of these are ever
+  // than trusting whoever created it. Windows gets its own NTFS-ACL-based
+  // check (checkWindowsCredentialAcl above), not a POSIX-bit approximation
+  // -- Node's fs.Stats.mode on Windows does not reflect NTFS ACLs at all,
+  // so pretending otherwise would be meaningless, not merely imprecise.
+  // Project mode is skipped on every platform -- none of these are ever
   // project-scoped files by any vendor's own design, so there is no
   // project-relative equivalent to check.
-  if (!projectMode && process.platform !== "win32") {
+  if (!projectMode) {
     const geminiDir = process.env.GEMINI_CLI_HOME
       ? path.join(process.env.GEMINI_CLI_HOME, ".gemini")
       : path.join(home, ".gemini");
@@ -739,6 +798,24 @@ function checkIntegrity({ home = os.homedir(), cwd = process.cwd(), projectMode
         }
         continue;
       }
+
+      if (process.platform === "win32") {
+        let acl = null;
+        try { acl = checkWindowsCredentialAcl(file); } catch { acl = null; }
+        if (!acl) {
+          mark(file, "unreadable");
+          add("warn", "unreadable-config", file, "credential file exists but its NTFS permissions could not be checked (Get-Acl failed): unverified, not clean");
+          continue;
+        }
+        mark(file, "checked");
+        if (acl.tooOpen) {
+          const shown = display(file);
+          add("warn", "insecure-credential-permissions", file,
+            `${note}; NTFS permissions grant ${acl.detail} access to a live credential on this machine. Fix: right-click "${shown}" > Properties > Security > Advanced, and remove any group other than your own account and the system/administrators.`);
+        }
+        continue;
+      }
+
       mark(file, "checked");
       const openBits = stat.mode & 0o077;
       if (openBits !== 0) {

package/src/keychain.js

@@ -1,6 +1,11 @@
 "use strict";
 
-const { execFileSync } = require("child_process");
+// Not destructured: kept as `cp.execFileSync(...)` at every call site so a
+// test can monkey-patch `require("child_process").execFileSync` (the same
+// shared module object) the way tests/smoke.js's Windows-path tests do for
+// both this file and integrity.js -- a destructured `const { execFileSync
+// } = ...` would copy the reference at import time and never see a patch.
+const cp = require("child_process");
 
 /**
  * OS-native secure credential storage for `scan --seal --keychain` and
@@ -64,7 +69,7 @@ function isSupported() {
   if (process.platform === "darwin") return true;
   if (process.platform === "linux") {
     try {
-      execFileSync("which", ["secret-tool"], { stdio: "ignore" });
+      cp.execFileSync("which", ["secret-tool"], { stdio: "ignore" });
       return true;
     } catch {
       return false;
@@ -78,9 +83,108 @@ function unsupportedReason() {
   if (process.platform === "linux") {
     return "secret-tool (libsecret) is not installed. Install it (e.g. \"apt install libsecret-tools\" or \"dnf install libsecret\") or omit --keychain to use a passphrase instead.";
   }
+  if (process.platform === "win32") {
+    // Specifically about THIS by-name store/retrieve/remove API (residoo
+    // cred's only use of it) -- `--seal --keychain` works on Windows via a
+    // different, vault-relative mechanism (wrapVaultKeyWindows/
+    // unwrapVaultKeyWindows below), so this message must not read as "no
+    // --keychain support at all on Windows," which would be wrong.
+    return "residoo cred needs a named credential store, and Windows has none reachable without an extra dependency " +
+      "(cmdkey.exe can store a credential but never reads its password back -- confirmed against Microsoft's own docs). " +
+      "--seal --keychain works on Windows through a different mechanism; this specific store is what's unavailable.";
+  }
   return `--keychain is not supported on ${process.platform} yet. Omit --keychain to use a passphrase instead.`;
 }
 
+/**
+ * True when wrapVaultKeyWindows/unwrapVaultKeyWindows (below) can run --
+ * Windows only, since DPAPI is a Windows-specific API. Deliberately
+ * SEPARATE from isSupported() above: that function is about the by-name
+ * store()/retrieve()/remove() API (false on Windows -- no OS-level named
+ * credential store is reachable there without an extra dependency, since
+ * cmdkey.exe is confirmed write/list-only, never returning a stored
+ * password). This one is about the vault-relative wrap/unwrap pair, which
+ * exists only because `--seal --keychain` has a legitimate place (the
+ * vault directory itself) to put a DPAPI-wrapped blob -- `residoo cred`
+ * has no such place and does not use this.
+ */
+function isVaultKeySupported() {
+  return process.platform === "win32";
+}
+
+/**
+ * Windows-only DPAPI (Data Protection API) wrap/unwrap for `--seal
+ * --keychain`'s vault key, via a PowerShell shell-out -- the same
+ * "invoke the OS's own tool" pattern as macOS's `security` and Linux's
+ * `secret-tool` above, but a materially different SHAPE, and why these
+ * two functions exist separately from store()/retrieve() rather than as a
+ * Windows branch inside them.
+ *
+ * Windows has no OS-level "store this under a name, fetch it back by that
+ * name later" service the way macOS Keychain/secret-tool do. Verified
+ * directly, not assumed: `cmdkey.exe` (Windows Credential Manager's own
+ * CLI) can WRITE a generic credential but Microsoft's own documentation
+ * states plainly "Passwords are not displayed after they're stored," and
+ * `/list` only ever surfaces target names and usernames -- cmdkey is
+ * write/list-only, and cannot serve a store-then-retrieve flow at all.
+ * DPAPI (`System.Security.Cryptography.ProtectedData`, confirmed reachable
+ * from stock PowerShell 5.1 via `Add-Type -AssemblyName System.Security`
+ * with zero extra installs -- learn.microsoft.com/dotnet/standard/security/
+ * how-to-use-data-protection) is the real built-in alternative, but it is
+ * a stateless encrypt/decrypt PRIMITIVE, not a named registry: something
+ * still has to decide where the encrypted bytes are persisted.
+ *
+ * That is why wrapVaultKeyWindows only WRAPS a secret and hands the
+ * encrypted blob straight back to its caller -- this module never decides
+ * where it lives. `--seal --keychain` (cli.js's resolveSealSecret/
+ * resolveUnsealSecret) is the one caller with a rule-compliant place to
+ * put it: the vault directory itself, already within `--seal`'s own
+ * carve-out under CONTRIBUTING.md's hard rule (residoo writes nothing
+ * outside `~/.residoo/rotations.json` and an explicit `--seal`). `residoo
+ * cred` stores a long-lived credential with no vault of its own, so there
+ * is no rule-compliant place to write a DPAPI blob for it -- it remains
+ * genuinely unsupported on Windows (isSupported() above, unchanged), not
+ * worked around by squeezing it through this pair too.
+ *
+ * Disclosed security-property difference, not glossed over: on macOS/
+ * Linux, the key lives in a genuinely separate OS-managed store, entirely
+ * absent from the vault directory -- copying just the vault gets an
+ * attacker nothing at all. On Windows, the wrapped blob travels WITH the
+ * vault directory (inside it), so copying the whole vault also copies the
+ * blob. DPAPI's CurrentUser-scope encryption still means that blob is
+ * only decryptable by the same Windows user account on the same Windows
+ * installation -- not portable, the same end-user guarantee --keychain
+ * already documents -- but a threat model where an attacker can read the
+ * vault directory's files without being able to run code as that same
+ * user gets less protection here than macOS/Linux's physically-separate
+ * store provides. Verified against Microsoft's own DPAPI documentation;
+ * not live-tested against a real Windows install.
+ */
+function wrapVaultKeyWindows(secret) {
+  if (process.platform !== "win32") throw new Error("wrapVaultKeyWindows is Windows-only.");
+  const escaped = String(secret).replace(/'/g, "''");
+  const script =
+    "$ErrorActionPreference='Stop'; " +
+    "Add-Type -AssemblyName System.Security; " +
+    `$bytes = [System.Text.Encoding]::UTF8.GetBytes('${escaped}'); ` +
+    "$enc = [Security.Cryptography.ProtectedData]::Protect($bytes, $null, [Security.Cryptography.DataProtectionScope]::CurrentUser); " +
+    "[Convert]::ToBase64String($enc)";
+  return cp.execFileSync("powershell.exe", ["-NoProfile", "-NonInteractive", "-Command", script], { encoding: "utf-8" }).trim();
+}
+
+/** The other half of wrapVaultKeyWindows -- see its docstring for the full design. */
+function unwrapVaultKeyWindows(blob) {
+  if (process.platform !== "win32") throw new Error("unwrapVaultKeyWindows is Windows-only.");
+  const escaped = String(blob).replace(/'/g, "''");
+  const script =
+    "$ErrorActionPreference='Stop'; " +
+    "Add-Type -AssemblyName System.Security; " +
+    `$enc = [Convert]::FromBase64String('${escaped}'); ` +
+    "$dec = [Security.Cryptography.ProtectedData]::Unprotect($enc, $null, [Security.Cryptography.DataProtectionScope]::CurrentUser); " +
+    "[System.Text.Encoding]::UTF8.GetString($dec)";
+  return cp.execFileSync("powershell.exe", ["-NoProfile", "-NonInteractive", "-Command", script], { encoding: "utf-8" }).trim();
+}
+
 /**
  * Store `secret` (a string) under `account` in the OS keychain, for later
  * retrieve(account). `keychainFile`, macOS only, is an escape hatch used
@@ -97,13 +201,13 @@ function store(account, secret, keychainFile, service = SERVICE) {
     const kf = keychainFile || testKeychainFile();
     const args = ["add-generic-password", "-a", account, "-s", service, "-w", secret, "-U"];
     if (kf) args.push(kf);
-    execFileSync("security", args, { stdio: "ignore" });
+    cp.execFileSync("security", args, { stdio: "ignore" });
     return;
   }
   if (process.platform === "linux") {
     // secret-tool reads the secret from stdin, never a CLI argument, so it
     // never appears in a process listing or shell history.
-    execFileSync("secret-tool", [
+    cp.execFileSync("secret-tool", [
       "store", "--label", "residoo sealed vault key", "service", service, "account", account,
     ], { input: secret, stdio: ["pipe", "ignore", "ignore"] });
     return;
@@ -120,10 +224,10 @@ function retrieve(account, keychainFile, service = SERVICE) {
     const kf = keychainFile || testKeychainFile();
     const args = ["find-generic-password", "-a", account, "-s", service, "-w"];
     if (kf) args.push(kf);
-    return execFileSync("security", args, { encoding: "utf8" }).trim();
+    return cp.execFileSync("security", args, { encoding: "utf8" }).trim();
   }
   if (process.platform === "linux") {
-    return execFileSync("secret-tool", [
+    return cp.execFileSync("secret-tool", [
       "lookup", "service", service, "account", account,
     ], { encoding: "utf8" }).trim();
   }
@@ -142,14 +246,17 @@ function remove(account, keychainFile, service = SERVICE) {
     const kf = keychainFile || testKeychainFile();
     const args = ["delete-generic-password", "-a", account, "-s", service];
     if (kf) args.push(kf);
-    execFileSync("security", args, { stdio: "ignore" });
+    cp.execFileSync("security", args, { stdio: "ignore" });
     return;
   }
   if (process.platform === "linux") {
-    execFileSync("secret-tool", ["clear", "service", service, "account", account], { stdio: "ignore" });
+    cp.execFileSync("secret-tool", ["clear", "service", service, "account", account], { stdio: "ignore" });
     return;
   }
   throw new Error(unsupportedReason());
 }
 
-module.exports = { isSupported, unsupportedReason, store, retrieve, remove, CRED_SERVICE };
+module.exports = {
+  isSupported, unsupportedReason, store, retrieve, remove, CRED_SERVICE,
+  isVaultKeySupported, wrapVaultKeyWindows, unwrapVaultKeyWindows,
+};

package/src/notify.js

@@ -8,13 +8,8 @@ const cp = require("child_process");
  * precedent `keychain.js`'s `security` and `ocr.js`'s `tesseract` already
  * set), Linux via `notify-send` (commonly present on a desktop session,
  * NOT guaranteed -- `watch` also runs on headless/server machines with no
- * notification daemon at all).
- *
- * Windows: no built-in, dependency-free mechanism was found that doesn't
- * either need an external module (BurntToast) or pop a blocking, modal
- * MessageBox in front of a background process -- a disclosed scope limit,
- * not silently assumed covered, the same posture `keychain.js` already
- * takes for its own Windows refusal.
+ * notification daemon at all), Windows via `System.Windows.Forms.NotifyIcon`'s
+ * balloon-tip API (see the Windows-specific docstring below).
  *
  * Decoration, never the report itself: `watch`'s own `emit()` already
  * writes every finding to stdout/stderr before this is ever called, so a
@@ -43,11 +38,63 @@ function notifyDesktop(title, message) {
       const child = cp.spawn("notify-send", [String(title), String(message)], { stdio: "ignore" });
       child.on("error", () => {});
       child.unref();
+    } else if (process.platform === "win32") {
+      notifyWindows(title, message);
     }
-    // Windows and anything else: no-op, disclosed above, not attempted.
+    // Anything else: no-op, not attempted.
   } catch {
     // Never let a notification failure affect the caller.
   }
 }
 
+/**
+ * Windows desktop notification via `System.Windows.Forms.NotifyIcon`'s
+ * balloon-tip API, shelled out to `powershell.exe` -- an earlier version
+ * of this module considered WinRT toast interop
+ * (`[Windows.UI.Notifications.ToastNotificationManager]`) instead and
+ * declined it after research found a real, disqualifying prerequisite:
+ * Microsoft's own docs make a Start-menu shortcut carrying a registered
+ * AppUserModelID a hard requirement for ANY desktop app's toast to
+ * display at all, explicitly including unpackaged/scripted apps. NotifyIcon
+ * has no such requirement -- confirmed against Microsoft's own current API
+ * reference (no [Obsolete] marker, listed through the windowsdesktop-10.0/
+ * 11.0 monikers) and multiple independently-converging technique
+ * write-ups, one of which states plainly it "requires no Start-menu
+ * shortcuts, AUMID registration, or external PowerShell modules." Not
+ * live-tested against a real Windows install, the same disclosed
+ * limitation `keychain.js`'s DPAPI functions and `integrity.js`'s Get-Acl
+ * check already carry.
+ *
+ * Two real caveats, disclosed rather than smoothed over: Windows ignores
+ * the millisecond value passed to `ShowBalloonTip` (actual on-screen
+ * duration is governed by the user's own accessibility settings, not this
+ * script), and the tray icon does NOT self-remove -- every reference
+ * implementation found demonstrates disposal via an interactive
+ * double-click handler, not an automatic one, which does not exist for a
+ * non-interactive script. This is why the script below explicitly
+ * `Start-Sleep`s before calling `.Dispose()` itself, inside the SAME
+ * spawned process: `notifyDesktop` never blocks its caller (the sleep
+ * happens in a detached, `unref()`'d child, exactly like the macOS/Linux
+ * branches above), but something has to keep the icon alive long enough
+ * to actually be seen before removing it, and nothing outside that one
+ * process is positioned to send a follow-up "now dispose" signal.
+ */
+function notifyWindows(title, message) {
+  const esc = (s) => String(s).replace(/'/g, "''");
+  const script =
+    "Add-Type -AssemblyName System.Windows.Forms; " +
+    "Add-Type -AssemblyName System.Drawing; " +
+    "$ni = New-Object System.Windows.Forms.NotifyIcon; " +
+    "$ni.Icon = [System.Drawing.SystemIcons]::Information; " +
+    `$ni.BalloonTipTitle = '${esc(title)}'; ` +
+    `$ni.BalloonTipText = '${esc(message)}'; ` +
+    "$ni.Visible = $true; " +
+    "$ni.ShowBalloonTip(10000); " +
+    "Start-Sleep -Seconds 10; " +
+    "$ni.Dispose()";
+  const child = cp.spawn("powershell.exe", ["-NoProfile", "-NonInteractive", "-WindowStyle", "Hidden", "-Command", script], { stdio: "ignore" });
+  child.on("error", () => {});
+  child.unref();
+}
+
 module.exports = { notifyDesktop };