Description
The daemon enumerates untracked files in a git repo via git ls-files --others --exclude-standard, then runs git diff --no-index --numstat -- /dev/null <file> for every untracked file simultaneously. For large binary files, each git diff reads the entire file and hammers the CPU -- and the daemon spawns one per file in parallel.
Example scenario
A user accidentally ran git init in their home directory (or any directory containing large binaries). If that directory also contains multi-GB files like GGUF model weights, VM images, database dumps, etc., the daemon will launch dozens of git diff processes, each reading an entire multi-gigabyte file and pegging a CPU core. The result is a fully saturated machine that is unresponsive until the daemon is killed.
This is a general problem: any git repo watched by the daemon that contains large untracked binary files triggers the same behavior. A .gitignore entry works around it, but users should not have to know to add one preemptively to avoid a CPU storm.
Suggested fixes
The daemon should at minimum:
- Skip
git diff --no-index on files above a reasonable size threshold
- Skip known binary extensions (
.gguf, .bin, .safetensors, .iso, .qcow2, etc.)
- Throttle concurrent diff operations
- Or respect
.gitattributes binary markers
Environment
- OS: Ubuntu on WSL2 (Linux 5.15)
- Version: latest as of 2026-06-09
Description
The daemon enumerates untracked files in a git repo via
git ls-files --others --exclude-standard, then runsgit diff --no-index --numstat -- /dev/null <file>for every untracked file simultaneously. For large binary files, eachgit diffreads the entire file and hammers the CPU -- and the daemon spawns one per file in parallel.Example scenario
A user accidentally ran
git initin their home directory (or any directory containing large binaries). If that directory also contains multi-GB files like GGUF model weights, VM images, database dumps, etc., the daemon will launch dozens ofgit diffprocesses, each reading an entire multi-gigabyte file and pegging a CPU core. The result is a fully saturated machine that is unresponsive until the daemon is killed.This is a general problem: any git repo watched by the daemon that contains large untracked binary files triggers the same behavior. A
.gitignoreentry works around it, but users should not have to know to add one preemptively to avoid a CPU storm.Suggested fixes
The daemon should at minimum:
git diff --no-indexon files above a reasonable size threshold.gguf,.bin,.safetensors,.iso,.qcow2, etc.).gitattributesbinary markersEnvironment