A resumed Claude seat whose session id changes can no longer be proved, so it reads attention_required

[haralez]

What I'm trying to do, and what stops me

After rig up <rig> --existing restores a Claude Code seat with --resume <id>, Claude Code sometimes continues the conversation under a new session id. OpenRig's SessionStart hook then records the new id, and from that point the seat can never pass the strict identity proof:

• selectNativeProcess (native-process-lineage.ts) requires the --resume token in the process argv to equal the stored token. Argv still says the old id; the stored token is the new one.
• So restore's finish step and rig seat clear-attention can't verify the seat, and it stays attention_required for the life of that process. Every rig send to it warns: "Claude launch identity differs from the stored conversation; current conversation is unverified".

The seat is healthy, and nothing an operator can do short of restarting it clears the state. set-resume-token back to the argv id would be wrong, because the new id is the conversation that is actually being written.

Evidence (OpenRig 0.6.6 and 0.6.7, Linux, Claude Code 2.1.x)

One of eleven Claude seats on one host after a reboot restore:

1. Restore launched the seat with claude --resume T1.
2. Claude Code continued that conversation as T2: the T2.jsonl transcript is the one being appended, and T1.jsonl stopped at the restore time.
3. The session row's token went from T1 (provenance scrape/operator) to T2 (provenance hook).
4. Since then, rig ps shows the seat attention_required, clear-attention can't prove it, and every send to it carries the warning above.

The other ten seats kept their id on resume and prove fine. Any resumed seat whose id rotates will hit this.

Why this is not just "trust the hook"

The refusal is deliberate, and the comment in observeClaudeDelivery gives the reason:

argv records launch identity, not the current conversation: /clear can rotate the hook-persisted token without replacing this process. A sole launch-token mismatch cannot distinguish that from stale resume metadata.

That's right as far as it goes. Today the daemon can't tell these two cases apart:

	argv token	stored token	what happened
A	T1	T2	the seat resumed T1 and Claude Code continued as T2 (this report)
B	T1	T2	the user ran /clear in the same process, starting a new conversation T2
C	T1	T2	the stored token is stale or wrong metadata

The missing fact: Claude already says which case it is

Claude Code's SessionStart hook input carries source: startup, resume, clear or compact. OpenRig's relay (activity-relay.cjs, buildSessionIdentityPayload) runs on every SessionStart (no matcher) but forwards only session_id, so the daemon receives A and B as the same event.

Proposed rule

Accept a stored Claude token T2 that differs from the argv token T1 only when all of these hold. Otherwise keep today's behaviour (unknown).

1. The launch is ours. T1 is the token OpenRig itself launched this occupant with: the restore or launch recorded it on this session row (or its launch receipt) for the same seat and launch generation.
2. The rotation came from the resume. T2 was recorded by the hook with source: "resume" (newly relayed), for this same session row, after that launch and before any other SessionStart for it. A source: "clear" or "startup" record never qualifies.
3. Same process. The single verified Claude process, its foreground chain and its fingerprint are the ones the launch produced, unchanged since (the existing lineage checks).
4. One hop. Only T1 → T2 once per launch. A later clear makes the seat unverified again, which is today's behaviour.

Why it stays safe

• Case B (/clear) reports source: "clear", so rule 2 refuses it. The current refusal is kept exactly where it matters.
• Case C (stale metadata) has no source: "resume" hook record tied to this launch, so rules 1 and 2 refuse it.
• A forged or replayed hook post has to come through the authenticated relay for this session row and this launch generation. That is the same trust the hook path already has when it writes tokens today. The rule adds no new writer; it only lets one already-recorded write count, under a narrower condition.
• Everything else is unchanged: process lineage, the foreground process group, the frozen launch executable, and Codex, Pi and OMP seats.

Cost to everyone else

• The relay adds one field (source) to the session-identity post, and the daemon stores it with the token's provenance.
• The proof gains one guarded branch for Claude only.
• No new setting, no new prompt, no change for seats whose id doesn't rotate.

Open questions for maintainers

• Is source stable enough across Claude Code versions to rely on? If it is absent, the rule simply doesn't apply (fail closed).
• Should the accepted T2 also become the argv-equivalent for later restores, or stay "hook-accepted for this launch" only?
• Would you rather fix this in the restore path (re-read the hook record right after resume) than in the general proof?

I'm happy to send a PR for whichever shape you prefer.

[lab1207]

I verified the load-bearing claim in source, and the rule holds up. Do this:

Confirm the gap first (activity-relay.cjs:143): buildSessionIdentityPayload reads session_id but never reads source — resume/clear/startup/compact all arrive as the identical event. Your A-vs-B-vs-C indistinguishability is real, not hypothesized.

Take the general-proof branch, not the restore-path re-read. Your four guards (own launch, resume-sourced, same process, one hop) map onto machinery that already exists: the occupant-tenure generation ledger already distinguishes 'same launch' from 'new tenure', so the T2-acceptance can ride the same comparison instead of adding restore-path special-casing that every future rotation path would need to duplicate.

On your open questions: source-absent must fail closed (your rule already does — old Claude versions just keep today's behavior); T2 should stay 'hook-accepted for this launch' rather than becoming argv-equivalent, because a later restore replays argv and would then bless the rotated id without a fresh hook.

One test to demand of whichever PR implements it: the B-case (same process, /clear, source clear) must still refuse — that's the case the current refusal exists for, and it's the one most likely to regress. Confirm the above by reading buildSessionIdentityPayload yourself; it's 25 lines.

[mvschwarz]

Thanks, @haralez, for a precise report from a real host: one of eleven Claude seats was restored with --resume T1, carried on as T2, and has read attention_required since, with a warning on every send, while the other ten proved fine. Your table of the three cases makes clear both why today's refusal exists and what it can't tell apart. Thanks also, @lab1207, for checking the source. Your reading is that buildSessionIdentityPayload in activity-relay.cjs forwards session_id but not SessionStart's source. We haven't checked that reading ourselves or reproduced the report.

You offered a PR, and a focused one with regression tests would be welcome. On your three questions, we'd rather the PR take a position on each, with its reasons, than settle them in this thread; the review will decide. The tests should keep today's distinctions between resume, clear, startup and compact. In particular, a /clear in the same process, the case the current refusal exists for, must still be refused. We'll review it once it's open.

[haralez]

PR: #1080. It follows the rule proposed here, takes a position with reasons on each of the three open questions (rely on source and fail closed; nothing becomes argv-equivalent for later restores; general proof, keyed to evidence recorded when the hook is written), and has regression tests that keep resume distinct from clear, startup and compact. A /clear in the same process stays refused.

[mvschwarz]

An update: #1080 is merged to main, so a resumed Claude seat whose session id changed can be proved again. It will ship in the next release. Thanks again, @haralez, and thanks to @lab1207 for checking the source.

[mvschwarz]

An update: OpenRig 0.6.10 is out on npm (release notes: https://github.com/mvschwarz/openrig/releases/tag/v0.6.10), with #1080. A resumed Claude seat whose session id changed is now verified and restored as resumed, and sends to it no longer warn that its identity can't be confirmed. The release's known issues list the cases it still doesn't cover, such as after /clear or with an openrig-core plugin older than 0.1.9 (0.6.10 bundles 0.1.9). To upgrade, run npm install -g @openrig/cli, then restart the daemon with rig daemon stop and rig daemon start. Thanks again, @haralez, and thanks to @lab1207 for checking the source.