Best possible solution:

Port the expected-session compare-and-clear invariant onto current main's storage-neutral session accessor and canonical direct/queued CLI dispatch paths, then prove durable cleanup and successful continuation with a real expired-session failover while also proving that concurrent replacement and deletion remain untouched.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: current main retries an expired CLI session fresh without clearing the persisted binding, so the next turn can select the same stale ID again. A real current-main gateway reproduction was not supplied in the PR evidence.

Is this the best way to solve the issue?

Yes in principle: an atomic expected-session compare-and-clear before authorizing the fresh retry is the narrowest concurrency-safe fix. The submitted branch still needs to be ported to current main's storage accessor and execution topology before that judgment applies to the merge result.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 4b6575636fd4.

Label changes:

• add P1: A persisted stale CLI binding can make every later turn in an affected conversation fail until users manually edit session state or reset the conversation.
• add merge-risk: 🚨 session-state: The PR mutates persisted CLI session ownership during retry, and an incorrect port could clear a newer binding or leave memory and durable state inconsistent.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR reports unit suites and static checks but no redacted after-fix gateway plus CLI-backend failover run showing the persisted stale binding removed and the conversation recovering; after adding proof, update the PR body to trigger review or ask a maintainer for @clawsweeper re-review.

Label justifications:

• P1: A persisted stale CLI binding can make every later turn in an affected conversation fail until users manually edit session state or reset the conversation.
• merge-risk: 🚨 session-state: The PR mutates persisted CLI session ownership during retry, and an incorrect port could clear a newer binding or leave memory and durable state inconsistent.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR reports unit suites and static checks but no redacted after-fix gateway plus CLI-backend failover run showing the persisted stale binding removed and the conversation recovering; after adding proof, update the PR body to trigger review or ask a maintainer for @clawsweeper re-review.

PR surface:

Source +50, Tests +224. Total +274 across 6 files.

What I checked:

• Current-main source reproduction: The current CLI runner retries a session-expired failure without the stale session ID, but its own comment states that the caller still needs to clear persisted session state; this leaves the linked issue's repeated-turn failure mechanism present on current main. (src/agents/cli-runner.ts:25, 4b6575636fd4)
• Storage boundary changed after the PR base: Current main defines session-accessor.ts as the permanent storage-neutral boundary backed by SQLite and provides atomic patch/update APIs; the PR was authored against the older session-store topology and must be reviewed after rebasing onto this contract. (src/config/sessions/session-accessor.ts:1, 4b6575636fd4)
• Queued execution topology changed: Current main's follow-up runner is substantially refactored and currently invokes the embedded agent path directly rather than containing the CLI dispatch block modified by this branch, so the queued-path patch and tests do not establish behavior against the present topology. (src/auto-reply/reply/followup-runner.ts:1, 4b6575636fd4)
• Proposed implementation: The branch adds an expected-session compare-and-clear helper and wires it into direct and queued CLI fresh-retry callbacks, protecting newer replacement bindings and deleted-session lifecycle state. (src/auto-reply/reply/agent-runner-cli-dispatch.ts:298, c5ee5d025504)
• Regression coverage: The branch adds focused tests for stale-state removal, a newer persisted binding, missing-row isolation, direct recovery, and queued follow-up recovery. (src/auto-reply/reply/agent-runner-cli-dispatch.test.ts:570, c5ee5d025504)
• Real behavior proof gap: The PR body reports focused unit suites, lint, formatting, and static checks, but does not show an after-fix gateway/CLI run where an expired persisted binding is cleared and the same conversation successfully continues with a fresh CLI session. (c5ee5d025504)

Likely related people:

• vincentkoc: Repository ownership documentation identifies this person with the Agents area, and current session-accessor architecture and adjacent agent-runtime history make them the strongest routing candidate for the storage-neutral compare-and-clear boundary. (role: agent and session-state owner; confidence: high; commits: 4b6575636fd4; files: src/config/sessions/session-accessor.ts, src/auto-reply/reply/agent-runner-execution.ts)
• steipete: Recent merged history includes CLI turn runtime work and broad maintenance of the agent execution surface, making this person relevant to the fresh-session retry contract and current-main integration. (role: recent CLI runtime contributor; confidence: medium; commits: 5518ac9; files: src/agents/cli-runner.ts, src/auto-reply/reply/agent-runner-execution.ts)
• RajvardhanPatil07: Recent merged history credits CLI turn output work in the same runtime area, providing an additional routing candidate for CLI execution behavior. (role: recent CLI runtime contributor; confidence: medium; commits: 5518ac9; files: src/agents/cli-runner.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.