The Codex half of #1891's acceptance condition is not covered by this PR. Since the Fixes #1891 trailer closes that issue on merge, the uncovered lane has been split out to #1898 so it survives the close, with the evidence, both blockers (LLP 0419 #scope) and the hook-trust hazard carried over.

This PR's scope is unchanged by that: the Claude lane, the SessionIgnoreSet store change and the docs are what is being proposed here.

Verdict: approve with fixes landed. Full PR review of 3dec9434 against base master, comparison base eee50a73a4129f80acbb30b857f9a771de91af0f (merge base). 9 findings: 5 fixed and pushed, 4 deferred. New head dd047dd5a5d5974f010e577da269850cceb9b89d.

The mechanism is sound and the fail-closed direction is right throughout. Nothing found could cause the defect this PR closes (an opted-out conversation recorded under a fork's id). Two of the fixes close paths that could have destroyed capture for a session nobody opted out of, which review priority 1 names as worse than the bug.

Baseline confirmed at the merge base myself: hyparquet-floor-pin 3 failures and src/core/otlp/server.js(85,51) typecheck error are pre-existing and unchanged. At the new head: 6925 tests, same 3 failures, same 1 typecheck error, +1 test.

1. A fingerprint could be written with no marker beside it, looping the guard forever - high, fixed

session_command.js:445 wrote a fingerprint on any confirmed 200. But the Cursor listener answers this route over a plain Set (cursor/src/index.js:36 -> cursor/src/listener.js:157, advertised at :330), as does OpenCode, so ignored: true can come back with no marker on disk. Then in hook_command.js:254 hasSessionIgnoreMarker is false, :255 a fingerprint exists, :257 it matches (a fingerprint matches its own session), :259 spawns node bin/hypaware.js session ignore - and the next UserPromptSubmit does it again, one 20s-budget subprocess per prompt, indefinitely. The orphan is also unremovable: unignore against a plain-Set recorder deletes nothing from disk.

Fixed: the marker, not the reply, arms the fingerprint (session_command.js:564). fork_protection: armed now means a durable exclusion exists. New test a recorder that persists nothing arms nothing, and the receipt says so (claude-fork-guard.test.js:200) drives the plain-Set shape.

2. FINGERPRINT_TOKEN did not enforce the property any-match rests on - medium, fixed

session_ignore_store.js:46 was /^[A-Za-z0-9._:-]{8,128}$/, while LLP 0419 #any-match justifies the whole rule with "transcript uuids are random v4, so one shared value is not a coincidence". Nothing checked that, on the write side or the match side. A single non-random uuid value from a future client build (msg_..., a constant, a short token) would match every stored fingerprint at once and silently ignore every session on the machine.

Not reachable today: 20 real transcripts sampled, every head line type either carries a distinct v4 uuid or no uuid at all (queue-operation, mode, permission-mode, file-history-snapshot, last-prompt carry none and are correctly skipped), 0 collisions across files. But the code accepted far more than the argument allows. Fixed to a canonical uuid, any version digit, so a move to v7 keeps protection (session_ignore_store.js:53).

3. One unreadable fingerprint aborted the whole match walk - medium, fixed

sessionForkFingerprintMatches's readFileSync was unguarded while the lstatSync two lines above was not. An EACCES/ENOENT from a concurrent unignore propagated to walkExclusionDir's catch { return undefined } and reported "no match" for every fingerprint after that entry. Fail-open is the right direction, but the blast radius should be one file. Fixed at session_ignore_store.js:342.

4. The spawned opt-out passed the id positionally - low, fixed

hook_command.js:311 was ['session', 'ignore', sessionId, '--json']; parseArgv refuses an argument starting with -, so a client-supplied id opening with a dash would fail the spawn on every prompt for the life of the session. Fixed to ['session', 'ignore', '--json', '--', sessionId] (:315) - the verb already supports --.

5. LLP 0419 #verification named the wrong acceptance gate - low, fixed

It pointed at claude_otel_shape_check as the release gate for fork drift while this same PR adds claude_fork_session_optout for exactly that. Both are now named (0419:194).

6. Unignoring one member of a fork family does not release it - high, deferred, needs a decision

Each auto-ignored fork gets a fingerprint of its own on the way through (LLP 0419 states this), and every fingerprint in a chain holds the same leading uuids. delete removes only the pair for the id it is given, so:

• hyp session unignore $B in the fork -> B's marker goes, but B's head still matches A's fingerprint -> the guard re-adds B on its next prompt.
• hyp session unignore $A in the parent -> A's head still matches B's fingerprint -> A is silently re-ignored.

Both print a success receipt saying the id is out of the drop set. The hook's stderr notice is invisible in practice (the hook exits 0, so Claude does not surface it). Verified empirically against the real modules. The existing test misses it because it unignores A before any fork was auto-ignored, so only one fingerprint ever exists.

Deferred rather than fixed because every candidate fix trades one silent wrong for another: removing matching siblings' fingerprints would lose fork protection for a parent that is still ignored, and suppressing the fork's own fingerprint fixes only one of the two directions. What unignore means for a conversation filed under several ids is a question LLP 0403 did not settle either. The residue is over-exclusion, never a recorded conversation the user opted out of, so it does not block this change.

Landed instead: LLP 0419 #scope records the limit verbatim (0419:163), and docs/ACCEPTANCE.md step 12 is corrected - as written it told a human to unignore only $A and expect a fresh fork to be recorded, which would have failed the run and been read as a regression.

7. A fork taken with no live recorder is not covered, and says so invisibly - medium, deferred

ignoreSessionViaCli runs the real verb, which returns SESSION_EXIT_UNKNOWN when no recorder advertises the route (session_command.js:396). Fork while the daemon is down and no marker is written; the warning goes to stderr on an exit-0 hook, so nobody sees it, and a later transcript backfill imports the fork in full. Inherited from hyp session ignore itself (a hand-typed opt-out with the daemon down behaves the same way), so not a regression, and fixing it means changing what the verb guarantees. The code comment's "loudly enough to find" overstates what a user actually sees.

8. Raising FORK_FINGERPRINT_UUIDS later would brick capture on a rollback - medium, deferred

parseFingerprint treats length > FORK_FINGERPRINT_UUIDS as damage, and load() turns damage into LOAD_ERROR, which disables capture everywhere. A well-formed-but-longer list is version skew, not damage. Speculative until someone changes the constant, and that release would be a durable-store change gated accordingly. Same class: an older build meeting any .fingerprint.json at all refuses the store, so a downgrade across this release needs the directory cleared.

9. Reuse and duplication - low, deferred

transcript_fingerprint.js:26,47 re-declare the 512 KiB context tail and re-derive the plugins/@hypaware/claude/session-context.jsonl path, both of which exist in the plugin as SESSION_CONTEXT_READ_TAIL_BYTES / defaultSessionContextFile. The file's own header explains why it cannot import the plugin, so the copies are deliberate, but they can drift with nothing to catch it. Related: the hook appends to the --state-file baked into settings.json at attach time while the verb recomputes the root from the current env, so a moved HYP_HOME yields unconfirmed while looking healthy.

Verified clean

• False positives. Any-match is safe given uuid randomness, which finding 2 now enforces. The un-ignored-fork test is not vacuous: it runs the full path (fingerprint present, guard live, transcript read, matcher consulted) and stops only at the match. Subagent transcripts go to subagents/agent-*.jsonl, never named in transcript_path, and subagents emit neither hook event. Across the real session-context channel: 0 transcripts shared by more than one session id, 0 sessions with more than one transcript path.
• False negatives. The UserPromptSubmit backstop is genuine and covers a copy landing after SessionStart; the guard is idempotent and short-circuits on one stat once ignored (asserted by harness.calls being empty on the repeat). Empty, truncated, and >64 KiB-head transcripts all yield zero uuids, which never matches and is reported as UNCONFIRMED rather than silently assumed armed.
• Privacy of the mechanism. A fingerprint is uuids only; nothing logs, stores, or emits transcript content, paths, or prompts. The filename is the sha256 of the id. No transcript path on record -> marker written as today, receipt says UNCONFIRMED in prose and as fork_protection in --json.
• Store. Unknown filenames are still corruption (session_ignore_store.js:100), and the tmp-file regex genuinely matches what atomicWriteFileSync produces for both names (executed against real tmpPathFor output), so a crash mid-write cannot brick the store. Ceiling accounting is real and conservative in the safe direction; delete clamps at 0 for the cross-process case.
• The rewritten test asserts the new truth, not a weaker one: it pins the UNCONFIRMED branch positively and adds assert.doesNotMatch on the removed blanket claim. The armed branch is asserted separately in claude-fork-guard.test.js.
• LLP discipline. git diff origin/master...HEAD -- llp/0403*.md | grep -c '^-[^-]' = 0; 0403 gained only the Extended-by: header and an italic forward-ref. All four new @refs resolve to real 0419 anchors. node scripts/llp-numbers.js check: 1 number minted, no collision.
• Acceptance procedure. Runnable as written, and it names the two upstream facts no fixture can settle (copied lines keeping uuid, the hook still seeing source: "fork") plus the silent failure mode. Step 11 is the false-positive direction; step 12 corrected per finding 6.
• Codex lane. Deliberately absent and honestly recorded in the PR body, LLP 0419 #scope, docs/PRIVACY.md, and all four skill copies. Nothing half-built left in the codex plugin: the only change there is a comment correction.
• Style / deps. No semicolons in code, no em dashes anywhere including LLP and docs prose, no NUL bytes, JSDoc only, no @typedef, no inline import('...') types, no new runtime dependencies, no invented config keys.

CPU and memory pass

Live capture is untouched: the drop stays an O(1) Set lookup over id markers and a fingerprint never enters that set. Store loads are per refresh, not per message. The hook's ordinary path is one stat plus a readdir that stops at its first entry, both far below the two git subprocesses the same hook already spawns per event. walkExclusionDir streams rather than materialising a listing, and every file handle closes in a finally.

Two costs worth naming, neither a blocker:

• Once any fingerprint exists, every UserPromptSubmit of every Claude session - not just forks - pays a 64 KiB head read plus a split('\n') over the whole buffer (transcript_fingerprint.js:114), materialising every line before the loop breaks at 8 uuids, plus a walk that reads every stored fingerprint. LLP 0419 acknowledges the walk and bounds it by the store's 10,000-id ceiling; it does not acknowledge that the read and split happen for non-forks too. An incremental indexOf('\n') scan would remove the split allocation for nothing. Deferred.
• writeSessionForkFingerprint lstats every entry per opt-out. Person-initiated, and the walk is what buys the difference between "this fork is not covered" and the ceiling overshoot that would refuse the whole store.

No unbounded growth, busy loop, or retained allocation. Finding 1's per-prompt subprocess loop was the one genuine unbounded-work path and it is fixed.

Fixed and pushed as dd047dd5, verified in the committed tree against 3dec9434: session_command.js:564 (marker guard) and :17 (import), session_ignore_store.js:53 (uuid token) and :342 (guarded read), hook_command.js:315 (--), 0419:78,163,194, ACCEPTANCE.md:2191, claude-fork-guard.test.js:200, session-ignore-fork-fingerprint.test.js.

Neutral is stuck on this PR

What it was doing: the review rung on PR #1897 (fix/issue-1891, the fork opt-out). The first full review ran at head 3dec9434; its record is here. Five findings were fixed and pushed (head is now dd047dd5), three were deferred, and one is a blocker neutral must not decide on its own.

Why it cannot proceed: hyp session unignore <id> does not actually release a session that belongs to a fork family.

Once a conversation is ignored and then forked, several session ids share one set of fork fingerprints. Unignoring a single id removes that id's marker, but the siblings' fingerprints still match, so the guard silently re-adds the id on the next prompt. The receipt tells the user the session is out while the mechanism puts it straight back in.

That direction matters more than it looks: this whole PR exists so that an opt-out cannot be defeated by a fork. The mirror image is a user who explicitly asks to resume recording and is quietly overruled, with no error and no visible trace. Finding 1 of the same review (fixed here) was the related unbounded case: a fingerprint written with no marker was unremovable by any shipped verb and re-spawned the opt-out every prompt forever.

What it needs from you - a design call:

When a conversation is ignored and then forked, so several session ids share one fork fingerprint set, what should hyp session unignore <one id> do?

(a) Release only that id. Simple and literal, but today that means the guard silently re-adds it, so the command does not do what its receipt says.

(b) Release the whole fork family by clearing every matching fingerprint. The command then means what it says, but a parent that is still ignored loses its fork protection as a side effect of unignoring a child.

(c) Refuse, and tell the user which sibling ids must be unignored first. Honest and lossless, but it makes unignore fail on a case the user did not create deliberately.

Neutral has no authority to choose between weakening an opt-out guarantee and weakening an explicit un-ignore, so it is holding the PR here rather than guessing.

How to unstick: reply with a comment on this PR (or push to the branch). Neutral monitors this thread and will re-engage with your guidance on its next tick.

_{The three deferred findings (fork with no live recorder, a speculative rollback hazard if FORK_FINGERPRINT_UUIDS is ever raised, and some duplicated constants) are recorded in the review comment and are not blocking. The Codex lane of the original issue is tracked separately in #1898.}