🤖 perf: session tape read side follow-ups for T3 (from #5568)

[ThomasK33]

Tracking the limitations of the session tape read side (T2, #5568), for the perf tape program. Tapes hold full chat content; every fixture and repro here must be synthetic.

Owner: T3 (perf E2E tape replay). Trigger: when T3 starts.

T2 ships only the offline read side: the loader, the offline replay driver, bun scripts/perf/tapeInfo.ts and the synthetic tape builder. Delivering a tape to the app renderer, with network isolation, is T3's main scope and is not tracked here.

Current limitations of the offline read side

1. Bounded-reader size check. readSessionTapeFile reads the whole file before validating it. Stat the path first, and refuse non-regular files and files above the recorder's tape cap (32 MiB) before reading.

2. Validation time. Loading is synchronous. A 24.1 MiB synthetic tape with 60,007 events took 0.6 to 0.9 s (Bun 1.3.12). That is a measurement for one fixture shape, not a worst-case bound. Recheck it once T3 plays tapes inside the app, where a long synchronous load blocks the main process.

3. Offsets above the timer limit. A recorded t above about 24.9 days (2^31-1 ms) is clamped by setTimeout, so later events would burst. Wait in bounded chunks against the absolute deadline, or reject such offsets in the loader.

4. Space-padded workspace ids. The recorder hashes the raw workspaceId for the header's workspaceIdHash. A tape recorded through a space-padded id therefore carries a hash that a trimmed-id check will not match. Trim the id in the recorder (sessionTapeRecorder.ts) before hashing, like WorkspaceService does.

5. Malformed UTF-8. readSessionTapeFile decodes with replacement characters, so a corrupted byte is not reported. Read bytes and decode with a fatal TextDecoder before loading (Codex, 🤖 perf: session tape loader, offline replay driver and tapeInfo CLI (T2) #5568 round 6).

6. Pathologically deep JSON. An event nested deeply enough for JSON.stringify to overflow the stack throws RangeError out of loadSessionTape instead of rejecting the tape. Convert non-TapeRejection errors during canonicalization and decoding into a rejection (Codex, 🤖 perf: session tape loader, offline replay driver and tapeInfo CLI (T2) #5568 round 6).

Features for T3's app integration

7. Resumable replay. Only a fresh full replay is planned. Re-entering a replayed workspace (a since resubscription) needs an explicit design, or a documented refusal.
8. Fast pacing through the app. The driver supports pacing: "fast". Decide whether T3's harness exposes it (for example make perf-tape TAPE=<file> PACING=fast).

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $43.69

[ThomasK33]

Status after T3 (#5612):

Done in #5612: items 1 (stat-bounded read, 32 MiB cap, regular files only), 3 (timer chunking), 4 (trimmed-id hash), 5 (fatal UTF-8), 6 (deep JSON rejected, header and trailer included). Item 7 is a documented refusal (since/live subscriptions are refused; reload replays).

Still open (owner: perf tape program, trigger: the first replay of a real recorded tape in the app):

1. Validation time (item 2). Tapes still load synchronously on the Electron main process.
2. Fast pacing (item 8). App playback uses recorded pacing only.
3. Replaying real local tapes through make. make perf-tape-replay replays only the committed synthetic fixture. A real tape needs its workspace id (the header holds only a hash).
4. Composer side effects of replayed events (Codex, 🤖 perf: replay synthetic session tapes through the desktop app with egress blocked (T3) #5612 round 5). restore-to-input and auto-compaction-triggered events in a tape still dispatch UPDATE_CHAT_INPUT and touch the replayed workspace's draft. Replay workspaces are scratch workspaces, so no real draft is affected. The fix is to skip those handlers when window.api.isSessionTapeReplay is set.
5. Replay mode does not take the app's other background network offline (git remote queries, gh, Coder CLI probes). make perf-tape-replay isolates them in the harness (failing coder/gh stubs, git wrapper with GIT_ALLOW_PROTOCOL=file). Running a manual desktop app with XUM_REPLAY_TAPES gets no such isolation.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $24.50

[ThomasK33]

More follow-ups from #5612. The UAT runs on the final head (62c186e) found these low-severity issues. I did not fix them: the review cap was reached, and a fix would have changed the head.

1. The refused workspace shows the wrong reason for blocked sends. When replay is refused, the composer says "Transcript is still loading — wait until it is up to date before sending or editing." It does not show the replay refusal. Sends are still blocked.
2. The harness refusal names the wrong source of the markers. The message says make perf-tape-replay sets XUM_E2E=1 and XUM_REPLAY_HARNESS=1. The spec actually sets XUM_REPLAY_HARNESS, and electronTest sets XUM_E2E.
3. User docs are missing. No page covers XUM_REPLAY_TAPES, the harness markers, the tape-path allowlist or make perf-tape-replay. The allowlist accepts absolute local paths that contain .. and paths through symlinks. Document that this is intended.
4. The leak audit has two unattributed rows. During the window between UAT rounds 2 and 3, the audit recorded two api_key login rows at 10:52Z with an iPhone Safari user agent, presumed to be the owner's browser. They need the owner's confirmation.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $39.60