fix(redact): relocate ^-anchored spans so egress masking stops dropping whole files (#2912)

[aclansley]

What

locateSpan() cannot relocate an ^-anchored pattern, so redactFindingSpans() returns null and its caller drops the whole payload. This is the mechanism behind #2912.

Why it happens

A finding's col points at the reported span — the capture group when the pattern has one — which sits after the start of the whole match. locateSpan resumed the scan two characters before that span:

re.lastIndex = Math.max(0, offset - 2);
const m = re.exec(input);

env.kv is ^-anchored:

regex: /^[ \t]*(?:export[ \t]+)?[A-Z][A-Z0-9_]*(?:KEY|TOKEN|SECRET|...)[ \t]*=[ \t]*['"]?([^\s'"]{8,})['"]?/

The only position its ^ can match is the line start, and that is already behind lastIndex. exec scans forward, never matches the line the finding came from, and locateSpan returns -1. redactFindingSpans then returns null — which, per its own contract, the caller must read as "drop the whole payload".

The scope is wider than #2912 reports

#2912 frames this as a false positive on lines that read a key from the environment. The trigger is actually any env.kv match at all, so a file is dropped just as readily when the match is a genuine secret:

redactFindingSpans('DB_PASSWORD = "s3cr3t-Kx9mQ2vLp7Wn"', { repoVisibility: "private" })
// → null   (before this change)

That is the fourth case in the added test file. The practical effect is that the files most likely to contain credentials are the ones most likely to be withheld.

The fix

Resume the scan at the line start so an anchored match is reachable, then walk matches and accept only the one whose span lands exactly at the reported offset.

Fail-closed behaviour is unchanged: when no match lands at that offset, locateSpan still returns -1 and the payload is still dropped. The change makes a correct relocation possible; it does not make masking more permissive.

Verification

	test/locate-span-anchored.test.ts (new)	test/redact-engine.test.ts
before	0 pass / 5 fail	98 pass / 0 fail
after	5 pass / 0 fail	98 pass / 0 fail

Verified against main at v1.87.5.0.

test/gstack-redact-cli.test.ts, test/telemetry.test.ts and test/redact-audit-log.test.ts report an identical 124 pass / 37 fail both with and without this change — those 37 are pre-existing failures in my sandbox (they shell out through execSync) and are unrelated to it.

Deliberately not addressed

The other half of #2912 — env.kv firing on os.environ[ in the first place — is left alone. Tightening that validator trades against false negatives on real secrets, which felt like a maintainer's call rather than mine. This change stops the file loss either way, and the two are independent.

🤖 Generated with Claude Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[capy-ai]

Thank you @aclansley for isolating the anchored-match relocation failure and proposing the exact-position check. Your diagnosis and anchored-span approach are explicitly credited in the maintainer integration, #2942, merged as b9706f3 for v1.88.1.0.

The shipped implementation binds masking to the original spans captured during scanning, rather than searching the raw text again. It also preserves normalization offsets, overlapping matches, and fail-closed behavior. See lib/redact-engine.ts, the span-binding regressions, and the Unicode-offset regressions.

Closing this PR as superseded by that integration, not as a merge or wholesale adoption of this branch. As you correctly separated in your proposal, detector false positives are a different problem; #2912 remains open for that and its outstanding size-limit concerns. Thanks for keeping the original fix focused and fail-closed.