Stop secret-shape detection from swallowing file paths

[steflsd]

@coderabbitai ignore

The secret-json-value pattern matches KEY\n VALUE with no separator required between key and value. So any line ending in a token containing a secret-ish word (token, secret, auth, password) — as long as the word isn't at position 0 — caused the entire next whitespace-delimited token to be registered as a secret.

In practice that ate file paths out of tool output.

Impact

Any git diff --name-only, ls, find, or grep listing in a repo containing an *Auth*/*Token*-named file lost paths. Measured across 10 repos: 27 of 4,265 tracked paths (~0.6%).

Two properties made it hard to spot:

• Silent. The path is replaced by a FICTA_<hex> surrogate, not dropped, so a listing looks well-formed.
• Position-dependent. It depends on the preceding line, so the same path survives one listing and vanishes from the next. Once registered, it stays redacted for the proxy's lifetime.

Fires	Doesn't fire
convex/lib/rotateToken → next path	packages/token (word at position 0)
apps/web/hooks/useAuth.ts → next path	packages/authStore (same reason)
comment ending (registered-secret → path:12:	bare auth
prose ending oauth → next path	paths with no secret-ish line above

No leak, and no request failure — restore-into-tools puts the real path back into later tool args. The cost is that an agent sees an opaque token where a path should be and reasons about it. This was found because a session flagged one as evidence that "something is injecting into git config" and spent a turn on a phantom bug.

Fix

Reject values shaped like multi-segment filesystem paths, tolerating a trailing grep/ripgrep locator (src/defaults.ts:12:9). Ordered after the credential-URL and known-shape checks so those still win.

A segment that looks like credential material — ≥20 chars, no ./-/_, mixing letter cases with digits — disqualifies the whole value, so a slash-containing secret isn't mistaken for a path.

Length alone does not work as the discriminator. A 32-char segment cap still ate src/routes/api/v1/$.ts and a 33-char filename; widening to 64 then dropped a genuine credential (Xk9s…uI4o/S, 40-char segment). Requiring an unbroken mixed-case-plus-digit run keeps content-hashed assets like app.4f3a2b1c9d8e.js on the path side, since they carry separators.

Relationship to #83

This is the text-surface sibling of the JSON-key corruption fixed there. That fix separates leaves in the \n-joined detection text; this one fires on genuine multi-line string leaves, so it survived. Verified present in published 0.2.1 by running the repro against the installed tarball — which is what shimmed sessions actually execute.

Verification

• 27 → 0 false positives across the same 4,265 files.
• Regression tests: five listing shapes must register zero values (incl. a path:line: locator and src/routes/api/v1/$.ts), plus a true-positive guard that base64 and slash-containing credentials still pair with a bare API_TOKEN key — that second test is what caught the 64-char-cap mistake.
• pnpm check (biome + engine-boundary + typecheck + tests): 51 files, 562 tests, all pass.

🤖 Generated with Claude Code