fix(cursor): truncate toolResult bodies across compact reload - #1044
fix(cursor): truncate toolResult bodies across compact reload#1044leeseunguk wants to merge 15 commits into
Conversation
Keep the code-yeongyu#984 mid-turn compact skip, but cap each toolResult text part to 2000 chars at Cursor admission and again after compact reloads sessionContext.messages so the retry cannot restore megabyte jsonl bodies (code-yeongyu#1043).
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-1 adversarial review: this is not mergeable or buildable, and the core recovery path is still not correct.
B1. Build is broken. this.agent.allowConversationRotate is not part of the actual Agent or AgentState contract in this tree. CI reports TS2339 at agent-session.ts:1326 and agent-session.ts:6760; the required Check and test gate is red. Make this a real typed/runtime API or remove it; suppressing the type error is not a fix.
B2. The claimed remint is not implemented. Even if B1 were papered over, this field is never read anywhere in the agent or Cursor provider. Cursor's actual wire-id remint is driven by the provider rotation store, while the session retry path uses sameModelRemint; assigning an undeclared, unread field cannot change the wire id. The PR body and changelog claim that truncation remints, but this diff does not establish that behavior.
B3. The new cleanup can be unreachable in the exact overflow case it is supposed to fix. _executeCompaction() calls _wouldCompactionOverflow() before it reaches the reload assignment and this pass. _wouldCompactionOverflow() rebuilds from persisted JSONL, which this PR intentionally leaves full. A 1 MB result is roughly 250k tokens under this tree's estimator, so on the default 200k Cursor window the compaction is rejected as would-overflow before line 5146 ever runs. That leaves the original retry wedge intact. Size the simulation using the same truncated retained context, or otherwise make truncation happen before this guard.
B4. Per-part truncation does not bound the request. A single toolResult with 1,000 text parts at 2,000 characters each, or a kept turn with 1,000 results, is still approximately 2 MB before protobuf/JSON overhead. buildRootPromptMessagesJson() and buildConversationTurns() serialize all of it. The code comment says the skip cannot send MB-scale payloads; this implementation still can. The bound must cover the result/request, not only each individual text part.
B5. The boundary semantics are wrong for Unicode and for the stated hard cap. length and slice operate on UTF-16 code units, not Unicode characters or UTF-8 bytes. For example, "a".repeat(1999) + "😀" has length 2001 and this slice leaves an unpaired high surrogate; 2,000 CJK characters are also about 6,000 UTF-8 bytes. Existing Cursor CLI sizing and shared truncators use byte-aware handling. On top of that, appending \n...[truncated] makes every truncated output maxChars + 15, so this is not actually a 2,000-character cap. Define the unit explicitly and make the cutoff safe and inclusive of the marker.
B6. The clone breaks session identity and pending-persistence invariants. { ...msg, content } creates a new message object. session-manager.ts stores contextMessageEntryIds and messageEntryPositions in WeakMaps keyed by the original objects, so a re-truncated session-context message loses both associations; remote replay/provenance checks can then fail when a user switches from Cursor to an OpenAI Responses route. Worse, _messageEndsAwaitingPersistence also tracks exact original identities. If this helper runs before a queued message_end is persisted, the compaction/reload filters at lines 5132-5138 and _restoreAgentMessagesFromSession() do not recognize the clone and can drop the in-flight tool result from agent.state.messages. Preserve identity/metadata or make the persistence and replacement transaction explicit, then add a deterministic race test.
B7. The advertised 4/4 test result does not test the behavior. Two tests exercise the helper, and the other two search source text for substrings. Nothing drives AgentSession and the agent loop through an actual compact/reload/provider admission, verifies that the captured Cursor payload is truncated, verifies that full JSONL reloads are handled, or verifies a real wire-id remint. This is precisely the lifecycle path where the bugs above hide.
B8. The PR is still unmergeable. GitHub reports mergeable=CONFLICTING and mergeStateStatus=DIRTY; the branch is based on an older main ancestry and conflicts in the exact core/changelog zones documented by the PR. Rebase/merge main and resolve the conflicts before this can be landed or meaningfully re-reviewed.
B9. Required CI is failing. Check and test is red: the build fails on the two missing allowConversationRotate properties, and Static checks independently fail on unsafe optional chaining in the new test. Changelog gate is green and the release CHANGELOG plus nearest src/core/changes.md entry are present, but that does not offset a broken build, failed required gate, or unresolved merge conflict.
B10. The first post-resume admission still bypasses this fix. Agent.runPromptMessages() enters runAgentLoop() and makes its first provider request before prepareNextTurnWithContext is ever called. A session reopened with full JSONL tool results therefore still sends those full results on the first Cursor request; this helper only runs after an assistant/tool turn has already completed. The admission guard must cover the initial request too, or the claimed Cursor payload protection is incomplete.
VERDICT: REQUEST_CHANGES
|
Addressed review 5058035474 and merged origin/main.
Verification: repo six-phase build passed; targeted compaction/regression tests passed (95/95); root typecheck passed; Biome/static checks passed; changelog/install-lock gates passed. The initial failing evidence was the pre-fix compaction suite (4 failures from unconditional faux-provider truncation), then the narrowed implementation passed all 95 tests. Pushed commit e7d7068 to leeseunguk/fix/cursor-toolresult-truncate. |
|
review-1044-r2 - code-trace |
There was a problem hiding this comment.
Round-2 adversarial review of e7d7068.
Round-1 blocker verdicts:
- B1 RESOLVED. The undeclared
allowConversationRotateassignment is gone; the only remaining remint references are the actual Cursor rotation-store path. - B2 RESOLVED. No fake/unconsumed remint field remains in AgentSession.
- B3 RESOLVED by code inspection.
_executeCompaction()calls_wouldCompactionOverflow()atagent-session.ts:5289; that method builds the simulated retained context and callstruncateToolResultBodies()at:5424-5425beforeestimateMessagesTokens()at:5427. - B4 NOT FULLY RESOLVED. The 50,000-byte counter is aggregate across all text parts/results, but it is not a bound on the whole serialized tool-result/request. Image parts are ignored by the helper, while Cursor serializes tool-result images into
createCursorMcpResult()(packages/ai/src/api/cursor-agent.ts:3975-3991) and embeds them in conversation steps. A single image can therefore still produce a multi-megabyte Cursor request. JSON/protobuf metadata and the duplicated root-prompt/conversation representations are also outside the claimed bound. - B5 PARTIALLY RESOLVED, still open. UTF-16 splitting and marker-over-budget behavior for the normal 2,000 limit are fixed with UTF-8/code-point accounting, but code-point boundaries do not protect grapheme clusters. A cutoff can split a combining sequence or ZWJ emoji (for example
e\u0301or👩💻) even though the test only covers a standalone emoji. Also, onceremainingBytes < markerBytes, the implementation silently emits an empty part rather than a marker. - B6 PARTIALLY RESOLVED. The helper mutates
part.textin place and returns the same messages, so it fixes the specific WeakMap clone regression. However, this identity-preserving mutation also reaches freshly emitted tool results before AgentSession persistence has completed (see new blocker 4 below). - B7 NOT RESOLVED. The new
1043-cursor-toolresult-truncate.test.tsstill only constructs plain messages and calls the exported helper. There is no AgentSession run, session reload, captured Cursor provider payload, or first-request/compact-reload lifecycle assertion. The identity and aggregate assertions are helper-level tests, not runtime regression coverage. - B8 NOT RESOLVED. GitHub currently reports
mergeable=CONFLICTING/mergeStateStatus=DIRTY. The currentmainis7493d42a50d2954f34529cc7d22290a3b9991c12, while this PR is based atac2f171232187ccce6d5657260c8d7ee63c58d17;git merge-treereports content conflicts in bothpackages/coding-agent/CHANGELOG.mdandpackages/coding-agent/src/core/changes.md. - B9 RESOLVED in source. The two
allowConversationRotateTS2339 sites and the unsafe optional chain from the old test are gone. The available e7 checks are green, although the claimed full Check-and-test gate is not reported for this commit. - B10 RESOLVED by call-order trace. A resumed session loads
existingSession.messagesbefore AgentSession installs its transform;runPromptMessages()entersrunAgentLoop(), whose firststreamAssistantResponse()callsbuildProviderContext(), which invokestransformContext()beforeconvertToLlm()and the provider stream. The first request therefore reaches the Cursor truncation wrapper even thoughprepareNextTurnWithContext()is not called for that request.
New blockers found in this pass:
-
Cursor-only truncation leaks into non-Cursor lanes. The Cursor guard controls whether the helper runs, but the helper mutates the shared
agent.state.messagesobjects in place (agent-session.ts:1367-1374and:6987-6991). After a Cursor request truncates a resumed full result, switching to OpenAI/another provider does not restore the canonical full session context; the next non-Cursor request therefore receives the Cursor marker/empty bodies. This makes the feature provider-visible outside Cursor despite the call-site guards. Use a provider-specific request view or restore full canonical objects when leaving Cursor. -
Aggregate eviction preserves the wrong side of history and silently destroys the newest results. The helper walks messages and parts oldest-to-newest (
agent-session.ts:840-871). Once older results consume the 50,000-byte budget, every later/newer part takes theremainingBytes < markerBytesbranch and becomes an empty string. With the test's 100 large results, the first results consume the budget and the newest results are blank. Cursor's immediate continuation needs the newest tool outputs most; at minimum the policy must be explicit and preserve recent results (and retain a truncation marker instead of silently blanking them). -
The merge resolution drops unrelated main history. Relative to the PR base,
git diff ac2f171232187ccce6d5657260c8d7ee63c58d17..e7d7068cb99b423dac9a2ae2cf20ca0437678c94deletes 473 lines frompackages/coding-agent/CHANGELOG.mdand 630 lines frompackages/coding-agent/src/core/changes.md. This is consistent with keeping stale branch copies while resolving the merge, not with a clean main merge, and would erase unrelated release/change records. Rebase/merge current main and preserve both sides before landing. -
In-place admission truncation can persist the redacted body. The agent loop emits each tool result into
agent.state.messagesand AgentSession queues itsmessage_endpersistence asynchronously. For Cursor,prepareNextTurnWithContext()takes the early_truncateCursorToolResultBodies()branch without awaiting_agentEventQueue; therefore a newly produced long tool result can be mutated before_processAgentEvent()callssessionManager.appendMessage(event.message). The implementation comment at:5422-5424says persisted JSONL remains verbatim, but this race can write the truncated/empty text to JSONL, and a later resume cannot recover it. Keep a separate provider request view or make persistence and mutation ordering explicit.
Please address the still-open B4/B5/B7/B8 items and the four new blockers above, then rerun a real AgentSession/provider-capture test over resume, first request, compaction reload, aggregate eviction, provider switching, and persistence ordering.
VERDICT: REQUEST_CHANGES
|
Round-2 blockers addressed in
Verification: targeted Vitest 5/5 passed; |
|
review-1044-r3 - code-inspection |
|
review-1044-r3 - provider-serialization-and-regression-validation |
|
WORKING: review-1044-r3 - submission |
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-3 adversarial review of d219d4d.
Resolution checks:
- B1/B2/B9 RESOLVED. The stale
allowConversationRotate/fake-remint references are absent,npm run buildpasses, both changed files have no LSP diagnostics, anddiff --checkis clean. - B5 PARTIALLY RESOLVED.
Intl.Segmenterwith grapheme granularity protects combining marks, ZWJ sequences, and regional-indicator clusters; the marker is included in the normal 2,000-grapheme budget. The aggregate/marker edge cases below remain open. - B6/N1/N4 RESOLVED for the normal request path.
ExtensionRunner.emitContext()deep-clones before the Cursor wrapper, and the helper clones changed messages/content parts instead of mutating the source.buildProviderContext()invokes this transform before conversion on the initial request, so queuedmessage_endpersistence receives the canonical full object. - N2 RESOLVED. The helper walks newest-to-oldest and retains tool-call/result messages and IDs, so eviction does not orphan a result from its call.
- N3/B8 RESOLVED. The PR is based on current
origin/main, GitHub reports mergeable, and the diff againstorigin/mainadds only 2 CHANGELOG lines and 1 core-changes line. - B10 RESOLVED. The first resumed request goes through
buildProviderContext()->transformContext()beforeconvertToLlm()/the provider stream.
Remaining blockers:
-
The aggregate bound is still violated for multiple text parts. In
truncateToolResultBodies(),effectiveMaxBytesreservesmarkerBytesfor every text part, but the full-part fast path at lines 895-897 admits text againstmaxBytes, noteffectiveMaxBytes. The later truncated parts then add their markers on top of the original 50,000-byte budget. I reproduced this from the checked-out code with one 100-byte old result, eight 2,000-grapheme CJK results, and a 1,990-byte newest result: the returned tool-result bodies total 50,005 bytes. This also means the new aggregate test can pass while a multi-part case exceeds the advertised cap. -
The compaction-overflow fix is regressed by discarding the request view.
_wouldCompactionOverflow()buildssimulatedMessages, callstruncateToolResultBodies(simulatedMessages)atagent-session.ts:5513-5515, and then estimatessimulatedMessagesat line 5516. The helper is now non-mutating and returns the transformed array, so this call has no effect. A retained context containing a large tool result is therefore still sized at its full persisted body and can be rejected aswould-overflowbefore the Cursor-safe compaction can be committed. Use the returned messages in the estimate and ensure the post-compaction admission follows the same transformed view. -
The 50,000-byte counter is not a bound on the complete Cursor serialized request. It counts only raw tool-result text plus base64 strings. Cursor builds both
rootPromptMessagesJsonandConversationTurnStructurehistory from those results (cursor-agent.ts:3922-3937,:4097-4114), and paired results are represented in both structures; protobuf/JSON envelope and MIME/tool-call metadata are additional bytes. Image data is decoded from base64 into protobuf bytes at:3995-3999, so base64 counting is conservative for the image bytes themselves, but it does not account for the remaining envelopes or the duplicated text representation. A checked-out reproduction with eight 2,000-character CJK tool bodies leaves 48,000 raw body bytes while the decoded root and turn history JSON representations are about 49.7 KB and 49.9 KB respectively (about 99.7 KB together). The implementation therefore does not establish the claimed whole-request bound, and a single result can still produce a large serialized admission relative to the 50,000-byte contract. -
B7 remains unresolved: the regression suite is still helper-level for this feature.
1043-cursor-toolresult-truncate.test.tscalls the exported helper directly; it does not run an AgentSession with a Cursor serializer/provider capture, inspect a real root/turn payload, verify full JSONL after a queuedmessage_end, or exercise provider switching. The existing1009test uses the faux stream and seeds a large user transcript, not a large tool result, so it does not fail if request-view truncation, persistence ordering, or Cursor serialization regresses. The four helper tests passed, as did the targeted 1009 test, but those tests do not cover the blockers above.
Verification performed: npx vitest --run test/suite/regressions/1043-cursor-toolresult-truncate.test.ts test/suite/regressions/1009-cursor-payload-re-compaction.test.ts (5/5), npm run build in packages/coding-agent, npx vitest --run test/cursor-agent.test.ts in packages/ai (33/33), LSP diagnostics on the changed source/test files, and git diff --check.
VERDICT: REQUEST_CHANGES
|
Round-3 blockers F1-F3 and B7 addressed in commit 92ace3a.
Verification:
Pushed to |
|
WORKING: review-1044-r4 - adversarial reproduction of F1-F3, AgentSession/persistence coverage, and Cursor wire-budget assumptions |
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-4 adversarial review of 92ace3a.
Round-3 resolution verdicts:
- F1 RESOLVED for the reported reproduction. The 100-byte old result + eight 2,000-grapheme CJK results + 1,990-byte newest result now returns 19,939 raw UTF-8 body bytes, not 50,005. The targeted regression passes.
- F2 RESOLVED.
_wouldCompactionOverflow()now assigns the array returned bytruncateToolResultBodies()before estimating it. The AgentSession harness regression passes with the request view truncated while the SessionManager entries still contain the full persisted body. - F3 RESOLVED for the exact eight-2,000-character CJK shape. The helper returns 19,938 raw body bytes; an actual synthetic Cursor HTTP/2/KV exchange using the production
stream()encoder measured 43,391 bytes of root/turn blobs and 45,065 bytes of client protobuf traffic, under 50,000. The 2.5 factor is conservative for that shape, but it is not conservative for the broader payload space (blocker 1). - B7 remains unresolved as an integration-test requirement (blocker 3).
New blockers:
-
The serialized-request budget is still not a bound for real Cursor payloads.
agent-session.ts:871-875budgets raw tool text/base64 atfloor(maxBytes / 2.5), but it does not account for JSON escaping or per-content-item protobuf overhead. Reproduction against the production Cursor encoder: one paired tool result with eight text parts of exactly 2,000 newline characters has only 16,000 raw bytes, so the helper makes no change, but the synthetic HTTP/2/KV capture sends 51,538 bytes of root/turn blobs and 53,232 bytes of client protobuf traffic. Eight 2,000-character NUL parts reach 115,538 and 117,232 bytes respectively because JSON escapes each NUL as\u0000. The CJK case passes because its raw bytes trigger truncation; escaped ASCII/control text bypasses the 20,000-byte threshold and exceeds the claimed 50,000-byte wire bound. The budget needs to be based on the actual serialized root/turn representation (including escaping and per-part/envelope overhead), or the transform must conservatively cover those costs. -
Marker reservation can increase the body and violate the aggregate cap. With 3,334 text parts of
abcdefghij, input is 33,340 raw bytes, buteffectiveMaxBytesbecomes zero (20,000 - 3,334 * 15) and every part is replaced by the 15-byte marker, producing 50,010 bytes. With 5,000 ten-byte parts, a 50,000-byte input becomes 75,000 bytes. The loop still appends a marker and incrementsusedBytesafter the effective budget is exhausted, so reserving marker space does not guarantee that markers fit. This violates the advertised 50,000-byte aggregate invariant and can also amplify the serialized payload. Marker insertion must be budgeted as a replacement and must never cause the transformed body to exceed the input/cap. -
B7 is still helper/seam-level rather than a real AgentSession integration regression. The new harness test instantiates AgentSession, but directly invokes
harness.agent.transformContext, manually appends the persistence entry, assignsagent.state.messages, and calls the private_wouldCompactionOverflow()viaany. The Cursor history assertion separately callsbuildCursorHistoryForTest()after calling the helper. No test runssession.prompt()/the Agent loop through the real provider admission, captures the actual Cursor blob exchange, or verifies queuedmessage_endpersistence ordering. Consequently the escaped-text and many-part failures above pass all 7 new tests. Add one real AgentSession run with a captured Cursor request and a persistence assertion, covering the failing shapes.
Other checks: npx vitest --run packages/coding-agent/test/suite/regressions/1043-cursor-toolresult-truncate.test.ts packages/coding-agent/test/suite/regressions/1009-cursor-payload-re-compaction.test.ts passed 8/8; npx vitest --run packages/ai/test/cursor-agent.test.ts passed 33/33; coding-agent build passed; LSP diagnostics and git diff --check are clean. The current PR diff also deletes the tracked .omo/init-deep.json; this is unrelated to the feature and should be restored or explicitly justified.
VERDICT: REQUEST_CHANGES
|
Round-4 blocker resolution (commit c837ee3):
Verification:
|
|
WORKING: review-1044-r5 - reproducing serialized-cost boundaries, adversarial content shapes, emptied-part/provider pairing behavior, and public AgentSession.prompt() coverage |
There was a problem hiding this comment.
Round-5 adversarial review of c837ee3.
Round-4 resolution verdicts
- N1: RESOLVED for the reported newline/NUL/CJK shapes, but the general bound is not resolved (fresh R5-1 below). Using the production Cursor
stream()encoder behind a local HTTP/2 blob server, the transformed eight-part cases measured: newline15,183client-wire bytes /13,257fetched blob bytes; NUL27,571/25,649; CJK12,074/10,158. All are below 50,000. The 16x model still does not establish a bound for arbitrary part cardinalities. - N2: RESOLVED for the exact 3,334 and 5,000 ten-byte-part reproductions. The unpaired cases measured
9,278/9,076and12,610/12,408client-wire/blob bytes respectively, and the joined transformed bodies did not exceed 50,000. A denser boundary shape is the fresh blocker below. - N3: RESOLVED.
.omo/init-deep.jsonis tracked at blob6fbc892c81ce2e7e71e310bf4acb4074b2b7aec1; there is no unrelated file diff againstorigin/main. - B7: RESOLVED for the requested public AgentSession/persistence regression. The test calls
harness.session.prompt()and lets the real Agent loop execute the registered tool; the provider callback observes the admitted context andSessionManager.getEntries()observes JSONL persistence. It does not invoke a private compaction method or manually append the tool result. An A/B run confirms the assertion is behavioral: with the installed transform the admitted body is 2,000 characters and persisted JSONL is the full 160,000-character body; after disabling the transform, admission contains all 160,000 characters while persistence remains full.
Fresh blocker
- R5-1 - the serialized-cost model is still not a conservative upper bound when empty content items are retained. I used one paired assistant tool call and a tool result containing 7,424 text parts, each
abcdefghij, then rantruncateToolResultBodies()and the production Cursorstream()encoder. The helper retained 223 non-empty parts and emitted 7,201 empty text parts after the marker stopped fitting. The fetched protobuf blob payload totaled 50,003 bytes (the corresponding decoded JSON history views totaled 110,971 bytes), and the client sent 50,439 wire bytes; the fetched payload and client traffic both exceed the claimed 50,000-byte bound. At 7,500 parts the corresponding measurements were 50,459 blob bytes and 50,904 client-wire bytes. The root cause is that an emptied part is still serialized bycreateCursorMcpResult()as a protobuf content item; the helper adds a nominal 64-byte cost for the empty replacement but does not enforce the cap once the marker no longer fits, and the actual framing/varint cost exceeds the assumed constant. This disproves that16 * raw bytes + 64is an upper bound, rather than merely a larger heuristic. Please make the transformed representation itself stay within the bound (including all retained empty-item envelopes), or use a Cursor-valid coalescing/omission policy that preserves the tool-call/result pair, and add a production-encoder regression at this boundary.
Additional adversarial checks
- A single 1,000,000-character text part was reduced to 2,000 characters and measured 4,546 fetched blob bytes / 4,980 client-wire bytes. Mixed CJK+NUL+newline+emoji, emoji-heavy, lone-surrogate-heavy, and 1,000-level nested JSON text all remained grapheme-safe and under the bound for their single-part forms; decoded history totals were 10,965, 6,823, 9,929, and 5,401 bytes respectively.
- Empty text parts do not orphan a paired call: the Cursor root history still emits one
role: toolentry, and the turn step still contains the tool-call result with the same ID. Empty image bytes also round-trip through the local protobuf encoder; 1,000 one-byte image parts produced 36,151 client-wire bytes / 35,724 blob bytes. I found no independently reproducible Cursor pairing or local provider-validation blocker, but the retained-item overhead is covered by R5-1.
Verification: coding-agent targeted regressions 1043 + 1009 passed 12/12; Cursor tests passed 33/33; coding-agent build passed; LSP diagnostics for the changed source/test files are clean; git diff --check is clean.
VERDICT: REQUEST_CHANGES
|
R5-1 resolved in f2d1408. The truncation pass now coalesces consecutive emptied text parts to one empty Cursor content-item placeholder. This preserves the toolResult message and toolCallId pairing, while preventing thousands of rejected parts from each adding a serialized envelope. Non-empty parts, images, markers, and separated empty runs remain unchanged. TDD evidence:
Gates: root build passed; root typecheck passed; static check passed (Biome, pinned deps, TS imports, shrinkwrap, install lock, Claude SDK platform lock, typecheck, browser smoke); changelog gate against origin/main passed; git diff --check passed. The full coding-agent suite had 1,106 passing tests and 18 pre-existing environment/infrastructure failures (stale ai dist before rebuild, occupied QA ports, and unrelated timeout cases); the affected regressions pass cleanly. |
|
WORKING: review-1044-r6 - verifying R5-1 with production Cursor wire encoding, coalescing edge cases, marker/envelope boundaries, adversarial mixtures, and provider pairing semantics |
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-6 adversarial review of f2d1408.
R5-1 verdict: RESOLVED for the reported boundary
I reproduced both reported shapes through the production Cursor HTTP/2 stream encoder behind a local blob server. After the coalescing transform:
- 7,424 ten-byte text parts: 6,784 fetched blob bytes / 7,182 client bytes.
- 7,500 ten-byte text parts: 6,784 fetched blob bytes / 7,182 client bytes.
- Each output retained 223 non-empty text parts and one empty text placeholder; the original
toolCallIdremained intact. - Cursor root history still emitted the paired
role: toolresult, and the conversation turn still contained the matching tool call/result ID.
The coalescing edge probes behaved as intended for text: emptied runs separated by non-empty text did not merge; empty/non-empty/empty alternation stayed separated; a single emptied part and an all-emptied result became one placeholder; a marker remained distinct from an emptied run; and an image between emptied text runs prevented coalescing. Local production decoding accepts a lone empty text item and preserves tool-use/result pairing. The 200 non-empty 200-byte parts plus 7,000 tiny parts mixtures stayed below the cap (6,709 and 6,665 blob bytes depending on order).
The focused regression file passes 13/13, the existing Cursor tests pass 33/33, and changed-file LSP diagnostics are clean.
Fresh blockers
-
R6-1 - image-heavy results still exceed the production wire cap because emptied image items are never coalesced or omitted. With one paired tool result containing 1,450 valid one-byte PNG image parts (
data: "AA=="), the transform retained all 1,450 content items: 390 images kept their data and 1,060 images were changed to empty data. The production Cursor capture measured 51,008 fetched blob bytes and 51,412 client bytes, both above the 50,000-byte bound. The direct history encoder crosses the cap at this boundary as well (1,423 parts measured 50,012 bytes). Coalescing only text fixes R5-1's exact text shape but does not establish the claimed aggregate bound when image content is present. Either use a Cursor-valid image omission/coalescing policy or budget the actual retained image envelopes so the transformed representation itself cannot exceed the cap. -
R6-2 - the aggregate model still omits per-message/turn envelope cost, so many small paired results exceed the cap without any part being truncated. I built 98 user/assistant-toolCall/toolResult turns, each result containing only a ten-byte text part. The helper considers all 98 results admissible (
98 * (10 * 16 + 64) = 21,952modeled bytes), but the production Cursor history encoder emits 50,066 fetched blob bytes and 71,962 client bytes. The direct history encoder reports 50,008 bytes; 97 otherwise-identical results report 49,497 bytes. This is a new cardinality boundary distinct from the R5 run: all parts remain non-empty, so text coalescing cannot help. The bound needs to charge the per-result/root/turn/tool-call envelopes and duplicated representations, or compute admission against the actual Cursor representation.
The exact R5-1 text regression is therefore green, but the advertised 50,000-byte production bound is not yet true for image cardinality or multiple paired results.
VERDICT: REQUEST_CHANGES
|
Round-6 blockers R6-1/R6-2 are fixed in commit
Wire-bound regression evidence:
Gates:
Pushed to |
|
WORKING: review-1044-r7 - adversarial wire-bound reproduction, envelope-charge stress probes, coalescing semantics, and final review submission |
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-7 adversarial review of commit 4dd0292.
R6 resolution verdicts
- R6-1: RESOLVED for the reported image-cardinality shape. Reproduced one paired result with 1,450
image/pngparts whose data isAA==throughbuildCursorHistoryWireBytesForTest: the unique Cursor history blobs were 54,134 bytes before transformation and 14,796 bytes after. The transformed result kept one empty image placeholder for the emptied run, retained pairing, and stayed below 50,000. - R6-2: RESOLVED for the reported multi-turn shape. Reproduced 98 user/assistant-toolCall/toolResult turns with ten-byte results: 50,008 bytes before and 49,326 bytes after; 67 results remained non-empty and 31 were emptied. The focused regression is 15/15, the related Cursor suite is 33/33, and diagnostics/static checks are clean.
Fresh blockers
-
R7-1 - the 512-byte envelope charge is not an upper bound for variable history metadata, so
changed: falsecan still produce a wire payload over the cap.serializedCost()charges only the text/base64 data and a fixed 64-byte content-item cost, while the new 512-byte charge is constant per result. It does not charge variabletoolName,toolCallId, imagemimeType, or the assistant tool-call arguments that are serialized in the same root/turn history. I reproduced this with an otherwise small paired result and a 15,000-character tool name: the direct Cursor encoder measured 60,456 bytes, buttruncateToolResultBodies()returnedchanged: falseand left it at 60,456. A more ordinary large tool-call argument has the same failure: a 25,000-character argument field measured 50,524 bytes and also returnedchanged: false. The admission model must either account for these encoded fields (including the non-result history that contributes to the same cap) or measure admission against the actual Cursor representation; a fixed 512-byte heuristic does not establish the advertised bound. -
R7-2 - the fixed charge is materially over-conservative and evicts fitting history. At the exact boundary of 68 paired turns with ten-byte results, the actual Cursor history is 34,678 bytes, leaving 15,322 bytes below the 50,000-byte cap, yet the transform changes the request and empties the oldest result. The model reaches this decision because it charges
68 * (512 + 16 * 10 + 64) = 50,048bytes. At 67 turns it is a no-op; at 68 it unnecessarily loses continuation context despite the wire representation fitting comfortably. This is not just a few bytes of safety margin and is a regression in retained context caused by the heuristic. Please derive the charge from the actual encoded incremental cost or otherwise avoid evicting results when the actual representation is demonstrably within the cap.
Other adversarial probes
- Mixed emptied image/text runs coalesce only across consecutive emptied parts; non-empty parts remain separators. Forced all-empty mixed runs retain one placeholder per run. The production protobuf encode/decode path accepts a lone empty image placeholder, preserves the tool call/result ID, and emits the paired root/turn structures, so I found no separate semantic blocker here.
- The exact 1,450-image and 98-turn wire-bound regressions pass after 4dd0292.
vitestpasses 48/48 for the focused coding-agent regression plus Cursor tests; LSP diagnostics, Biome, TypeScript noEmit, and diff-check are clean.
VERDICT: REQUEST_CHANGES
|
R7 blockers resolved in commit
Evidence:
|
|
WORKING: review-1044-r8 - inspecting the shared Cursor history encoder and admission transform before reproducing boundary and oversized-metadata cases. |
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-8 adversarial review of commit 641fe3b.
R7 resolution verdicts
- R7-1: RESOLVED for the reported active-user fixtures. Reproduced the 15,000-character tool-name and 25,000-character argument cases through the production
buildCursorHistoryWireBytesForTestbuilders with a trailing active user. The measured histories were 60,592 and 50,635 bytes before admission; the transform removed the oversized oldest complete turn, leaving 145 and 145 bytes respectively. The transformed production representations are within 50,000. - R7-2: RESOLVED for both requested boundaries. The 68-turn history measured 34,823 bytes and returned
changed: false; the 97-turn history measured 49,642 bytes and also returnedchanged: false. The focused regression file passes 19/19. - R5-1/R6-1/R6-2 interaction: RESOLVED for the existing ordinary
Messagefixtures. Empty text/image runs are coalesced in the eviction replacement before the nextfits()measurement; the 7,424/7,500-part, 1,450-image, and 98-turn regressions pass, and the Cursor package tests selected for the history builder pass.
Fresh blockers
-
R8-1 - admission measures the wrong history boundary on the normal resumed tool-result tail.
measureCursorHistorySerializedBytes()defaultsactiveUserMessageIndextofindLastUserMessageIndex(messages). In contrast, productionbuildGrpcRequest()usescontext.messages.length - 1and passes-1when the final message is a tool result, which is exactly the continuation state after a tool executes and before the next Cursor request. Therefore the helper excludes everything after the prior user message while production includes that assistant/tool-result tail.Reproduction:
[user, assistant(toolCall), toolResult]with a 15,000-character tool name measured 60,447 bytes with the production-1boundary but 0 bytes with the helper default;truncateToolResultBodies()returnedchanged: falseand production remained 60,447 bytes. The 25,000-character argument case was 50,490 bytes in production, measured as 0 by the helper, and also remained unchanged. With 98 ordinary turns and no trailing active user, production was 50,008 bytes while the helper saw 49,497 and returnedchanged: false. The active-user versions pass because their test-only boundary happens to match the default, but resumed Cursor admissions do not.This also answers the oversized metadata probe: with a trailing active user, the complete first turn is removed; in the reachable resumed-tail shape the wrong boundary bypasses that eviction and silently sends the over-limit metadata. A no-user/metadata-only input also reaches the
firstUser < 0break and returns an over-limit representation (60,200 bytes in a 60k tool-name + empty-result reproduction) rather than a hard error or a guaranteed fitting result. -
R8-2 - the measured input is not the same message domain that production encodes. The transform runs before
convertToLlm, buttruncateToolResultBodies()calls the CursorMessageencoder withresult as never. The builders only handleuser,assistant, andtoolResult; they ignorecustom,compactionSummary, andbashExecution, while coding-agent conversion maps those AgentMessage types into provider-visible user messages.Reproduction: a 60,000-character
compactionSummary(and equivalently a custom or bash message) before a paired tool call/result measured only 430 bytes in the helper, while the same context after the realconvertToLlmstep measured 120,561 bytes in the production history builders. The transform returnedchanged: false, so the actual Cursor history stayed over the 50,000-byte bound. This is common enough to matter after compact reloads becausebuildSessionContext()deliberately restores acompactionSummaryAgentMessage. The measurement must consume the exact converted context (including the actual active-user decision) or share a conversion-aware measurement seam. -
R8-3 - full serialization is repeated per eviction with no cache, producing quadratic admission latency.
fits()rebuilds and hashes the complete root/turn protobuf history, and the oldest-result loop calls it again after each candidate. On this Apple M4 Pro checkout, a single transform of paired 2,000-character tool results took 0.9s for 120 turns, 1.46s for 150, and 2.57s for 200; the 68/97 fitting cases were about 10ms. The 200-turn case is not an artificial measurement loop: it is one admission call that repeatedly serializes the entire history while evicting. SincetransformContextruns for every Cursor provider request, this can add seconds to normal large sessions and scales poorly. Use an incremental/cached or otherwise non-quadratic admission calculation while retaining the exact production encoder semantics.
Measurement-approach verdict
The lower-level history blob payload builders are shared with production: buildCursorHistoryWireBytesForTest() invokes the same buildRootPromptMessagesJson() and buildConversationTurns() functions used by buildGrpcRequest(), so there is no copy/paste drift for already-converted ordinary Message roles. However, the exported measurement sums isolated blob payload values only; production additionally sends the run-request/action, system-prompt blobs, KV response wrappers, and Connect framing. That is acceptable only if the contract is explicitly limited to the stored history blob payloads. It is not the complete client-wire byte count claimed by the broader comments. More importantly, R8-1 and R8-2 mean even the history blob payload being measured is not the production payload for resumed tails and converted AgentMessage types.
Verification
./node_modules/.bin/vitest --run packages/coding-agent/test/suite/regressions/1043-cursor-toolresult-truncate.test.ts: 19/19 passed../node_modules/.bin/vitest --run packages/coding-agent/test/suite/regressions/1043-cursor-toolresult-truncate.test.ts packages/coding-agent/test/suite/regressions/1009-cursor-payload-re-compaction.test.ts: 20/20 passed.npm --prefix packages/coding-agent run build: passed.- Changed-file LSP diagnostics and
git diff --check: clean. packages/ai/test/cursor-agent.test.ts: one unrelated/pre-existing heartbeat-only stream-health failure in the current checkout; the two targeted history-builder tests passed, and the AI package build passed.- GitHub still reports
mergeable=CONFLICTING/mergeStateStatus=DIRTY; this remains an independent landing blocker.
VERDICT: REQUEST_CHANGES
|
Round-8 blockers fixed in
Verification:
Pushed non-force to |
|
WORKING: review-1044-r9 - adversarial reproduction of R8 fixes, monotonic eviction, conversion/wire parity, mixed-ending boundaries, cache freshness, and bounded admission latency |
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-9 adversarial review of 07db910.
R8 resolution verdicts
-
R8-1: RESOLVED for the normal resumed tool-result admission.
truncateToolResultBodies()now uses-1whenever the converted context does not end in a user message, matchingbuildGrpcRequest(); a trailing converted user is excluded as the action. Reproduction with[user, assistant(toolCall), toolResult]and a 15,000-character tool name measured 60,451 bytes before admission, returnedchanged: true, and ended at 0 bytes after the metadata-only turn was correctly discarded. The mixed ending[...toolResult, user]preserved the last user as the action and retained/truncated the preceding tool result (40,469 -> 4,488 bytes), matching production boundary semantics. -
R8-2: RESOLVED for AgentMessage conversion coverage. Measurement now calls
convertToLlm(candidate), socustom,compactionSummary,branchSummary, andbashExecutionbecome provider-visible user messages before sizing. A 60,000-character compaction summary was counted in the production-sized history and the transform reduced the result to a fitting representation. The role-domain omission from R8 is fixed. Exact transport-conversion parity has a new issue below. -
R8-3: RESOLVED for the requested admission latency. The exact 200-turn paired-result fixture was measured five times at 65-118 ms per transform on this Apple M4 Pro checkout; the focused 1009+1043 regressions pass 23/23. The implementation performs fresh conversion/serialization for each
fits()candidate; I found no stale measurement cache across mutations.
Other adversarial probes
- For ordinary valid contexts with unique tool-call IDs, exhaustive empty-prefix probes across 36 varied cardinality/content cases were monotonic, and the binary result matched the fitting boundary in the tested cases. A deliberately malformed duplicate-tool-ID shape can make the deduplicated blob-size sequence non-monotonic (for example 331 -> 409 -> 243 bytes), causing over-eviction, but it did not produce an over-cap result and duplicate IDs already violate the provider transcript invariant.
- The no-user/metadata-only malformed shape still cannot be reduced below the bound when metadata itself is oversized (for example 60,102 bytes with only an assistant/tool-result pair). I am not counting that as a fresh normal-path blocker because Cursor admissions ordinarily contain a preceding user turn; it remains a limitation worth documenting or handling explicitly.
- Changed-file LSP diagnostics, root
tsc --noEmit, both package builds, targeted regressions, andgit diff --checkare clean. The standalonepackages/ai/test/cursor-agent.test.tsstill has the unrelated pre-existing heartbeat-only-stream failure (32/33).
Fresh blocker
-
R9-1 - admission measures a different conversion than the provider sends, so valid image settings can still exceed the 50,000-byte Cursor history bound. At
agent-session.ts:869-872, the helper measures the imported baseconvertToLlm(candidate). However, the real pipeline first runs thistransformContextand then invokes the agent's configured converter inagent-loop.ts:431-438; the coding-agent SDK configures that converter asconvertToLlmForTransport()(sdk.ts:377-398), which appliesimages.blockImagesandimages.maxHistoricalImages. The measured message array is therefore not byte-identical to the one passed to Cursor.Reproduction through the checked-out code: one paired result containing 708
image/pngparts (data: "AA==") separated by one-character text parts measures 33,746 bytes with the helper's raw conversion, sotruncateToolResultBodies()returnschanged: false. With the validimages.blockImages: truesetting, the actual agent conversion replaces every image withBLOCKED_IMAGE_PLACEHOLDER; the same Cursor history measures 50,030 bytes, and the AgentSession harness's post-transform provider context reproduced the >50,000 result. A second valid configuration is worse: withimages.maxHistoricalImages: 0, 708 tiny images in a completed historical tool result measure 30,361 bytes before the transport policy but 218,691 bytes afterconvertToLlmForTransport()replaces them with elision placeholders; the helper again reportschanged: false.This is a production under-limit admission bypass, not merely conservative over-eviction. The Cursor request receives the later
Context.messagesconversion, andbuildGrpcRequest()serializes that output, so the provider-visible history can exceed the exact bound this PR claims to enforce. Make the measurement use the same configured transport converter (including its image policy) and the same post-conversion active-user boundary, or move the policy into a shared conversion-aware measurement seam. Add a regression that runs the real AgentSession/buildProviderContext()path withblockImagesandmaxHistoricalImagesenabled and asserts the final Cursor history is <=50,000.
Please address R9-1 and rerun the production-converter regression before landing.
VERDICT: REQUEST_CHANGES
|
Resolved R9-1 in commit
Evidence:
|
|
WORKING: review-1044-r10 - inspecting R9-1 resolution and preparing reproduction passes |
code-yeongyu
left a comment
code-yeongyu
left a comment
There was a problem hiding this comment.
Round-10 adversarial review of PR #1044 at 17283162c7d95622dc183771c3f99a47ca710e27.
R9-1 resolution: VERIFIED
The measurement seam now receives the same configured this.agent.convertToLlm closure used by the production provider request. In this session that is convertToLlmForTransport, so measurement and active-user boundary detection see the live blockImages and maxHistoricalImages policies before Cursor history serialization.
I reproduced the two R9-1 shapes independently with paired tool calls/results and compared the post-admission converted context against the Cursor wire-history encoder:
blockImages: true, 708 tiny images interleaved with one-character text: pre-admission visible history was 50,015 bytes; admission changed the context, and the resulting measured history was 507 bytes, exactly equal to the provider-visible wire bytes and <= 50,000.maxHistoricalImages: 0, the same image payload in a completed historical result: pre-admission visible history was 227,943 bytes; admission changed the context, and the resulting measured history was 982 bytes, exactly equal to the provider-visible wire bytes and <= 50,000.- Additional
maxHistoricalImages: 1mixed-history probe across three paired turns: pre-admission visible history was 488,924 bytes; the result was 34,995 bytes, exactly equal to provider-visible bytes and <= 50,000. The newest completed-turn image set plus one historical image was retained as expected.
The focused R9-1 regression suite passes 24/24, including both requested policy regressions; the transport image suite passes 19/19. Related Cursor/compaction regressions pass 43/43. Coding-agent build and root TypeScript checking also pass.
Remaining findings
No new blockers. The named R9-1 blocker is verifiably resolved, and admission now measures through the same transport conversion path production uses rather than the base converter.
VERDICT: APPROVE
|
CI repair: re-exported measureCursorHistorySerializedBytes from @earendil-works/pi-ai's root entry point and updated agent-session.ts to use the root import, avoiding strict Terminal tools export-map resolution failure. Verified terminal suites 25/25, cursor regression 24/24, typecheck, AI/coding-agent builds, and changelog gate. |
|
Fixed the browser-smoke regression by removing the Node-only cursor-agent export from the root barrel, adding the explicit |
2 participants
Fixes #1043.
Problem
Cursor 0-token
resource_exhaustedsurvives compact because the last tool turn is kept verbatim (findCutPointcannot cut attoolResult). After compact,agent.state.messagesis replaced frombuildSessionContext(), which reloads those full jsonl bodies. The retry sends the same payload. A second compact often throwsNothing to compact (session too small).Mid-turn compact skip (#984) is still correct. Skipping compact is not enough: admission still ships megabyte tool logs.
Change
truncateToolResultBodies(2000 chars per toolResult text part).compactBeforeNextAdmissiontruncates before the Cursor compaction during a live turn poisons conversationId #984 skip return and remints when anything changed.sessionContext.messagesand in_restoreAgentMessagesFromSession.Test
packages/coding-agent/test/suite/regressions/1043-cursor-toolresult-truncate.test.ts— 4/4.Summary by cubic
Fixes Cursor retries re-sending megabyte
toolResultbodies after compact reload, which caused 0-tokenresource_exhausted. TruncatestoolResulttext and image payloads in memory for every Cursor provider request and during compaction sizing;jsonlhistory is unchanged and other providers are unaffected.@earendil-works/pi-ai./api/cursor-agentsubpath export.1043-cursor-toolresult-truncate.test.ts; updatesCHANGELOG.mdandchanges.md.Written for commit c428d99. Summary will update on new commits.