anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Closed
opened 2026-02-16 18:05:46 -05:00 by yindo · 17 comments
yindo commented 2026-02-16 18:05:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @Brian-Zavala on GitHub (Jan 20, 2026).

Originally assigned to: @rekram1-node on GitHub.

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

Originally created by @Brian-Zavala on GitHub (Jan 20, 2026). Originally assigned to: @rekram1-node on GitHub. ### 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: ```bash /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) 3. Include at least one symlink in the nvim config (mine is `~/.config/nvim/lua/plugins/theme.lua` → `~/.config/omarchy/current/theme/neovim.lua`) 4. Open or edit files in the nvim config directory with OpenCode 5. Wait a few minutes - OpenCode will spawn ripgrep processes that never finish 6. 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
yindo added the bugperf labels 2026-02-16 18:05:46 -05:00
yindo closed this issue 2026-02-16 18:05:46 -05:00
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 20, 2026):

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

  • #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
  • #5220: Glob search uses 100% of CPU - reports similar ripgrep performance issue when searching for files
  • #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.

@github-actions[bot] commented on GitHub (Jan 20, 2026): This issue might be a duplicate of existing issues. Please check: - #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 - #5220: Glob search uses 100% of CPU - reports similar ripgrep performance issue when searching for files - #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.
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@hbouhadji commented on GitHub (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

@hbouhadji commented on GitHub (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
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@Brian-Zavala commented on GitHub (Jan 23, 2026):

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

@Brian-Zavala commented on GitHub (Jan 23, 2026): @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.
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@ainslec commented on GitHub (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
@ainslec commented on GitHub (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 ```
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@Brian-Zavala commented on GitHub (Jan 24, 2026):

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

@Brian-Zavala commented on GitHub (Jan 24, 2026): @ainslec you need to kill all opencode processes "killall -9 opencode"
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@emmaneugene commented on GitHub (Jan 24, 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

@emmaneugene commented on GitHub (Jan 24, 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](https://opncd.ai/share/vMO3WPY9) 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](https://opncd.ai/share/lcsy2JX4). 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
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@NikiLentz commented on GitHub (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?

@NikiLentz commented on GitHub (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?
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@cau1k commented on GitHub (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.

@cau1k commented on GitHub (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`.
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@konovalov-nk commented on GitHub (Jan 30, 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: https://github.com/BurntSushi/ripgrep/issues/692#issuecomment-347063338
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.

@konovalov-nk commented on GitHub (Jan 30, 2026): [This](https://unix.stackexchange.com/a/99166) 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: https://github.com/BurntSushi/ripgrep/issues/692#issuecomment-347063338 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.
yindo commented 2026-02-16 18:05:47 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 31, 2026):

I agree, let's fix it

I should've reviewed that pr better, apologies

@rekram1-node commented on GitHub (Jan 31, 2026): I agree, let's fix it I should've reviewed that pr better, apologies
yindo commented 2026-02-16 18:05:48 -05:00
Author
Owner
Copy Link
Copy Source

@jeroenev commented on GitHub (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 commented on GitHub (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
yindo commented 2026-02-16 18:05:48 -05:00
Author
Owner
Copy Link
Copy Source

@NikiLentz commented on GitHub (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.

@NikiLentz commented on GitHub (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.
yindo commented 2026-02-16 18:05:48 -05:00
Author
Owner
Copy Link
Copy Source

@jeroenev commented on GitHub (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.

@jeroenev commented on GitHub (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.
yindo commented 2026-02-16 18:05:48 -05:00
Author
Owner
Copy Link
Copy Source

@konovalov-nk commented on GitHub (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.

@konovalov-nk commented on GitHub (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.
yindo commented 2026-02-16 18:05:48 -05:00
Author
Owner
Copy Link
Copy Source

@jeroenev commented on GitHub (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).

@jeroenev commented on GitHub (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).
yindo commented 2026-02-16 18:05:48 -05:00
Author
Owner
Copy Link
Copy Source

@konovalov-nk commented on GitHub (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)
@konovalov-nk commented on GitHub (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) ```
yindo commented 2026-02-16 18:05:48 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Feb 11, 2026):

Yeah we can make it opt in

@rekram1-node commented on GitHub (Feb 11, 2026): Yeah we can make it opt in
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug perf
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#6977
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?