Summary
Current dev rewrites a valid opaque Cursor call ID when it happens to look like output from the new reserved-prefix escape namespace introduced by #2868.
Current-dev reproduction
Current dev: 8d1dc1f
Introduced on dev by: 93b5507 (#2868)
decodeCursorCallId("ocxc1e_b2N4YzFf") === "ocxc1_"
The input contains no CR or LF and is a valid opaque upstream ID. Its payload decodes to the reserved text ocxc1_, so decodeCursorCallId treats it as locally emitted escape data and changes the ID. That can break tool-call/result pairing in request-builder and protobuf continuation paths.
The current test covers ocxc1e_Y2FsbF8x, whose payload decodes to non-reserved call_1, but not the marker-shaped payload above. The focused codec suite therefore stays green while this identity loss remains.
Root boundary
A second public stateless prefix does not remove the ambiguity: arbitrary upstream text can equal any value the encoder emits. The decoder needs provenance proving that this process/session emitted the escape value, or another design that does not guess from attacker- or provider-controlled opaque text alone.
Acceptance criteria
- The exact opaque input ocxc1e_b2N4YzFf remains byte-for-byte unchanged without local provenance.
- A freshly escaped ocxc1_- or ocxc1e_-prefixed ID still round-trips in the live tool-result continuation.
- Missing-provenance and process-restart behavior is explicit and covered; it must not silently rewrite an opaque ID.
- Request-builder and protobuf-request coverage proves call/result identity, not only the codec helper.
- The fix remains bounded in memory/lifetime if it uses a session-scoped mapping.
This is a follow-up to the post-merge exact-head review on #2868; #2864/#2868 should remain historical rather than being reopened.
Summary
Current dev rewrites a valid opaque Cursor call ID when it happens to look like output from the new reserved-prefix escape namespace introduced by #2868.
Current-dev reproduction
Current dev: 8d1dc1f
Introduced on dev by: 93b5507 (#2868)
The input contains no CR or LF and is a valid opaque upstream ID. Its payload decodes to the reserved text ocxc1_, so decodeCursorCallId treats it as locally emitted escape data and changes the ID. That can break tool-call/result pairing in request-builder and protobuf continuation paths.
The current test covers ocxc1e_Y2FsbF8x, whose payload decodes to non-reserved call_1, but not the marker-shaped payload above. The focused codec suite therefore stays green while this identity loss remains.
Root boundary
A second public stateless prefix does not remove the ambiguity: arbitrary upstream text can equal any value the encoder emits. The decoder needs provenance proving that this process/session emitted the escape value, or another design that does not guess from attacker- or provider-controlled opaque text alone.
Acceptance criteria
This is a follow-up to the post-merge exact-head review on #2868; #2864/#2868 should remain historical rather than being reopened.