[Bug]: Large unstaged files cause excessive disk usage

[nikolaloncar]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Start the app
2. Open a git project folder
3. Add a large unstaged file to the project
4. Start a thread which generates many steps / checkpoints

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 .gitignore means 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 -vH is likely to show that size-pack is reasonable, but size-garbage is 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=now or 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 other git process if writing pack files. Running git fsck afterwards will confirm if the deletion left the repo in a valid state.