Stop-and-reboot screen restoration #232

Parent

Part of #154 (remote agent sessions). Phase 3. Design doc docs/designs/remote-workrooms.md, Distribution Plan ("The snapshot format is not a wire contract"), Next Steps item 3 (terminal-state durability) and item 4 ("Treat stop-and-reboot screen restoration separately from live-process survival"). This is the remaining half of #208's durability criterion.

What to build

When a provider stops and reboots a box, the children are dead but the user should still get their screen back.

• Persist replay()'s VT bytes, not a snapshot. At write time the terminal is live, so the bytes carry the parser continuation, which a snapshot decoded after a reboot cannot report. VT does not change between agent revisions, so after a reboot a newer agent reads what an older one wrote without starting the older binary.
• A new session state: a screen with no pty behind it. Today a Session is a pty plus the identity a client reattaches by. After a reboot the identity and the screen survive and the pty does not, and the pane must say so rather than silently opening a fresh shell in its place.
• Write policy. When and how often the bytes reach disk, a bound on their size, and where they live on the box, so a reboot mid-write never leaves a corrupt screen.

Acceptance criteria

• After a stop-and-reboot of the container fixture, a reattaching pane shows its last screen, and it is clearly marked as ended (not a live shell).
• A screen written by one agent revision is restored by a newer one.
• A reboot during a write never produces a corrupt screen: the previous screen or nothing, never a torn one.
• Persisted screens have a size bound and are removed when their session is closed by the user.
• Interchangeability services: port forwarding, terminal durability, wakefulness #208's durability criterion is fully met, and Interchangeability services: port forwarding, terminal durability, wakefulness #208 can close.

Blocked by

#228 (the supervised remote agent and the container fixture).

Filed by Claude Code at the owner's request, 2026-09-24.