v0.6.0 — never move a pristine byte

Claude Code 2.1.269 moved to Bun 1.4.3, which chains two more records after the module table. patch-cc 0.5.x walked that chain with a whitelist of the records it knew, and refused the build outright (offsets flags 0x1bff carry record bits 0x1800 this code does not know). This release fixes that build, and fixes the class: the write no longer needs to know Bun's records at all.

What changed

• The write never moves a pristine byte. Each edited module's text is appended after the arena and its stale bytecode is unlinked; everything else — the module table, Bun's records, whatever a future Bun adds — is copied where it was, and only the pointers that name what changed are re-aimed. The record walker, its whitelist and the compaction are gone.
• Verification is byte-for-byte against the pristine blob, allowing exactly the intended edits and enumerating nothing, so a record patch-cc has never parsed is covered by the same comparison as one it has.
• A patched binary is now a few percent larger than the original, not smaller (2.1.269: 220 → 229 MB). The size win was what bought the fragility. The apply report, the menu and patch-cc status say so plainly, and status reports the bytecode the module table names.

Compatibility

Transparent. Every held build from 2.1.210 to 2.1.269 patches with the same per-patch results as before. If Claude auto-updated you onto 2.1.269 and patch-cc refused it, upgrade and re-bake (patch-cc apply --from-cache, or re-run the menu). macOS is no longer the odd one out: growing a segment is the only thing the write asks of either container.

Validated

patch-cc doctor bakes and boots all 51 corpus builds, 2.1.210 → 2.1.269; every tail record on every build was checked to point into the arena; a real 2.1.269 apply boots, answers a turn, and runs its edited modules from inside Bun 1.4.3's pre-linked graph.

uvx patch-cc            # or: uv tool install patch-cc && patch-cc