Massive memory use on opening opencode when there is a very large file #2585

Activity

1. github-actions commented on Sep 13, 2025

   

   github-actionsBot

   on Sep 13, 2025 – with GitHub Actions

   Contributor

   More actions

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

   • Hangs if there is a multi gb .tar.gz file in current directory #683: Hangs if there is a multi gb .tar.gz file in current directory - similar issue with large files causing hangs
   • Session grew to 88G! #1126: Session grew to 88G! - another case of extreme memory usage
   • Running opencode causes a git diff that consumes all memory #2262: Running opencode causes a git diff that consumes all memory - similar memory consumption issue resolved by removing large files
   • URGENT - "MEM LEAK", eats up gigabytes of ram until system crash #804: URGENT - "MEM LEAK", eats up gigabytes of ram until system crash - memory leak issue with large files

   Feel free to ignore if none of these address your specific case.
2. rekram1-node

   assigned

   thdxr

   on Sep 13, 2025
3. rekram1-node commented on Sep 13, 2025

   

   rekram1-node

   on Sep 13, 2025

   Contributor

   More actions

   good to know thx for raising
4. zelenkovsky commented on Sep 22, 2025

   

   zelenkovsky

   on Sep 22, 2025

   More actions

   In my case, it's 72GB of memory that got committed right after start (for other repository it's 93GB):

   
5. rekram1-node commented on Sep 22, 2025

   

   rekram1-node

   on Sep 22, 2025

   Contributor

   More actions

   @zelenkovsky can you tell me more about where you are running opencode is this a massive project or something?
6. zelenkovsky commented on Sep 24, 2025

   

   zelenkovsky

   on Sep 24, 2025

   Last edited by zelenkovsky

   More actions

   @rekram1-node, aha, very interesting thing. If my working folder has a backup subfolder with large .tar.gz files, the opencode executable starts to grow in size (virtual memory) and gets killed by the OOM Killer.

   Is there anything special in backup or tar.gz handling?

   That happens on application startup. I did not even enter anything.
7. zelenkovsky commented on Sep 24, 2025

   

   zelenkovsky

   on Sep 24, 2025

   More actions

   Actually, backup has nothing to do with it; it's large tar.gz files located anywhere in the project folder.
8. zelenkovsky commented on Sep 24, 2025

   

   zelenkovsky

   on Sep 24, 2025

   More actions

   Analysis Summary

   I've identified the root cause of the high virtual memory consumption when large .tar.gz files are present in your working directory. Here's what happens during opencode startup:

   Primary Issue: File Tree Generation at Startup

   1. Location: packages/opencode/src/session/system.ts:47-50
   2. Function: SystemPrompt.environment() calls Ripgrep.tree() during initialization
   3. Process: This scans ALL files in your project directory to build a project tree structure that gets included in the system prompt

   The Problem Chain:

   1. File Scanning: Ripgrep.tree() → Ripgrep.files() → ripgrep binary with --files flag
   2. No Archive Filtering: The default ignore patterns in FileIgnore don't include common archive extensions like *.tar.gz, *.zip, *.tar, etc.
   3. Memory Allocation: When ripgrep encounters large files (even if it's just listing them), it can cause memory allocation issues, especially with compressed archives
   4. Startup Execution: This happens before any conversation starts, during the system prompt preparation

   Evidence from Code:

   • src/session/system.ts:47-50: Calls Ripgrep.tree() with limit of 200 files during environment setup
   • src/file/ignore.ts: Missing patterns for archive files (*.tar.gz, *.zip, *.tar, *.7z, etc.)
   • src/file/ripgrep.ts:206-220: The files() function uses ripgrep's --files flag which scans the entire directory

   Verification Checklist: ✅ Verified: File scanning occurs at startup via SystemPrompt.environment() ✅ Verified: No archive file patterns in default ignore list ✅ Verified: Ripgrep.files() scans
   entire directory structure ❓ Inferred: Large archive files cause memory allocation during scanning

   Next Steps to Confirm: You could verify this by temporarily moving your .tar.gz files out of the working directory and checking if the memory usage drops during opencode startup.

   The fix would involve adding archive file patterns to the default ignore list in src/file/ignore.ts.
9. ofriw commented on Sep 28, 2025

   

   ofriw

   on Sep 28, 2025

   More actions

   Before trying out opencode, I had been experimenting which chunkhound, that indexes your source folder to allow searching later. It stores its database file(s) in the .chunkhound folder, and in my project that folder was around 27GB in size.

   It seems like opencode was trying to load the files in that folder, because when I ran opencode the memory usage would shoot up, and opencode was using 29GB of RAM, and my computer was getting very slow.

   Deleting that folder solved the problem. Unfortunately I didn't check what the sizes and filetypes of files in that folder were before I deleted it.

   Author of ChunkHound here. As a workaround, you can place the db file outside of your code's dir using the --db flag. See https://chunkhound.github.io/configuration/#database-options
10. IlyaMaksheev commented on Oct 2, 2025

    

    IlyaMaksheev

    on Oct 2, 2025

    More actions

    I also experience same issue with .parquet files.
11. scarf005 commented on Dec 25, 2025

    

    scarf005

    on Dec 25, 2025

    Contributor

    More actions

    hi @rekram1-node, could #2761 be taken a look? also getting 17GiB ram usage on repository with lots of image files
12. SPOOKEXE commented on Jan 5, 2026

    

    SPOOKEXE

    on Jan 5, 2026

    Last edited by SPOOKEXE

    More actions

    Its reading my .venv folder as well, or there is something stored in session histories. I've been sitting at 5GB, but have been to 20GB+. Could we get a panel that displays a breakdown of memory usage, or some instructions on how to view what consumes it?
13. aniel300 commented on Jan 22, 2026

    

    aniel300

    on Jan 22, 2026

    More actions

    same issue
14. github-actions commented on Mar 28, 2026

    

    github-actionsBot

    on Mar 28, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.
15. github-actions

    closed this as completedon Mar 28, 2026