Rules / Format and vendor rules

nul-bytes

File contains NUL bytes.

warning by default Format and vendor rules Inline suppression allowed

Source: git docs: gitattributes (git-scm.com), read 14 October 2026.

On GitHub: the rule doc and the tests.

All rules73

What it catches#

File contains NUL bytes.

One or more 00 bytes in the file. Text never contains NUL; it shows up when a binary is misnamed .md, when a UTF-16 file is read as UTF-8, or when a crash or a bad merge left padding behind.

Why it matters#

A NUL byte usually means a binary or wrongly encoded file, and many tools stop reading at it.

Bad example#

$ xxd .cursorrules | tail -2
00000a40: 2074 6865 2074 6573 7473 2e0a 0000 0000   the tests.......
00000a50: 0000 0000 0000 0000 0000 0000 0000 0000  ................

An editor crash truncated the file and the filesystem filled the rest with zeros. Many tools stop reading at the first NUL; some refuse the file as binary.

Good example#

$ xxd .cursorrules | tail -1
00000a40: 2074 6865 2074 6573 7473 2e0a             the tests..

How to fix#

Check what the file is with file CLAUDE.md. If it is UTF-16, see encoding. If it is text with trailing zeros, restore it from git (git checkout -- CLAUDE.md) or delete the padding and re-save.

Suppress or configure#

For one finding, put a comment on the line above it. The reason after -- is optional but worth writing:

<!-- asitis-disable-next-line nul-bytes -- why this one is fine -->

For a whole file:

<!-- asitis-disable-file nul-bytes -- why this file is an exception -->

For every file, turn it off or change its severity in .asitisrc.json:

{ "rules": { "nul-bytes": "off" } }

A .asitisrc.json overrides entry limits a change to some paths, and a baseline (asitis lint --format json --write-baseline) accepts today's findings so only new ones fail the build.

Source#

git docs: gitattributes, read on 14 October 2026.

This page is generated from the plugin's rule registry. Edit it on GitHub. False positive? Open an issue with the line it fired on.