fix(opencode): preserve Unicode in catalog tool input#109591
Conversation
24db632 to
e29f737
Compare
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Codex review: needs real behavior proof before merge. Reviewed July 17, 2026, 12:06 AM ET / 04:06 UTC. Summary PR surface: Source +1, Tests +20. Total +21 across 2 files. Reproducibility: yes. at the source level. The production-reader probe demonstrates how raw slicing splits the surrogate pair at the exact 20,000-code-unit boundary, although it uses a controlled OpenCode payload. Review metrics: none identified. Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Keep the shared UTF-16-safe helper change and regression test, then add a redacted terminal transcript from an actual OpenCode session or export whose long tool input crosses the 20,000-code-unit boundary and shows valid catalog output. Do we have a high-confidence way to reproduce the issue? Yes at the source level. The production-reader probe demonstrates how raw slicing splits the surrogate pair at the exact 20,000-code-unit boundary, although it uses a controlled OpenCode payload. Is this the best way to solve the issue? Yes. Reusing the existing Plugin SDK UTF-16-safe truncation helper at the serialization boundary is the narrowest maintainable fix; duplicating surrogate logic locally or changing the catalog limit would be inferior. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 135aa7a0025d. Label changesLabel justifications:
Evidence reviewedPR surface: Source +1, Tests +20. Total +21 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
|
Merged via squash.
|
Co-authored-by: Peter Steinberger <[email protected]>
2 participants
What Problem This Solves
Fixes an issue where users viewing an OpenCode session catalog could receive malformed Unicode in long tool input when the 20,000-character display limit landed inside an emoji's UTF-16 surrogate pair.
Why This Change Was Made
The catalog now uses the existing UTF-16-safe truncation helper before appending its ellipsis. This changes only the over-limit boundary; CLI invocation, parsing, limits, and paging remain unchanged. The main risk is altering catalog text length by one code unit at a split pair, covered through the production reader and its real child-process boundary.
User Impact
Long OpenCode tool input retains valid Unicode at the catalog boundary instead of producing a replacement character when encoded for transport or display.
Evidence
I ran the same throwaway TypeScript probe against the real exported
readLocalOpenCodeTranscriptPagefunction. It spawned a real child process at the OpenCode CLI seam, returned the official export JSON shape, and placed🎉across code-unit positions 19,999–20,000 in tool input; only the upstream CLI response was controlled.Before the fix, with the production truncation line restored to
slice(0, maxLength):After the fix:
Focused regression suite after rebasing onto current
upstream/main:Targeted
oxfmt --check,oxlint, andgit diff --checkpassed. Full repository gates are left to fork CI. I did not use a persistent live OpenCode session; the proof drives the production child-process invocation, export parser, transcript mapper, and catalog output, while controlling only the CLI payload needed to place the exact boundary.AI-assisted: Codex helped implement and review the change; the behavior proof and tests above were run manually.