enhancement(codex): distinguish a live but not-yet-persisted Codex thread from a missing target #166

Summary

send --to codex:<uuid> (including --dry-run and an explicit --codex-home) reports thread_not_saved_in_known_homes for a live Codex session whose thread has not been persisted yet (before its first turn completes). The message cannot be distinguished from a wrong UUID or wrong home, and list --agent codex --all does not show the session either. Diagnosing it required tracing the process cwd and writer lock with lsof.

This is a diagnostics enhancement, not a delivery bug: refusing to queue to an unsaved thread is correct because Codex queueing requires a saved thread/rollout.

Environment

• session-peer 1.0.0rc2, macOS (mac-mini), Orca-managed Codex home
• Observed 2026-09-23

Observed

1. A new Codex session was started, but no message had been sent to it yet.
2. The process held <home>/thread-writer-locks/<uuid>.lock, but state_5.sqlite had no row for that thread.
3. list --agent codex --all (auto-discovery and explicit --codex-home) did not list the session.
4. send --to codex:<uuid> --codex-home <home> --dry-run returned No saved Codex thread <uuid> in known homes; nothing queued. (reason: thread_not_saved_in_known_homes).
5. After the first turn completed, the same dry-run resolved as explicit_live_writer, and a real send was queued normally.

Reproduction

1. Start a new Codex session and do not send it a message.
2. Run session-peer send --to codex:<uuid> --codex-home <home> --dry-run --message test.
3. Observe thread_not_saved_in_known_homes.
4. Send one message in that session, wait for the turn to finish, and repeat step 2. It now resolves.

Code location

session_peer_core/codex.py (standalone session_peer.py equivalent): when no candidate home has a saved thread, resolve raises NoTargetError(thread_not_saved_in_known_homes) without consulting thread-writer-locks/<uuid>.lock, although inspect_codex_writer already knows how to probe that lock.

Proposal

1. send / dry-run: if no home has a saved thread but exactly one home has a stably held writer lock for the same UUID, report a distinct reason (e.g. thread_not_yet_persisted) with actionable guidance such as "the Codex session has not finished its first turn; retry after it does." Still queue nothing.
2. doctor: report "live writer lock without a saved thread" as an unsaved session.
3. list (optional): consider exposing such sessions in --all with a field like persisted: false. This is an additive JSON schema change, so it needs a separate decision.
4. Keep fail-closed: do not add any workaround that queues to an unsaved thread; only improve diagnostics.

Acceptance

• Unit tests cover: no saved thread plus a held lock → thread_not_yet_persisted; no saved thread and no lock → unchanged thread_not_saved_in_known_homes; a stale lock (dead owner) is not treated as live.
• No behavior change for saved threads or for home-selection rules.