{"version":"2.1.281","anchor":"null-byte-path-check-moved-into-a-shared-nullbytepatherror-h","canonical_anchor":"null-byte-path-check-moved-into-a-shared-nullbytepatherror-h","heading":"Null-byte path check moved into a shared NullBytePathError helper","tier":"internal","area":"File Access","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/null-byte-path-check-moved-into-a-shared-nullbytepatherror-h","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Null-byte path check moved into a shared NullBytePathError helper\n\nFile paths containing a null byte are now rejected by permission-rule path handling too, with a dedicated `NullBytePathError`\n\n**What**\n\nA null byte is an invisible \"empty\" character that should never appear inside a file path. Claude Code already refused such paths when it worked out where a file is. Now there is a single shared check that raises a specific error named `NullBytePathError`, and three places use it:\n\n- the code that works out a file's location\n\n- two parts of the code that tidy up file paths inside permission rules (the rules that say which files Claude Code may touch)\n\nThere is also a new variant of the check that quietly returns nothing instead of raising an error.\n\n**Why**\n\nBefore this change, only the file-location code checked for null bytes. Now the permission-rule path handling also refuses these malformed paths, and they all produce one clearly named error.\n\n- Area: File Access\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 0\/5"}