Snapshot feature consumes 533GB+ of disk due to orphaned git temp files and unbounded growth

[Bewinxed]

Note

Automated bug report — This issue was filed by an AI coding agent (Claude Code) on behalf of @Bewinxed after diagnosing a disk space emergency. All data below was collected programmatically from the affected system.

Summary

The snapshot feature in ~/.local/share/opencode/snapshot/ consumed 533GB of disk space, filling a 1.1TB drive to 100% and causing system-wide issues. The root cause is a combination of:

1. Abandoned git gc temporary pack files (269GB in one snapshot alone)
2. Unbounded loose object accumulation in the global snapshot (264GB across 258 object directories)
3. No disk usage limits, monitoring, or cleanup beyond a weekly git gc --prune=7.days

Environment

• OpenCode version: 1.2.16
• OS: WSL2 (Ubuntu), kernel 6.6.87.2-microsoft-standard-WSL2
• Git: 2.43.0
• Disk: 1.1TB ext4 (was at 100%, now at 49% after manual cleanup)

Disk Usage Breakdown (Before Cleanup)

~/.local/share/opencode/snapshot/                     533G total
├── 0e0047b09bd609bdead33d952df5f2cf35d8207b/         270G  (project snapshot)
│   └── objects/pack/
│       ├── pack-331804b1...pack                       749M  (actual data, corrupted)
│       ├── tmp_pack_tK4eX9                            125G  ← abandoned gc temp file
│       ├── tmp_pack_mteked                             72G  ← abandoned gc temp file
│       └── tmp_pack_rAcec1                             72G  ← abandoned gc temp file
│   └── objects/79/                                    813M  (loose objects)
├── global/                                           264G  (global snapshot)
│   └── objects/pack/
│       └── tmp_pack_pjs4ru                             58G  ← abandoned gc temp file
│   └── objects/{56,57,64,82,94,a2,bb,cb,f0,...}/    ~1.3G each × 258 dirs
│                                                    (~206G of loose objects)
└── (5 other snapshots)                               ~92M  (normal size)

Root Cause Analysis

I traced this to the snapshot implementation in src/snapshot/index.ts. Several design issues contribute:

1. Failed git gc leaves massive temp files with no cleanup

The hourly git gc --prune=7.days scheduler can fail (e.g., out of disk space, process killed, OOM) and leave tmp_pack_* files in objects/pack/. These are never cleaned up. On my system, three abandoned temp files totaled 269GB in a single snapshot repo.

Suggested fix: Before running git gc, clean up any existing tmp_pack_* files in objects/pack/. Or add a pre-gc check like:

find "${gitdir}/objects/pack" -name 'tmp_pack_*' -mmin +60 -delete

2. global snapshot accumulates unbounded loose objects

The global snapshot had 258 object hash directories averaging 1.3GB each (~206GB of loose objects). Since write-tree creates tree objects without commits, and the index references them, git gc --prune=7.days may not actually prune them (they're technically reachable from the index).

Suggested fix: Periodically reset the snapshot index, or use git prune with more aggressive settings. Consider git gc --aggressive or manual git repack -a -d with pack size limits.

3. No disk usage limits or monitoring

There is no cap on snapshot storage. No check like "if snapshot dir exceeds N GB, purge old data." The only cleanup mechanism is the hourly git gc, which as shown above, can itself fail and worsen the problem.

Suggested fix: Add a configurable max size (e.g., snapshot.maxSize in config). Before each Snapshot.track(), check total size and aggressively prune or disable snapshots if the limit is exceeded.

4. No .gitignore-equivalent for the global snapshot

While git add . respects the project's .gitignore, the global snapshot doesn't have clear exclusion rules for large directories like ~/.cache/huggingface (92GB), ~/.cache/uv (31GB), etc. If the global snapshot's worktree covers the home directory, these all get tracked.

Steps to Reproduce

1. Use opencode on multiple projects for an extended period (days/weeks)
2. Have projects with large working trees
3. Let the hourly git gc scheduler run (and occasionally fail, e.g., due to disk pressure)
4. Check du -sh ~/.local/share/opencode/snapshot/

Workaround

# Nuclear option — delete all snapshots (loses undo history)
rm -rf ~/.local/share/opencode/snapshot/*

# Or disable snapshots entirely in .opencode.json
# { "snapshot": false }

Suggested Improvements

1. Clean up tmp_pack_* files before/after git gc runs
2. Add a total size cap with automatic pruning when exceeded
3. Add a startup health check that warns if snapshot storage exceeds a threshold
4. Use git commit-tree instead of orphaned write-tree so gc can properly manage object lifetime via commit reachability
5. Log snapshot storage size periodically so users can monitor growth
6. Consider using git gc --auto instead of unconditional git gc to let git decide when gc is needed

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The issue was explicitly filed by an AI agent on behalf of the user — AI-generated walls of text are not acceptable. Please rewrite this in your own words, keeping it concise and to the point.
• The issue does not use one of the required issue templates (Bug Report, Feature Request, or Question). Please re-submit using the Bug Report template with the required fields filled in.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• Snapshot system leaks tmp_pack_* files indefinitely, filling disk at ~9.5 GB/hour #14811: Snapshot system leaks tmp_pack_* files indefinitely, filling disk at ~9.5 GB/hour
• Snapshot tmp_pack files accumulate and fill disk when used in VSCode #15416: Snapshot tmp_pack files accumulate and fill disk when used in VSCode
• [BUG] tmp_pack Files Consuming 180GB on Ubuntu 24.04 LTS #8749: tmp_pack Files Consuming 180GB on Ubuntu 24.04 LTS
• [ROOT CAUSE ANALYSIS] tmp_pack Leak - Complete Code Analysis & Fix Recommendations #10034: [ROOT CAUSE ANALYSIS] tmp_pack Leak - Complete Code Analysis & Fix Recommendations
• [BUG] Ubuntu 22.04 Temp_Pack Files Using All of the Storage #5617: Ubuntu 22.04 Temp_Pack Files Using All of the Storage

If you believe this was flagged incorrectly, please let a maintainer know.

[Bewinxed]

Closing as duplicate of #14811 — same root cause (tmp_pack leak in snapshot git repos). Adding our data point there instead.