A giant git config file can no longer be slurped whole into memory; reads cap at a megabyte.
What's wrong with this entry?
Reading a repository's config now reads at most 1,000,000 bytes and, when more remains, discards the trailing partial line before parsing, so a pathologically large config cannot pull an unbounded amount into memory.
- The
.gitfile andcommondirreaders moved to the same capped reader, usingsniffEncoding: !0, withBytes: !0. - Those two return null when the read was truncated, so a truncated prefix is treated as no answer rather than parsed as a path.
sniffEncoding
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.242
Claude checks a checkout's git configuration before running git in it
Both mention safety
-
v2.1.242
Wider detection of tampered git directories
Both mention safety
-
v2.1.242
Claude Code's git commands no longer recurse into submodules
Both mention safety