Repository navigation
fix(identity): pin list-to-send targets to a session generation and fail closed when stale #180
Description
Reddit feedback
A reader asked whether a session that exits or restarts between list and send can cause delivery to a successor, and requested a typed stale-target result. A second reader suggested binding the message to a target session ID. Source: https://www.reddit.com/r/ClaudeCode/comments/1wotkse/i_built_sessionpeer_to_hand_off_messages_between/
Current v1.0.0 boundary
Codex send checks the live writer PID, start time, and lock immediately before queueing, but a prior list result is not generation-pinned to a later send. Claude names are resolved again at send time; a successor may reuse a name. A stale PID is rejected when no longer live, but PID reuse is not a universal generation guarantee. Antigravity and paired-device generation contracts are separate and must not be generalized to ordinary local/SSH send.
Proposed work
- Define a portable, opaque target-generation token or equivalent precondition returned by discovery and accepted by send/dry-run, including SSH.
- If the observed target changed or disappeared, return a structured
stale_targetrefusal with safe last-seen metadata; never silently retarget and never submit or wake. - Keep unpinned legacy addressing clearly documented as weaker; decide compatibility and JSON schema explicitly.
- Test name reuse, PID reuse, Codex writer restart, list/send race, remote race, and no duplicate native submission.
Related, not duplicate: #173 is Windows discovery of exited Claude records; #166 concerns unsaved Codex threads.
Current follow-up scope after v1.1.0 — 2026-10-09
The original proposal above is retained as historical context. User-authorized release accounting keeps this issue OPEN and moves the remaining acceptance work from v1.1.0 to v1.2.0.
Shipped in v1.1.0
Claude inbox generation discovery and pre-effect revalidation (--with-target-generation, --target-generation) are shipped. Stale/unsupported targets refuse without queueing or wake.
Merged implementation: #286. Published release, exact source 8ca77cf31254c8287a2593fe484bb30a7dba2727; integrated main CI and PyPI publication/verification succeeded. Publication does not establish operational rollout or new live-agent acceptance.
Remaining acceptance — not completed by the release
- Establish a supported, atomic original-generation precondition for native Codex rather than treating a writer recheck or queue ID as an incarnation guarantee.
- Define and validate Antigravity and paired-device generation contracts separately; do not silently generalize Claude tokens.
- Verify the relevant restart/name/PID/remote races on the supported native platforms before advertising broader support. Preserve no retarget, no fallback and no uncertain resend.
This is backlog/state accounting only. No new runtime implementation, skill merge/release, operational change, native experiment or publication is authorized by this reassignment.
Activity
abruption commentedon Oct 13, 2026
v1.2.0 release target and work order — 2026-10-13
The owner requested a release due this week. Milestone v1.2.0 now has due date 2026-10-18. GitHub stores the milestone as a calendar date; the planning target is the end of Sunday in KST, not automatic publication or a waiver of acceptance gates.
Execution order:
Development and PR preparation have started in isolated worktrees. Existing worktrees, raw evidence and unrelated PRs are preserved. No live send, settings change, service deployment, automatic merge, tag or publication is authorized by this scheduling record. Codex repository reviews are triggered automatically; no reviewer mention is needed.
If a gate requires unsupported upstream behavior or cannot be validated by the deadline, report the exact gap and ask the owner to choose scope or schedule. Do not silently move issues, weaken guards, manufacture receipts, generalize experimental acceptance or claim the full milestone completed.
abruption commentedon Oct 14, 2026
Owner-authorized work allocation (2026-10-15; correlation PY120-ISSUE-DELEGATION-20261015): request submitted to the session-peer-claude implementation session; consumption/acceptance is not yet confirmed.
Second, after #268: investigate the native original-generation atomic precondition and implement only proven safe paths. Missing native authority stays unsupported; writer rechecks, queue IDs and direct-input capability do not establish an incarnation guarantee.
Use a separate isolated worktree based on current origin/main and report frozen commits with tests and remaining acceptance gates. Shared files are edited sequentially. The coordinating Codex session will run independent-cli-review with separate non-interactive Claude Opus 5.5 and Codex CLI reviewers, address findings, and then create the PR. No implementation PR has been created yet. No merge, release, operations change or expanded live test is authorized by this allocation. Target milestone date remains 2026-10-18; unproven safety requirements will not be weakened to meet it.
abruption commentedon Oct 30, 2026
Milestone housekeeping — 2026-10-30: moved remaining acceptance from the already published v1.2.0 milestone to Long-term, following the owner's research/backlog organization request. Shipped implementation and merged evidence remain unchanged. This issue stays OPEN; existing priority and safety/validation gates are preserved. No next release date, implementation completion, new live-test permission or operational change is implied.