Bound trajectory pointer file read with size cap#110555
Conversation
|
Updated PR body with evidence and compatibility assessment. Branch rebased onto current main. @clawsweeper re-review |
|
Codex review: needs real behavior proof before merge. Reviewed July 18, 2026, 6:20 AM ET / 10:20 UTC. Summary PR surface: Source +7. Total +7 across 1 file. Reproducibility: no. high-confidence runtime reproduction was demonstrated in the PR. The source-level path is clear, but the review context lacks an inspectable live run showing normal and oversized pointer-file outcomes. 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
Maintainer decision needed
Security Review detailsBest possible solution: Keep one PR as the sole owner of the trajectory-pointer hardening, add redacted runtime proof for normal and oversized pointer files, and land only the selected focused change. Do we have a high-confidence way to reproduce the issue? No high-confidence runtime reproduction was demonstrated in the PR. The source-level path is clear, but the review context lacks an inspectable live run showing normal and oversized pointer-file outcomes. Is this the best way to solve the issue? Yes, reusing the shared bounded regular-file reader is the narrowest maintainable solution, provided the duplicate branch ownership is resolved and the fallback behavior is proven. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against cb785ed95b36. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +7. Total +7 across 1 file. 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 (4 earlier review cycles)
|
|
Fixed the P1 buffer destructuring issue: now correctly destructures { buffer } from readRegularFileSync before parsing. Branch rebased to current main. @clawsweeper re-review |
Behavior ProofCode Changes
Local Verification
Risk AssessmentThis change replaces an unbounded |
10cd690 to
8a59244
Compare
|
Branch rebased to latest main. @clawsweeper re-review |
… file read
readRegularFileSync returns { buffer, stat }, not a string.
The original code passed the raw object to JSON.parse, causing a
TS2345 type error and runtime failure. Destructure buffer and call
buffer.toString('utf8') to produce the string JSON.parse expects.
|
Superseded by PR #110516 which consolidates this bounded-read change alongside 4 other file-read fixes into a single landing candidate. |
What Problem This Solves
readTrajectoryPointerFile calls fs.readFileSync(pointerPath, "utf8") on session trajectory pointer files with no size limit. A corrupted or malicious pointer file can OOM the process during session cleanup.
Why This Change Was Made
PR #101472 established readRegularFileSync with maxBytes as the standard bounded-read primitive. This applies the same pattern to trajectory pointer files.
User Impact
No user-visible change. Trajectory pointer files are typically <1 KB. A 1 MB cap is more than sufficient. An oversized pointer file gracefully returns null.
Evidence
Code Change
src/trajectory/cleanup.ts — readTrajectoryPointerFile
Fix Applied
Provenance
Follows the same pattern as PR #101472 (merged) and PR #110516 (sibling PR).