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

[Brian-Zavala]

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

[github-actions]

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

• perf: ripgrep config file search scans entire home directory including large hidden directories #6741: perf: ripgrep config file search scans entire home directory including large hidden directories - describes similar issue with ripgrep consuming excessive CPU and --follow flag causing problems with symlinks
• Glob search uses 100% of CPU #5220: Glob search uses 100% of CPU - reports similar ripgrep performance issue when searching for files
• Path traversal vulnerability via symlinks and cross-drive paths #8313: Path traversal vulnerability via symlinks and cross-drive paths - highlights security and performance concerns with how symlinks are followed during file searches

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

[hbouhadji]

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

[Brian-Zavala]

@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.

[ainslec]

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 

[Brian-Zavala]

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

[emmaneugene]

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

[NikiLentz]

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?

[cau1k]

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.

[konovalov-nk]

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.