fix(sanitize): don't reverse-flag path/URL env values as leaks (unblock main CI)

[autogame-17]

Problem

main CI (test.yml → npm test) has been red since at least v1.88.3 (2026-06-06) — always failing the same way:

not ok 130 - test/sanitize.test.js   (exitCode 1, location :1:1, no failing subtest)

It fails even on docs-only commits that never touched sanitize, and node --test test/sanitize.test.js passes locally. So the break is environmental, not a code regression. (macOS/Windows test-cross jobs pass — only the ubuntu test job is red.)

Root cause

sanitize.test.js asserts (top-level, not inside a test() block, so any throw exits the whole file):

fullLeakCheck('build trace from /home/runner/work/evolver/evolver/src/foo.js …').found === false

fullLeakCheck → detectEnvValueLeaks reverse-scans every process.env value and flags any (len ≥ 8) that appears verbatim in the content. The pattern scanner allowlists /home/runner/ paths, but the env-value reverse scan bypassed that allowlist.

In CI, several env vars equal the repo checkout path /home/runner/work/evolver/evolver — a substring of the fixture:

• the runner sets GITHUB_WORKSPACE, RUNNER_WORKSPACE
• because the suite runs via npm test, npm also sets INIT_CWD, npm_config_local_prefix, npm_package_json, PWD

Any one of them trips the reverse scan → found: true → assertion fails → top-level throw → file exits 1. Locally these are unset (or point elsewhere), so it passes.

Reproduce locally (note: must inject an npm-style var, since a bare node --test won't set INIT_CWD):

INIT_CWD=/home/runner/work/evolver/evolver node --test test/sanitize.test.js
# AssertionError at test/sanitize.test.js:280 — actual: true, expected: false

This is also a real product bug: in genuine CI use, any self-PR whose capsule content references the runner workspace path would be blocked by its own leak check.

Fix

Skip path/URL-shaped env values in detectEnvValueLeaks (one rule instead of chasing individual var names):

if (/^(\/|[A-Za-z]:\\|[a-z][a-z0-9+.-]*:\/\/)/i.test(val)) continue;

Filesystem paths and URLs are not secrets. Genuine sensitive paths in content are still caught by the local_path pattern scanner, and credentialed URLs by db_url / basic_auth. The reverse scan exists to catch non-pattern-matchable hardcoded secret values — which are never paths/URLs.

Regression test sets the runner/npm checkout-path vars (GITHUB_WORKSPACE, INIT_CWD, npm_config_local_prefix) and asserts fullLeakCheck stays clean, and asserts a non-path secret env value is still reverse-detected — so the security guarantee is locked in.

Verification

• full CI-env simulation (INIT_CWD=… GITHUB_WORKSPACE=… npm_config_local_prefix=… npm_package_json=… RUNNER_WORKSPACE=… node --test test/sanitize.test.js) → pass (70 assertions) (was failing)
• plain node --test test/sanitize.test.js → pass (70 assertions)

🤖 Generated with Claude Code

---

Note

Medium Risk
Narrows env-value reverse detection for all path/URL-shaped vars; non-secret strings could slip through if they aren't caught by pattern scanners, though tests assert real secrets still fail.

Overview
detectEnvValueLeaks no longer reverse-matches env values that look like filesystem paths or URLs (Unix /…, Windows C:\…, or scheme://…). That stops CI/npm checkout paths in vars like GITHUB_WORKSPACE, INIT_CWD, and npm_config_local_prefix from being treated as hardcoded secrets when capsule text mentions the same path—fixing CI-only failures in test/sanitize.test.js and avoiding self-PR blocks on legitimate build traces.

test/sanitize.test.js adds a regression block that sets those env vars to a runner-style path, asserts fullLeakCheck stays clean on path-containing content, and asserts a non-path secret env value is still detected (70 assertions total).

^{Reviewed by Cursor Bugbot for commit 6e5bc12. Bugbot is set up for automated code reviews on this repo. Configure here.}