Repository navigation
[Bug]: Large unstaged files cause excessive disk usage #1845
Description
Activity
I think I’m hitting the same underlying bug as #1845, but with a different repro on Linux desktop.
Environment:
- Linux
What I observed:
- T3 Code was repeatedly spawning:
- git --git-dir /home/michel/www/anon/.git fetch --quiet --no-tags origin
- git index-pack --stdin --fix-thin --keep=fetch-pack ...
- During those background fetches, new tmp_pack_* files appeared in:
- .git/objects/pack/
- The disk kept filling even while the machine was otherwise idle.
Impact:
- The repository’s .git directory grew to about 182 GiB.
- git count-objects -vH reported about 180 GiB of size-garbage.
- My root filesystem dropped to only a few GiB free.
Recovery: - Closing T3 Code stopped new tmp_pack_* files from appearing.
- Deleting the orphaned tmp_pack_* files recovered the space immediately.
- After cleanup, .git went back down to about 318 MiB and git count-objects -vH showed garbage: 0.
Important detail:
- This does not seem to require actively using the app once the repo is open.
- In my case it looked tied to automatic background Git fetches rather than only large unstaged files/checkpoints.
Possible workaround:
- In desktop settings, Source Control -> Automatic Git fetch interval -> set to 0 seconds.
Same problem here, but with no specific scenario where it happens, just opening the program and having it open will start burning disk writes for no reason.
Environment:
- Arch Linux
Installation done via AUR with Maria's package.
Before submitting
Area
apps/desktop
Steps to reproduce
Expected behavior
Unsure what the expected behaviour should be here given the current approach.
Option1: Removing unstaged files from the checkpoints will make it less robust but should address the disk space usage.
Option 2: Adding the large unstaged files to
.gitignoremeans they are not coming up in the suggestions when referencing them in the chat using@and cause readability issues for the agent.Actual behavior
Disk usage increases rapidly depending on the number and size of the unstaged files.
Running
git count-objects -vHis likely to show thatsize-packis reasonable, butsize-garbageis very large and increases over time as the number of checkpoints grows.That pattern usually means an interrupted or failed Git operation left temporary packfiles behind, typically from
git fetch,git gc,git repack, or clone/fetch maintenance.Impact
Minor bug or occasional failure
Version or commit
No response
Environment
MacOS 26.3.1
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
Either running
git gc --prune=nowor manually deleting.git/objects/pack/tmp_pack_*brings the disk usage down, but does not stop it from re-growing. The delete should happen when no othergitprocess if writing pack files. Runninggit fsckafterwards will confirm if the deletion left the repo in a valid state.