{"version":"2.1.281","anchor":"worktree-tamper-verification-reads-commits-through-a-structu","canonical_anchor":"worktree-tamper-verification-reads-commits-through-a-structu","heading":"Worktree tamper verification reads commits through a structured reader","tier":null,"area":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/worktree-tamper-verification-reads-commits-through-a-structu","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Worktree tamper verification reads commits through a structured reader\n\nWorktree tamper checks now read commits directly and report \"unverified\" instead of \"none\" when a commit cannot be read\n\n**Unclear.** The finding does not say where the \"unverified\" result is shown to a reader.\n\n**What**\n\nA worktree is a separate working copy of a git repository. When Claude Code works out the changes made in one, it also checks that the commit history has not been tampered with. That check now reads the commit, its parent commits and its file trees through a dedicated reader. Before, it relied on `git rev-parse` calls. The reader gives one of three reasons when it fails:\n\n- missing\n\n- unreadable\n\n- tampered\n\nIf a commit cannot be read, the result is now \"unverified\" instead of \"none\".\n\n**Why**\n\n\"None\" could suggest that nothing was wrong. \"Unverified\" says plainly that the check could not be done, so a commit that cannot be read is no longer treated as a clean one."}