Serve PTY scrollback from on-disk pty.log instead of a 256KB ring

[edwin-zvs]

Problem

Scrolling up in a PTY-wrapped session (codex / claude / antigravity) loses content or breaks formatting after ~2 pages of page-up. Zarvis sessions don't have the symptom.

Root cause: each session kept a 256 KiB in-memory ring (PTY_RING_CAP in crates/daemon/src/session.rs) of raw PTY bytes. pty_replay returned a snapshot of that ring. The TUI's shadow vt100 parser was fed only from that snapshot, so once the user scrolled past the 256 KiB worth of bytes the ring held, there was nothing to render. Older bytes had been evicted at write time.

The existing ultracode session on disk illustrates it: 2.8 MB pty.log but only the last 256 KiB ever reached the TUI — an 11× gap, exactly the "~2 pages back" boundary.

Zarvis sidesteps this entirely because its scrollback is the structured ItemHistory, not raw PTY bytes.

Fix

Switch pty_replay to read the tail of the on-disk pty.log directly (storage.read_pty_tail), bounded by a new constant PTY_REPLAY_CAP = 8 MiB. The TUI feeds the bytes into its vt100 parser whose SCROLLBACK_MAX = 5000 rows is now the real ceiling on what survives in scrollback — exactly what the row-count cap was meant to be. Disk reads happen once per attach.

The in-memory ring was the only consumer of PtyState::push / snapshot and the startup rehydration, so they're all gone. PtyState keeps the size field for parser sizing on attach. Disk append is unchanged.

What this does not fix

The secondary codex-only issue (in-place \x1b[2J\x1b[H redraws not pushing rows to vt100 scrollback) is a separate concern and not addressed here. With the cap raised from 256 KiB to 8 MiB, that issue becomes the next thing the user hits, but it's a much smaller fraction of the symptom space than the ring cap was.

Test

Two new daemon tests:

• pty_replay_returns_full_disk_tail_not_just_old_ring — writes 1 MiB (4× the old ring) to pty.log; verifies pty_replay returns the full 1 MiB.
• pty_replay_caps_at_replay_max_for_huge_logs — writes PTY_REPLAY_CAP + 1 MiB; verifies the response is exactly PTY_REPLAY_CAP bytes AND that it's the tail of the file (most recent), not the head.

cargo test -p agentd --bin agentd   # 53 passed (51 prior + 2 new)
cargo test -p agentd-cli            # 188 passed
cargo build                          # clean

🤖 Generated with Claude Code