bug(session): apply_patch full-file result metadata exhausts the 64 MiB transcript during a live turn

[moonbees01]

Summary

On GJC 0.13.2, a long but otherwise healthy managed session can abort during message_end when its transcript reaches the 64 MiB per-file limit. The dominant growth is not user/model prose or rendered diffs: every successful apply_patch tool result persists the complete pre-edit and post-edit file contents in message.details.oldText and message.details.newText.

Repeated small edits to one large source file therefore add roughly 2 × file_size to the JSONL on every patch. Once the next tool result no longer fits, managed append raises content_too_large; AgentSession aborts the active turn, and the just-applied source mutation may exist without its tool result or subsequent verification being durably recorded.

This is distinct from:

• resume: oversized session (~64 MiB) hard-fails with too large and no graceful fallback #3851, which added a graceful resume/open precheck for an already oversized transcript;
• Managed scope over 512 MiB makes gjc unlaunchable, reported as binding_invalid, and gjc gc cannot reclaim it #3959, which concerns the 512 MiB aggregate managed-scope budget;
• GJC_SESSION_CONTEXT_BUDGET_BYTES, whose current 512 MiB default governs context materialization rather than the managed transcript file.

I found no existing issue covering live append amplification from edit-result metadata.

Observed evidence

A real session ended with:

Session persistence error
SessionAppendPersistenceError: content_too_large
  at appendManagedFileStreamingSync (.../managed-session-storage.ts:3053)
  at #appendManagedRecordsSync (.../session-manager.ts:15630)

Sanitized measurements from that transcript:

• transcript at failure: 66,553,990 bytes (63.4708 MiB)
• per-file limit: 67,108,864 bytes (64 MiB)
• remaining capacity before the failed append: 554,874 bytes
• entries: 1,387
• apply_patch tool results: 180
• bytes attributable to those results: about 57.05 MiB (about 90% of the transcript)
• assistant entries: about 3.77 MiB
• all other tool-result families combined: about 2.63 MiB

The edited file was roughly 395–397 KiB. Individual small apply_patch results were about 0.76 MiB because their persisted details contained both full-file snapshots. The final append exceeded the remaining 0.53 MiB and failed deterministically.

The provider request itself had not failed for context overflow; the logged terminal cause was local persistence content_too_large.

Current code path

In tagged 0.13.2 and current dev:

1. packages/coding-agent/src/edit/modes/patch.ts returns full oldText and newText in EditToolDetails.
2. packages/coding-agent/src/edit/index.ts retains those fields in single-file and aggregated apply_patch results.
3. packages/coding-agent/src/session/session-manager.ts persists the complete toolResult to the managed JSONL.
4. packages/coding-agent/src/session/internal/managed-session-storage.ts rejects append when predecessor size plus appended bytes exceeds MANAGED_ARTIFACT_MAX_FILE_BYTES (64 MiB).
5. packages/coding-agent/src/session/agent-session.ts treats a normal tool-result SessionAppendPersistenceError as fatal and aborts the agent. Only todo_write has specialized reconciliation handling.

Compaction does not reliably prevent this boundary: the observed session compacted once, then accumulated another 34.66 MiB after the compaction, primarily through repeated edit results. Cold spill also preserves data elsewhere and does not change the hard per-file append contract by itself.

Minimal reproduction

A synthetic test does not need private session content:

1. Create a managed session and a source file around 400 KiB.
2. Apply many one-line apply_patch updates to that same file.
3. Inspect each persisted tool result and confirm it contains the complete old and new file bodies.
4. Continue until the transcript is just below 64 MiB.
5. Apply one more small patch.

Expected current result: the file mutation succeeds, then persistence of the tool result raises content_too_large and aborts the turn.

The same behavior can be reproduced faster with a larger synthetic file while remaining below the edit input/output guards.

Expected behavior

A small edit should have persistence cost proportional to its bounded result evidence, not twice the entire target file. Reaching a storage boundary must not leave an applied mutation followed by an unrecorded tool result and silently skipped verification.

Suggested fix boundary

The exact representation is a maintainer decision, but a complete fix likely needs both parts:

1. Bound persisted edit-result details. Keep the rendered diff, path, operation, diagnostics, and content identities/digests needed for replay. Do not inline complete oldText/newText into every durable tool result. If full snapshots are required for UI/fidelity, place them in a bounded content-addressed artifact and persist references, or strip them before session persistence after their process-local consumer is finished.
2. Handle near-limit live append explicitly. Preflight the serialized record against remaining transcript capacity and perform a typed recovery (for example a fresh linked session/handoff or a recoverable terminal receipt) before mutation where possible. At minimum, surface a structured error that states the source mutation may already have committed and provides an exact recovery path; do not continue emitting repeated message_end persistence warnings.

Simply raising the 64 MiB constant would delay the same amplification and increase resume/memory risk.

Acceptance criteria

• A regression test repeatedly applies small patches to a large synthetic file and proves durable transcript growth is bounded independently of full file size.
• Persisted edit results retain enough bounded evidence for rendering, diagnostics, replay/fidelity, and source-change accounting without duplicating both complete file bodies per edit.
• A synthetic near-64-MiB live append cannot terminate with an unclassified SessionAppendPersistenceError after a source mutation.
• The recovery result states whether the edit committed and how to continue safely.
• Existing resume: oversized session (~64 MiB) hard-fails with too large and no graceful fallback #3851 oversized-resume behavior and sub-limit sessions remain unchanged.

Environment

• GJC 0.13.2
• macOS arm64
• Bun 1.3.14

[Yeachan-Heo]

Active implementation ownership has started in a dedicated current-dev lane.

• session: gajae-code-issue-4566-apply-patch-transcript
• branch: fix/issue-4566-apply-patch-transcript
• exact base: 0a6138edbce49c0c42c9087c894f22ed8d112112
• duplicate bug(session): apply_patch persists full old/new snapshots and exhausts the 64 MiB live transcript #4567 has been closed and its equivalent evidence consolidated here

The lane is reproducing the full-snapshot amplification and post-mutation persistence boundary first, then will implement bounded durable edit receipts plus deterministic near-limit recovery without changing the existing oversized-resume or sub-limit contracts. Terminal ownership includes one PR to dev, exact-head review/CI, merge, and issue closure.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

PR #4573 is open against dev with the issue-only fix reconstructed onto exact current dev.

Exact revision:

• base: 96e718a2b0f2a46cad4876bf922886966c6fd0e3
• head: d7dd458e9d2f3aa6960d87d1fd671c46d67e9eb6
• tree: 2953e6e557baed79a6115925bc0e048d8be1d2bb
• PR: fix(session): bound apply_patch transcript metadata #4573

Scope proof: exactly five changed files; no workflow-gate/#4568 paths. The safety commit before rebase was b4e04321c78b9df516bb4ef5e1a63b949ef2fd70; its issue tree was byte-identical to the rebased tree after applying #4540.

Deterministic result on the exact head tree:

• synthetic source: 464,979 bytes
• pre-fix durable result: 943,242 bytes/patch (2.03x file size)
• fixed durable result: 1,398 bytes/patch (0.003x file size)
• 60-patch transcript: 84,394 bytes
• full live old/new bodies preserved for ACP; durable entries carry exact byte-length/SHA-256 receipts
• typed near-limit recovery tests pin committed-edit/receipt ordering

Local exact-tree verification:

• focused edit/session/ACP/tools: 154 pass, 0 fail
• session + session-manager suites: 677 pass, 26 skip, 0 fail
• edit/ACP/tools aggregate: 264 pass, 0 fail
• coding-agent package check and build: pass

Current verdict: NEEDS_HUMAN_REVIEW. Hosted CI and authorized independent exact-head review are in progress; the PR must not merge until both are bound to the exact head above (or refreshed after any head change).

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Exact-head refresh for PR #4573 after adversarial fix-forward:

• base/current dev: 96e718a2b0f2a46cad4876bf922886966c6fd0e3
• head: 96754755ad41c95b03bcf9bb690cd4aeb9b4d366
• tree: ce054b179e3aaa78982309ca5ecfade083d66b8f
• canonical diff digest: 866540568b165d0d97f7e8538cbc7144f8985364b583895667c58077d3c9a36b

Fix-forward: snapshot receipts are now generated before the generic 500k persistence truncation. A new regression proves exact full-body UTF-8 byte lengths and SHA-256 hashes for old/new snapshots above 500k; focused test count is now 49 pass / 0 fail.

All product jobs in Dev CI run 31862850261 are terminal green. The sole red remains the intentional needs-human bootstrap. Exact-head authorized review requests are pending from probepark and HaD0Yun; no approval exists, so this remains OWNER_CONFIRMATION_REQUIRED and unmerged.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Fixed by #4573 — closed with dev-merged evidence

fix(session): bound apply_patch transcript metadata (#4573) squash-merged to dev as 87b540d2caa57af71737f2f39d65d5c7d9337b8d at 2026-08-15T13:26:28Z (dev tip at merge time).

Verified binding:

• PR head 055546bd38cf2ada32b6ad8f0b95ae2d74a2e13d (canonical digest 1e0edc73077284c2539b7b6c37f10ed0fa772d90d6942d370f4885d0187b35f7), base 804314081fe9.
• git diff 055546bd38 87b540d2c over all four source/test files is empty — the squash commit carries the PR's source byte-identically (5 files, +898/−3).
• Merge gates on the exact head were terminal green before merge: Dev CI run 31886500438 completed with zero failed jobs, including PR contract bootstrap passing against the promoted merge-approved verdict (reviewer probepark, write-authorized non-author, APPROVED at commit 055546bd38cf, differential review: 5/6 fail on base including a 5s timeout hang from unbounded transcript growth, 6/6 pass on head).
• Regression pin shipped with the fix: packages/coding-agent/test/edit-result-persistence-bounding.test.ts (6 tests) — durable per-patch transcript bytes drop from 2.03x file size (943,242 bytes/patch on a 464,979-byte file) to 0.003x (1,398 bytes/patch), with SHA-256/byte-length receipts computed pre-truncation and the typed SessionNearLimitAppendError near-limit contract.

This issue tracks the live-turn 64 MiB transcript exhaustion; the durable bounding landed in dev, so the issue is resolved. Closing as completed.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]