Best possible solution:

Keep the bounded recorder/writer direction, but make the recorder or writer account for existing sidecar bytes and max-file skips before landing so the linked bug closes through this PR.

Do we have a high-confidence way to reproduce the issue?

Yes, source-level. Current main serializes runtime events before queueing and lets cleanup continue after the 10s timeout, and the PR blocker is also source-reproducible from the writer max-file no-op path.

Is this the best way to solve the issue?

No, not as written. The bounded capture approach is the right maintainable direction, but it needs to treat max-file skips or pre-existing sidecar size as dropped capture before merge.

Full review comments:

• [P1] Treat max-file skips as dropped writes — src/trajectory/runtime.ts:285-292
  The recorder now relies on writer.write() to decide when capture stopped, but the queued writer returns "queued" before safeAppendFile() can skip the append because the existing sidecar is already at maxFileBytes. For a later turn on a near-cap or over-cap trajectory file, runtime capture can keep building and sanitizing events without emitting the intended truncation marker, leaving the long-lived-session stall path only partially fixed.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.88

Acceptance criteria:

• pnpm test src/agents/queued-file-writer.test.ts src/trajectory/runtime.test.ts src/trajectory/export.test.ts
• pnpm check:changed in Testbox before handoff if promoted by a maintainer

What I checked:

• Current cleanup timeout leaves cleanup running: Current main races cleanup against a 10s timeout and logs on timeout while keeping the original cleanup promise alive with a late rejection handler. (src/agents/run-cleanup-timeout.ts:20, f0537e93fbe6)
• Current runtime serializes before queueing: Current main sanitizes/stringifies each runtime trajectory event before queueing it, then flush waits for the queued writer. (src/trajectory/runtime.ts:203, f0537e93fbe6)
• Current queued writer can silently skip max-file appends: The writer's maxFileBytes guard returns from safeAppendFile without exposing that no append happened to callers. (src/agents/queued-file-writer.ts:92, f0537e93fbe6)
• PR trusts writer.write as the acceptance signal: The PR increments acceptedRuntimeBytes after writer.write returns anything other than "dropped", but the queued writer still returns before the async max-file guard can skip the append. (src/trajectory/runtime.ts:285, ceb110ce1f12)
• PR writer still returns queued before file-cap outcome: safeAppendFile can return without writing when maxFileBytes is exceeded, while write still returns "queued" immediately after scheduling the chain. (src/agents/queued-file-writer.ts:153, ceb110ce1f12)
• Regression test misses existing sidecar size: The new capture-budget test uses an in-memory writer that always accepts writes, so it does not cover a real near-cap or over-cap existing trajectory sidecar. (src/trajectory/runtime.test.ts:120, ceb110ce1f12)

Likely related people:

• steipete: Local blame and file history show Peter Steinberger introduced the current main trajectory runtime, queued writer, and cleanup timeout code now being modified, with earlier nearby queued-writer refactor history in the same area. (role: recent maintainer and adjacent owner; confidence: high; commits: 605e89468ebf, 817b5812e10a; files: src/trajectory/runtime.ts, src/agents/queued-file-writer.ts, src/agents/run-cleanup-timeout.ts)
• scoootscooob: The related merged trajectory export/default-on capture PR in the provided context added the recorder/export surface whose runtime sidecar behavior is involved here. (role: introduced trajectory feature surface; confidence: medium; commits: a3d9c53db299; files: src/trajectory/runtime.ts, src/trajectory/paths.ts, src/agents/queued-file-writer.ts)

Remaining risk / open question:

• The remaining blocker should be verified with a focused case where an existing runtime sidecar is already near or over the 10 MiB capture cap.
• This read-only pass did not rerun the focused tests or a live 50 MiB Gateway reproduction.

Codex review notes: model gpt-5.5, reasoning high; reviewed against f0537e93fbe6.