CC silently replaces on-disk binary at unchanged version string, defeating tweakcc and other patchers

Resolved 💬 3 comments Opened Apr 23, 2026 by thebestmensch Closed Apr 27, 2026

Summary

Claude Code appears to silently replace the on-disk binary at ~/.local/share/claude/versions/<version> on launch/update, even when the version string is unchanged. This quietly reverts any third-party binary patches (e.g. tweakcc) without any observable signal — same filename, same version, zero patches.

Observed behavior

  1. Ran tweakcc --apply against CC 2.1.111 — patches landed (verified via grep for injected RGB values and the tweakcc v4.0.11 marker string).
  2. Restarted Ghostty + launched a fresh CC session.
  3. Theming regressed (themes + user-message-display both gone).
  4. Inspected binary at /Users/jm/.local/share/claude/versions/2.1.111 — file was still there, version was still 2.1.111, but:
  • grep -ac 'tweakcc' <binary>0
  • No spenschsuite theme block, no injected RGB values
  • Default orange rgb(215,119,87) present (shipping default)
  1. Re-running tweakcc --apply against the same version re-patched successfully.

So the binary at 2.1.111 was replaced by a different binary also reporting 2.1.111.

Impact

  • Tools patching the CC binary (tweakcc and similar) can be reverted without any observable change to the version symlink or CC CLI --version output.
  • A drift-detection hook that only compares version strings cannot catch this. Only a content check (e.g. grepping for an injected marker) works.
  • Users experience silent UI regressions after Ghostty/terminal restarts or system sleep — no upgrade prompt, no changelog, no signal.

Suggested remediation

Either:

  1. Don't silently replace same-version binaries on disk. If versions/2.1.111 already exists and matches its expected checksum, leave it alone.
  2. If replacement is intentional (e.g. hotfix at same version), bump the patch or build ID so the symlink target changes, allowing drift-detection hooks and patchers to notice.
  3. Expose a "frozen binary" flag (env var or settings.json) that disables on-launch binary replacement for users who patch their local install.

Environment

  • macOS (Darwin 25.4.0, arm64)
  • Claude Code 2.1.111 installed at ~/.local/share/claude/versions/2.1.111 (Mach-O binary, ~200MB)
  • tweakcc v4.0.11
  • Observed 2026-04-22 → 2026-04-23

Workaround

Added a SessionStart hook that greps the live binary for the tweakcc marker string and warns the user if it's missing:

if ! LANG=C grep -aq 'tweakcc' "\$live_binary"; then
  echo "⚠ binary was replaced — run tweakcc --apply"
fi

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗