[tractorjuice]

Fixes #737.

The bug

v6.8.0 exempted a value that is exactly read, write, none, true, false or null from the five reference-guarded key-value rules, so that id-token: write would stop being read as credential material:

const LEVEL = String.raw`(?!(?:read|write|none|true|false|null)\b\s*$)`;

All nine rules that interpolate LEVEL are built with the flags 'gi'. Without m, JavaScript's $ anchors to end of input, not end of line, so the exemption fired only when the permission line was the last content in the string:

allowed  id-token at END of input
BLOCKED  id-token MID-message   -> ["token: write"]

Why it matters more than the issue says

The same guard is duplicated in secret-file-scanner.mjs, the PreToolUse Edit|Write hook, where input is multi-line by definition. The OIDC case the v6.8.0 changelog entry was written for never worked there at all. On main today, a realistic release workflow is still blocked:

{"decision":"block","reason":"Warning: Potential secrets detected in file content: token (1x)
File: .github/workflows/release.yml ..."}

For secret-detection.mjs (UserPromptSubmit) the effect is the one reported: any prompt or subagent report quoting the line mid-paragraph is blocked, which halted a long /arckit:repo-audit run part-way through.

Trailing whitespace after the value was a second latent false positive from the same anchor.

The fix

End of line is spelled out rather than relying on $, which is one line per file instead of adding m to nine regex constructors:

const LEVEL = String.raw`(?!(?:read|write|none|true|false|null)\b[^\S\r\n]*(?:\r?\n|$))`;

case	want	before	after
OIDC mid-file	allow	BLOCK	allow
OIDC at EOF	allow	allow	allow
trailing spaces after value	allow	BLOCK	allow
literal credential mid-file	BLOCK	BLOCK	BLOCK
token: writeKeyABC123	BLOCK	BLOCK	BLOCK

Why CI did not catch it

All four capability vectors in tests/plugin/scanner-reference-guard.test.mjs were single-line strings with nothing after them, so $ coincided with end of line by accident.

This PR adds six regression tests covering the multi-line and trailing-whitespace cases against both hooks, plus two vectors asserting literal credentials are still caught when they are not the last line. Verified they fail on the old guard and pass on the new one:

6 fail / 49 pass   (guard reverted)
0 fail / 55 pass   (guard fixed)

The parity test now also compares the REF and LEVEL constants, not just the SECRET_PATTERNS block. The block interpolates both, so the copies could drift on the guards undetected, which is exactly where this bug lived.

Note for the reporter

@johnfelipe your trace was right on the mechanism. One correction: CLAUDE_CODE_OAUTH_TOKEN is not the trigger. The underscore is a word character, so \b(token|auth_?token|...) never matches inside ..._OAUTH_TOKEN. The trigger is id-token: write, where the hyphen supplies the boundary, which you identified in your second note.

Your workaround reasoning was also correct: the CLI loads hooks from ~/.claude/plugins/cache/, so patching a local checkout has no runtime effect and a cache patch is overwritten on the next plugin update. This release removes the need for either.

Verification

• node --test tests/plugin/*.test.mjs tests/plugin/test_*.mjs — 296 pass, 0 fail
• python -m pytest tests/codex -q — 35 pass
• python scripts/converter.py — exit 0, fix propagated to arckit-kimi (the only extension shipping these hooks verbatim); no hand-maintained Codex/Gemini hook carries a duplicate guard
• python scripts/sync-shared-assets.py --check — all 9 shared assets present in 14 community plugins
• npx markdownlint-cli2 CHANGELOG.md — 0 issues

🤖 Generated with Claude Code

https://claude.ai/code/session_01VKbHCujejpxkgvh47BndDE