{"version":"2.1.295","anchor":"git-file-linkage-check-no-longer-requires-a-link-count-of-1","canonical_anchor":"git-file-linkage-check-no-longer-requires-a-link-count-of-1","heading":"Hard-linked .git files are no longer rejected on link count alone","tier":"notice","area":"Git","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.295\/e\/git-file-linkage-check-no-longer-requires-a-link-count-of-1","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.295","markdown":"### Hard-linked .git files are no longer rejected on link count alone\n\nA `.git` file with more than one hard link is no longer refused just for that when Claude Code checks it\n\n**Unclear.** It is not clear whether the new check still refuses a hard-linked `.git` file in some other way.\n\n**What**\n\nIn some projects `.git` is a small file that points to where git keeps its data, rather than a folder. Claude Code checks this file in some git operations, such as building a bundle (a packed copy of a repository) or moving a session elsewhere. It used to refuse the file if it had more than one hard link, meaning the same file appeared under more than one name on disk. That rule is gone. The file is now read in a way that requires it to be reached under one name.\n\n**Why**\n\nThis is a security check, and it now uses a different test than before. A `.git` file that is hard-linked is no longer refused on the link count alone.\n\n- Area: Git\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}