Snapshot system leaks tmp_pack_* files indefinitely, filling disk at ~9.5 GB/hour #14811

Activity

1. ChrisMares

   added

   bugSomething isn't workingSomething isn't working

   on Feb 23, 2026
2. github-actions commented on Feb 23, 2026

   

   github-actionsBot

   on Feb 23, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [BUG] tmp_pack Files Consuming 180GB on Ubuntu 24.04 LTS #8749: [BUG] tmp_pack Files Consuming 180GB on Ubuntu 24.04 LTS
   • [BUG] Ubuntu 22.04 Temp_Pack Files Using All of the Storage #5617: [BUG] Ubuntu 22.04 Temp_Pack Files Using All of the Storage
   • Opencode using up 380GB in ~/.local/share/opencode/snapshot/objects #9601: Opencode using up 380GB in ~/.local/share/opencode/snapshot/objects
   • OpenCode nuked my storage (318 GB added) #9290: OpenCode nuked my storage (318 GB added)
   • Opencode using my 20 GB storage #10532: Opencode using my 20 GB storage
   • [ROOT CAUSE ANALYSIS] tmp_pack Leak - Complete Code Analysis & Fix Recommendations #10034: [ROOT CAUSE ANALYSIS] tmp_pack Leak - Complete Code Analysis & Fix Recommendations

   These issues describe the same tmp_pack file accumulation problem in the snapshot system. Please review them and consider adding your findings there instead, or confirm if your issue represents a distinct case.
3. github-actions

   assigned

   thdxr

   on Feb 23, 2026
4. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   perfIndicates a performance issue or need for optimizationIndicates a performance issue or need for optimization

   on Feb 23, 2026
5. amansingh107 commented on Feb 23, 2026

   

   amansingh107

   on Feb 23, 2026

   More actions

   I think i know why this is happening
   1.Failed Snapshots: Every time you interact with the AI, OpenCode tries to snapshot your workspace. If your project is large (or if you accidentally run it in your home directory), these operations can hang.

   2.Orphaned Files: When the process hangs or is killed, it leaves those tmp_pack_... files in your .local/share/opencode/.../objects/pack folder.

   3.No Auto-Cleanup: The current version of OpenCode (as of early 2026) doesn't have a built-in mechanism to delete these temporary files automatically once they've failed.
6. Bewinxed commented on Mar 4, 2026

   

   Bewinxed

   on Mar 4, 2026

   More actions

   Hit this on v1.2.16 — 533GB consumed on a 1.1TB disk (filled to 100%).

   Breakdown of the snapshot dir before cleanup:

   • Project snapshot (0e0047...): 270GB total — three abandoned tmp_pack_* files (125G + 72G + 72G) plus a corrupted 749M pack file
   • global snapshot: 264GB total — one 58G tmp_pack_* file plus ~206GB of loose objects across 258 hash directories (averaging 1.3GB each)
   • 5 other snapshots: ~92MB combined (normal)

   The loose object accumulation in global seems like a separate-but-related issue — write-tree creates tree objects that stay reachable from the index, so git gc --prune=7.days can't actually prune them. On top of that, when gc does try to repack, it fails (likely OOM or disk pressure) and leaves the tmp_pack_* files behind, compounding the problem.

   WSL2 Ubuntu, git 2.43.0. Fix was rm -rf ~/.local/share/opencode/snapshot/* — freed 533GB instantly.
7. rothnic commented on Mar 9, 2026

   

   rothnic

   on Mar 9, 2026

   Last edited by rothnic

   More actions

   I just found this issue after hitting 100% disk usage, causing opencode to crash. Found the same snapshot folder taking up 163GB of space for me. What is the solution to handling this safely for now? Between this and the memory leak issues, I'm struggling to use opencode for any length of time without running into performance issues.

   I had 120GB if tmp_* files. There are a bunch of pak files that i'm not sure what they are for and the downside of removing them. Most are ~40MB or less, but one is 40GB. Removing the tmp files at least cleaned things up for a bit.

   👍React with 👍2Reacted by OverHash and James Burdge
8. Git-on-my-level commented on Mar 18, 2026

   

   Git-on-my-level

   on Mar 18, 2026

   More actions

   Confirming this on macOS with a local reproduction and concrete cleanup numbers.

   Environment

   • OS: macOS
   • State dir: ~/.local/share/opencode

   What I found locally

   • ~/.local/share/opencode had grown to 45G
   • snapshot/ was 40G
   • one snapshot dir dominated all usage:
     • ~/.local/share/opencode/snapshot/01adec10548001d548c6d7c392e733d8e7535c65 = 40G
   • inside that snapshot:
     • objects/pack/ = 39G
   • of that, tmp_pack_* files alone accounted for about 19.4 GiB

   Examples from that directory:

   • tmp_pack_MzfB9A = 15G
   • tmp_pack_HzAeAw = 2.9G
   • tmp_pack_LAQ6cW = 912M

   Important detail

   • these files were not open by any process when I inspected the snapshot dir itself
   • deleting only the tmp_pack_* files reclaimed about 19-20 GiB immediately
   • the containing snapshot dropped from 40G to 20G
   • free space on the data volume jumped from about 8.5 GiB to 28 GiB

   This strongly suggests abandoned/incomplete git repack artifacts are being left behind without cleanup/rollback/GC.

   I also had stale leaked .opencode serve processes from a separate test issue keeping opencode.db open, but those do not explain the tmp_pack_* accumulation itself.

   👍React with 👍1Reacted by David Zhang
9. thdxr commented on Mar 25, 2026

   

   thdxr

   on Mar 25, 2026

   Member

   More actions

   This should be partially addressed by commit 0a80ef4 which adds a 2MB file size limit for snapshotting. Large files are now excluded from snapshots, reducing tmp_pack accumulation from large files.
10. thdxr

    closed this as completedon Mar 25, 2026
11. arthurjd commented on Aug 29, 2026

    

    arthurjd

    on Aug 29, 2026

    More actions

    A fix for this is now available in PR #46037: it prunes stale tmp_pack_* files after every snapshot gc run (success or failure) and rebuilds the snapshot store when gc fails on missing objects (the deterministic unable to read mode when the project's own gc prunes shared objects). Details and a reproducer in #46034.