Skip to content

Ripgrep processes get stuck and consume 700% CPU, freezing entire system #9676

Closed
#11415
Closed
Ripgrep processes get stuck and consume 700% CPU, freezing entire system#9676
#11415
Assignees
rekram1-node
Labels
bugSomething isn't workingperfIndicates a performance issue or need for optimization

Description

@Brian-Zavala
Brian-Zavala
opened on Jan 20, 2026

Description

I was working on some Neovim config files when my laptop suddenly became extremely sluggish - like completely unusable. At first I thought it was a power management issue, but when I checked my processes, I found three ripgrep processes that had been running for almost 3 hours, each consuming around 230% CPU (680% total).

The commands OpenCode spawned were:

/usr/bin/rg --files --glob=!.git/* --follow --hidden --glob=**/*nvim*
/usr/bin/rg --files --glob=!.git/* --follow --hidden --glob=**/.config/nvim/**/*.lua
/usr/bin/rg --files --glob=!.git/* --follow --hidden --glob=**/.config/nvim/**/*.vim

All three just ran indefinitely and never completed. My system load hit 31 (should be under 8 for my 8-core CPU).
The problem seems to be:

  • Overly broad glob patterns - **/*nvim* matches 61,000+ files in my home directory
  • The --follow flag - I have symlinks in my nvim config, and following them causes massive directory traversal
  • through my ~/.local/share/nvim/lazy/ plugins folder (594 subdirectories, 255MB)
  • No timeout - The processes just run forever with no resource limits
  • Searching entire home directory instead of just the workspace

This has happened twice now. I have to manually kill the processes with kill -9 to get my system responsive again.

Plugins

@modelcontextprotocol/server-filesystem - @modelcontextprotocol/server-github - @modelcontextprotocol/server-postgres - @modelcontextprotocol/server-brave-search

OpenCode version

1.1.25

Steps to reproduce

  1. Have a Neovim config directory with lazy.nvim plugins (~/.config/nvim and ~/.local/share/nvim/lazy with lots of plugins)
  2. Include at least one symlink in the nvim config (mine is ~/.config/nvim/lua/plugins/theme.lua → ~/.config/omarchy/current/theme/neovim.lua)
  3. Open or edit files in the nvim config directory with OpenCode
  4. Wait a few minutes - OpenCode will spawn ripgrep processes that never finish
  5. Check htop or ps aux --sort=-%cpu to see multiple rg processes consuming massive CPU

Screenshot and/or share link

No response

Operating System

Arch Linux (Omarchy distribution) - kernel 6.12+

Terminal

kitty

Activity

  1. Brian-Zavala
    added
    bugSomething isn't working
    on Jan 20, 2026
  2. github-actions
    assigned
    rekram1-node
    on Jan 20, 2026
  3. github-actions
    added
    perfIndicates a performance issue or need for optimization
    on Jan 20, 2026

  4. github-actions commented on Jan 20, 2026

    @github-actions
    github-actionsBot
    on Jan 20, 2026 – with GitHub Actions
    Contributor

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

    Feel free to ignore if none of these address your specific case.

  5. hbouhadji commented on Jan 23, 2026

    @hbouhadji
    hbouhadji
    on Jan 23, 2026

    Same issue ! I thought my computer was going to explode, first time this has happened to me since apple m1.

    ✱ Glob "/Users/hakim/.cargo/registry/src/**/gpui-*/src/lib.rs" in ../../../../.. 
Tool execution aborted
✱ Glob "/Users/hakim/.cargo/registry/src/**/gpui-*/Cargo.toml" in ../../../../.. 
Tool execution aborted

    here the tool calls he tries, had to kill them manually

  6. Brian-Zavala commented on Jan 23, 2026

    @Brian-Zavala
    Brian-Zavala
    on Jan 23, 2026
    Author

    @hbouhadji yeah my poor laptop sounded like a jet plane. I couldn't figure out why my pc was going so damn slow, I first thought it was neovim cause when I closed it, the pc sped up but in reality opencode was being the bully with its search processes. I finally just removed opencode altogether because I ran into more bugs like this.

  7. ainslec commented on Jan 24, 2026

    @ainslec
    ainslec
    on Jan 24, 2026

    Same thing is happening to me. I know what I did, but I don't know how to resolve this. Ideally I'd like OpenCode to detect this situation and calm things down.

    How I did this is that I accidentally opened OpenCode in my home folder. Therefore it's indexing many many GB of data, including my Steam library. Would appreciate instructions how to clean this up, currently it's thrashing my swap file, and destroying my SSD in the process. Innocently of course, a bug, but a super dangerous bug. My computer locks up every few minutes and kills processes.

    top - 23:33:11 up 10 days, 16:24, 4 users, load average: 38.23, 33.59, 24.42 Threads: 2703 total, 38 running, 2603 sleeping, 62 stopped, 0 zombie %Cpu(s): 7.3 us, 91.9 sy, 0.0 ni, 0.1 id, 0.0 wa, 0.5 hi, 0.2 si, 0.0 st MiB Mem : 27827.5 total, 2553.4 free, 22532.3 used, 7480.2 buff/cache MiB Swap: 4096.0 total, 0.0 free, 4096.0 used. 5295.2 avail Mem PID USER PR NI VIRT RES 
SHR S %CPU %MEM TIME+ COMMAND 2421608 chris 20 0 259196 21044 1368 R 79.7 0.1 2:34.88 rg 2421597 chris 20 0 
263292 23064 1364 R 65.0 0.1 2:48.06 rg 2421610 chris 20 0 259196 21044 1368 R 60.8 0.1 2:51.56 rg 2421629 chris 20 0 
267388 23236 1368 R 60.5 0.1 2:52.92 rg 2421613 chris 20 0 259196 21044 1368 R 50.8 0.1 2:51.80 rg 2421609 chris 20 0 
259196 21044 1368 R 48.6 0.1 2:43.30 rg 2421598 chris 20 0 263292 23064 1364 R 47.9 0.1 2:53.24 rg 2421605 chris 20 0 
259196 21044 1368 R 47.9 0.1 2:49.70 rg 2421592 chris 20 0 263292 23064 1364 R 46.3 0.1 2:47.77 rg 2421595 chris 20 0 
263292 23064 1364 R 45.0 0.1 2:39.12 rg 2421614 chris 20 0 259196 21044 1368 R 44.7 0.1 2:52.00 rg 2421607 chris 20 0 
259196 21044 1368 R 42.8 0.1 2:52.25 rg 2421611 chris 20 0 259196 21044 1368 R 41.5 0.1 2:50.31 rg 2421593 chris 20 0

  8. Brian-Zavala commented on Jan 24, 2026

    @Brian-Zavala
    Brian-Zavala
    on Jan 24, 2026
    Author

    @ainslec you need to kill all opencode processes "killall -9 opencode"

  9. emmaneugene commented on Jan 25, 2026

    @emmaneugene
    emmaneugene
    on Jan 25, 2026

    Chiming in to say that I've experienced this issue too. I've been able to reproduce it fairly consistently like this:

    1. Invoke opencode in my home directory (~)
    2. Prompt with "find my opencode config"
    3. The agent will then use the Glob tool (rg under the hood) search for some relevant patterns. The issue is that these processes occasionally run indefinitely and consume all available CPU resources

    I have a link to a thread where this issue occurred. And htere are the full commands of the 3 rg processes that were spawned:

    • rg --files --glob=!.git/* --follow --hidden --glob=**/*opencode*
    • rg --files --glob=!.git/* --follow --hidden --glob=**/opencode.json
    • rg --files --glob=!.git/* --follow --hidden --glob=**/.opencode*

    Glob works when invoked in a more specific directory like ~/.config, for example in this thread. So I guess this is fundamentally a performance issue with using rg in a directory that has lots of symlinks, mounted volumes or system drives.

    I looked up the docs for tool configurations to see if there was any support for setting timeouts on tool calls (and sending a SIGTERM/SIGKILL for example), but so far found none. Not sure how feasible that would be to implement, but I feel it would be very useful

  10. NikiLentz commented on Jan 25, 2026

    @NikiLentz
    NikiLentz
    on Jan 25, 2026

    i have the same issue on my pop os 24.04, it didn't quite peg my cpu, but i was at 77% for minutes until i manually killed the ripgrep process, seems to me like rg or glob are the ones with an issue, is there a way to simply not allow it to use glob, even if it takes a few more tokens?

  11. cau1k commented on Jan 25, 2026

    @cau1k
    cau1k
    on Jan 25, 2026

    also seeing this on Arch and NixOS. I reduced the --max-filesize arg in .config/ripgrep/config to 1M (default is 10M) and I'm not seeing as persistent CPU spikes. Not sure if this affects --glob.

  12. konovalov-nk commented on Jan 31, 2026

    @konovalov-nk
    konovalov-nk
    on Jan 31, 2026

    This is exactly the problem why.
    FULL STOP (see what I did here 🤣). What are we doing? Why do we need to follow symlinks for Glob tool?
    This can't be default behavior!

    See this comment: BurntSushi/ripgrep#692 (comment)
    Why are we overriding this with --follow?

    Instead, what should actually happen, in this order:

    1. When Glob doesn't provide enough results, it's usually context problem. User didn't provide enough instructions or they're too vague. opencode can't be this smart and try follow symlinks. This is not a fix for self-induced error. "No results" for agent means either "I'm searching for a wrong file" or "file truly doesn't exist". And you have failure mode that you can recover from very easily: "try another pattern" or "follow up to user explaining the problem"
    2. When opencode is used in the context of entire system (e.g. access to /), there should be a mechanism that either: blocks using --follow (why do you even need it if you can brute-force it with rg /), or uses sensible .rgignore / ripgreprc defaults.
    # e.g. my current example

$ cat ~/.rgignore 
# --- Steam: volatile Chromium cache (broken symlinks + transient locks)
**/.steam/**/config/htmlcache/**
**/.local/share/Steam/config/htmlcache/**

# --- Steam: runtime selinux entries (often dangling in runtime layouts)
.steam/**/*/selinux
**/steam/**/*/selinux
**/steam-*/**/*/selinux
**/Steam/**/*/selinux
**/SteamLinuxRuntime/**/steam-runtime/**/selinux

# --- Steam: pressure-vessel temp overlays (ephemeral)
**/SteamLinuxRuntime_*/var/tmp-*/**
/.steam/**/var/tmp-*/
/.local/share/Steam/**/var/tmp-*/
/.local/share/umu/**/var/tmp-*/

# --- Wine prefixes (your existing)
.wine/
.wine*/
**/.wine/
**/.wine*/
**/.wine*/dosdevices/
**/.wine*/dosdevices/*:
**/dosdevices/z:
Games/**/dosdevices/
Games/**/dosdevices/*:

# --- yay build cache (pick one)
**/.cache/yay/*/src/**
**/.cache/yay/*/pkg/**
# or: **/.cache/yay/**

# --- random one-off
**/dri/mali-dp_dri.so
.local/share/Trash/
**/.codex/tmp/**

    and

    $ echo "export RIPGREP_CONFIG_PATH=\"$HOME/.config/ripgrep/ripgreprc\"" >> ~/.bashrc
[br11k@archvm] tst $ micro ~/.config/ripgrep/ripgreprc
[br11k@archvm] tst $ cat ~/.config/ripgrep/ripgreprc 
--no-messages
--one-file-system

    Please, please don't make this even more cursed than that 🙏
    Respect Linux defaults when using tools that interact with file system, they are for reasons.

  13. rekram1-node commented on Jan 31, 2026

    @rekram1-node
    rekram1-node
    on Jan 31, 2026
    Contributor

    I agree, let's fix it

    I should've reviewed that pr better, apologies

  14. rekram1-node
    closed this as completedin #11415on Jan 31, 2026

  15. jeroenev commented on Feb 9, 2026

    @jeroenev
    jeroenev
    on Feb 9, 2026

    There should be an escape hatch tho, for allowing certain symlinks to be traversed.
    When working with Odoo, many modules are loaded into a project (odoo, enterprise, OCA modules etc...) and when using worktrees, it doesn't make sense to keep dozens of copies of each folder per project.
    Symlinking is an easy solution for this, but that no longer works if you disable it entirely without any option to allow RG to follow certain symlinks

  16. NikiLentz commented on Feb 9, 2026

    @NikiLentz
    NikiLentz
    on Feb 9, 2026

    it just doesn't have to follow them automatically for that, if it gets back a symlink it will simply make another call to the location of the relevant symlink. I'd bet that's less token intensive than autoresolving them.

  17. jeroenev commented on Feb 9, 2026

    @jeroenev
    jeroenev
    on Feb 9, 2026

    It seems to get stuck a lot on this for me.
    It keeps searching with empty results, and then ends up using ls -la to traverse the files manually, wasting tons and tons of tokens and context, often still failing to find the right details.
    I need it to be able to search and find results in symlinked folders, not just view a single symlinked file.

  18. konovalov-nk commented on Feb 9, 2026

    @konovalov-nk
    konovalov-nk
    on Feb 9, 2026

    There should be an escape hatch tho, for allowing certain symlinks to be traversed. When working with Odoo, many modules are loaded into a project (odoo, enterprise, OCA modules etc...) and when using worktrees, it doesn't make sense to keep dozens of copies of each folder per project. Symlinking is an easy solution for this, but that no longer works if you disable it entirely without any option to allow RG to follow certain symlinks

    @jeroenev This is already a "user-controlled" environment, for which I'd suggest writing/extending own Blob tool. It can be an option to toggle this in native tool but 100% must not be default behavior. If there's some setup that requires traversing symlinks to find things outside of the main folder, this already too complicated to handle properly.

    Users should be empowered to write their own Glob patterns / folders, configurable or easily extensible. I suggest to try and write your own tool first. If this is a common use-case, it can be maintained.

  19. jeroenev commented on Feb 9, 2026

    @jeroenev
    jeroenev
    on Feb 9, 2026

    Doesn't seem like an uncommon use-case to me, at least for many "module-based" codebases I would think this is fairly common use-case.
    I understand that it's no longer the default, especially when users run opencode from their home directory
    I think it makes sense to at least make --follow opt-in, for users who know what they're symlinking in their project (which I would suspect is the majority of projects).

  20. konovalov-nk commented on Feb 9, 2026

    @konovalov-nk
    konovalov-nk
    on Feb 9, 2026

    It can be supported as followSymlinks: ["odoo", "enterprise", "oca", "path/to"], something like that. It must be configurable to explicitly allow following + there should be a mechanism that detects loops early and either stops until you fix it (UX-friendly) or simply ignores any symlinks deeper than 1 (not sure if possible).
    E.g.

    Found a symlink loop while indexing files:
./odoo/addons -> ../enterprise/addons -> ../odoo/addons
Indexing stopped for safety. Fix the symlinks or add an exclude.
(hint: run realpath on these links)

  21. rekram1-node commented on Feb 11, 2026

    @rekram1-node
    rekram1-node
    on Feb 11, 2026
    Contributor

    Yeah we can make it opt in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingperfIndicates a performance issue or need for optimization

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions