[AbirAbbas]

An idle chat on a paired computer now hands its hold to the sync service. Opening it on another paired computer takes it over without the Continue-here step, even when the first computer is off. A running chat still asks, so you can watch it without taking it.

Base is app/v3. The desktop engine and the take path this builds on live on app/v3. When app/v3 lands on dev, this change goes with it, and if it is still open then, the PR re-points to dev. The branch is up to date with app/v3 a687c92, merged rather than rebased. Before it merges, it is also tested in a local merge on the app/v3 → dev landing candidate. That merge is not part of this PR.

Desktop half: Agent-Field/codeaf-desk#102 opens a can_open row directly.

What changes

• Release when idle. A chat on a computer in a paired set (two or more computers on one identity) lets go of its hold about 2 seconds after it goes idle, once everything is on the sync service: turns, settings saved after the last turn, workspace and vault.
  • Work keeps the hold exactly as today: a running turn, queued or steering work, a task that is starting or parked, jobs, title and memory writers, and unsent turns.
  • Release also waits until the capture is complete and nothing is unsaved, since app/v3 saves the work folder at pauses (Save the work folder at pauses, not after every tool batch #2356).
• Take back in place. New work in the window that released (a send, queue, steer, retry, task or ! shell) takes the chat back before any write or model call.
  • It acquires a new fence, conditionally and with the saved head unchanged. There is no restore and no setup question, and local files such as node_modules stay.
  • If another computer took the chat, the work gets today's held-elsewhere refusal and nothing is written.
• Open a free chat directly. Chat rows carry an optional can_open.
  • It is set only for paired homes, and only from the directory's own lease expiry.
  • Opening such a chat in the terminal, or through agents.open with its id, takes it with a non-forcing conditional acquire, checked again at acquisition.
  • A live hold keeps the Continue-here choice. Rebuildable files are not carried, as today.
• Copy folder name (pre-existing, now frequent). A chat moving back and forth no longer nests its copy-folder name until file name too long. Names are kept and capped at 240 bytes with a stable hash.

How this fits app/v3's ownership rules (93d4b7f)

app/v3's 93d4b7f ("Restore dev ownership expiry and exact-fence consent", part of the #2291 dev merge) replaced the earlier app/v3 behaviour, where an idle expired hold was renewed with the same fence by heartbeat. Its rules:

• an expired hold admits nothing until the person continues the chat;
• reopening takes a new fence;
• a take needs the exact fence it saw.

This PR keeps those rules for every hold but one:

• Only a window that released its own hold (through the idle path above, after certifying its saved state) may take the chat back, and only when new work arrives in that window.
• It does so by conditionally acquiring a new fence, with the saved head unchanged and nothing pending, before admitting anything. It never heartbeats or reuses the released fence, even if a stray heartbeat or a lost release reply left that lease live.
• A hold that merely lapsed, or was released from outside its window, takes app/v3's path unchanged: it is available, and the person continues it.

93d4b7f's own regression tests pass on this branch:

• TestReleasedSameFenceRetiresReceiptUntilContinuation
• TestAnExpiredHoldCannotAuthorizeTools
• TestIdleExpiredHoldRequiresContinuation
• TestStartupAcquiresNewHold
• TestIdleWatchReconnectAndProcessReacquisition
• TestRelayOutageO4FailedIdleRenewalKeepsWorkLocal
• TestAvailableAfterALapseRetiresTheReceipt
• TestConditionalAcquireRejectsNewerFenceWithSameHead
• TestTakeF2SameHolderSameHeadFenceChange
• TestHostedTakeBackReachesAcquireWithoutSharedUploadsOrReleaseDelay

TestIdleRelease_93d4_SelfReleasedRetakeIsANewFenceNeverARevival is built from the first of them. It checks that:

• a self-release closes the gate and sends no heartbeat at the released fence;
• an outside heartbeat there does not reopen it;
• new work takes a strictly newer fence;
• a chat another device took is refused;
• a lapsed or outside-released drive behaves exactly as 93d4b7f requires.

Nothing changes for anyone else

• Opt-in by pairing. A home with sync off, or a single device, makes no new requests and keeps the same renewal cadence. A test counts every request type over a full 30 s renewal period.
• Old builds keep working. An old holder never releases, so a new computer shows Continue here as before. An old reader sees a released chat the way it sees a lapsed hold today. can_open is optional and omitempty. The lease rules, wire, directory protocol and replicated records are unchanged.

Validation contract

• C1. A paired, idle chat with its turns uploaded is released within a few seconds; the directory shows no live holder.
• C2. A running turn, queued work, a running, starting or parked task or job, or unsent turns keep the hold, renewed as today.
• C3. New work in the released window, when nobody else took the chat, retakes it at a new fence before any write or model call, with no prompt.
• C4. If another computer took it, new work gets the held-elsewhere refusal and nothing is written locally.
• C5. Nothing is lost. Turns, journal, workspace (minus rebuildable files), memory and settings are on the sync service before the release, and a failed upload keeps the hold.
• C6. Opening a released chat on another paired computer pulls and takes it with no Continue-here prompt; its state matches the last save. A hold that merely lapsed (for example during a long outage, possibly mid-turn) still asks Continue here, as on app/v3.
• C7. Opening a chat another computer holds behaves as today: you can watch, and Continue here stays the person's choice.
• C8. C6 works while the first computer is stopped.
• C9. Rebuildable files are not part of the hand-off.
• C10. Unpaired and single-device homes behave exactly as before.
• C11. Old builds on either side keep working.
• C12. A send racing an open ends with exactly one owner under today's fencing.

Each item maps to TestIdleRelease_C* / TestIdleOpen_C* tests in cellsync, cellstore, session, syncsetup, chatlist, handoff, tui3 and cmd/codeaf.

Verification

• CI: the PR gate is green on every pushed head. Full check is green except TestAServedFactoryStartsAGoAheadsJobWithNoAppAttached, which is pre-existing on app/v3 and fixed on the landing candidate. Other reds seen along the way are pre-existing on base or proved to be flakes: TestMemoryLateReceiptReachesFactoryHeaderAfterQuit (A factory memory receipt that lands after Quit is missing from the ledger or the header (TestMemoryLateReceiptReachesFactoryHeaderAfterQuit fails ~1 in 3) #2566), TestFactoryRetryActionsDoNotReportStopped and the factory memory pause tests fail on base too, and a loop-speed timing law matched base in interleaved runs.

• Mac two-home hand test (macOS arm64), throwaway homes, local sync service and stub model, base app/v3 a687c92 against this branch:

  • C1: released 4.2–4.7 s after idle.
  • C2/C7: a running chat is never taken; B gets the Continue card.
  • C3: retakes in place at a new fence before the reply.
  • C4: held-elsewhere refusal; nothing written.
  • C5/C6/C9: no prompt, and history, files, memory and a setting changed after the last turn all arrive. Inside a Git work folder, an ignored node_modules stays behind. Outside Git it travels, the same as on base, because the install-folder rule needs a lockfile that travels.
  • C8: works with the first computer stopped.
  • C10: unpaired and single-device homes match base.
  • C11: interoperates with dev's build as the old device.
  • C12: one owner in every race.
  • Six alternating hops kept every journal exact.

• Found and fixed during the hand tests:

  • After a sync outage, a chat taken back from Home could not send until restart. Drive.RenewalStatus reported a self-released writer as never installed. It now keeps its period with holding false. Covered by TestIdleRelease_R4_RA_…; the Mac reran 15 of 15 sends and Linux 5 of 5.
  • A stray heartbeat at the released fence could have let a self-released window work under that fence. It now always takes a new one (TestIdleRelease_93d4_…).
  • The desktop's take now says <computer> picked this chat up again when that same computer took its own chat back, instead of blaming another device.
  • After a restart, the first Home open of a chat another computer had released stayed a viewer. Home decided from its display rows before they had loaded. It now reads ownership when the display can't answer, and then takes the free chat (TestIdleOpen_R5_…). The Mac measured 0.7–0.8 s to hold.
  • Opening your own saved chat never waits on, or fails on, the sync service. That read is bounded to 2 s and only made when needed; offline, Enter opens the local chat as before, and a remote row says the service is unreachable (TestIdleOpen_R5b_…, TestIdleOpen_R5c_…).
  • Opening a chat that owes no turn no longer prints a false "asking again". The resume door now checks for an owed turn before asking the work gate (TestR6_…). This also removes the same noise on app/v3 for chats held elsewhere.
  • A lapsed hold whose holder may have been working is never taken silently. It keeps the Continue-here card; only a released hold opens directly (TestIdleOpen_R6_…). TestIdleRelease_R6_LapsedHolderIsFencedAfterAnOpenElsewhere proves the fencing: the expired holder admits nothing, the open takes a new fence, an old-fence publish is refused, and local turns are kept.
  • The first Enter after the sync service returns sends, as on app/v3. It no longer replays a cached refusal (TestIdleOpen_R7_…).
  • A chat reopened after its writer's close failed offline gets a fresh writer instead of staying view-only (TestIdleRelease_R7_…; the same path exists on dev, A chat reopened after its writer's close failed stays 'this window only shows the chat' until restart #2581).

• Performance (Mac, 10 open chats, 3 runs each, equal homes):

  • steady idle CPU is 0.35–0.41% on this branch against 0.34–0.37% on base;
  • wakeups are 16–22/s against 21–28/s;
  • RSS and open files match base within noise, and the sync service sees no idle HTTP traffic;
  • taking a held chat is unchanged;
  • opening a released chat takes 0.8–1.0 s;
  • each release costs about 0.07 CPU-seconds once.

• Focused tests after the merge:

  • the contract tests;
  • app/v3's newer sync tests;
  • 93d4b7f's regression tests;
  • the full internal/manual package;
  • make test-quick.

• Landing candidate. In a local merge with land/app-v3, with dev's hosted sync storage opt-in (Hosted relay storage is off until an account is approved #2509):

  • an idle chat whose account cannot store keeps its hold and adds no requests;
  • nothing unstored is ever offered as openable;
  • storage-off Continue keeps working.

  That needs three dev-only guards, which go into the landing merge rather than this PR.

• Pending before merge:

  • Mac re-check of the R7 fixes on this head.
  • Core flows rerun with short paths: the first run's socket paths exceeded 103 bytes, so its reds don't count; the hand checks for tools, tasks, settings, pairing with --at and moving a running chat passed.
  • A rerun of the F-6.k2 double-outage sequence on the landing candidate once it carries Fix what the pre-release hand test of dev found #2567.

Evidence that a take never admits a stale publish (Mac, local sync service, chat taken while its holder was mid-turn): the relay log shows the holder's last publish and beat at fence 1 (10:10:46.919/.931), then the taker's forced acquire expecting fence 1 → fence 2 (10:10:48.561), a conditional acquire → fence 3, its publish at fence 3 and its release. There is no entry from the old holder after the acquire, and no 409 or 5xx. The taker's continue fetched the holder's last result before acquiring.

Issues found along the way and filed: #2563 (the stub answers codeaf's helpers note), #2564 (the arrival brief swallows typing), #2569 (approval waits for the 10-minute permission refresh), #2574 (offline Enter on a remote row gives no answer), #2579 (copy-folder names grow per move on app/v3 and the landing candidate; fixed here), #2580 (a cached refusal replayed after recovery, on other roads), #2581 (a reopened chat after a failed close; fixed here). Full-check flakes seen: TestSteersLandInTheOrderTheyWereSent passes 5/5 on head and base (recorded on #1749).

Also noted: on first launch, codeaf chat continues another computer's latest released chat automatically. That is base behaviour, seen on dev's build too.

Not in this PR

• An acquire-receipt protocol for reconciling a lost acquire reply. It would change the replicated lease state, so it belongs to the sync-service owner. An uncertain take-back here stays honest and retryable instead.

🤖 Generated with Claude Code