You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf: ripgrep config file search scans entire home directory including large hidden directories #6741
Summary
When OpenCode starts, it runs a ripgrep search with the pattern **/opencode/config.* that recursively scans the entire home directory, including large hidden directories like ~/.local, ~/.cache, node_modules, etc. This causes extremely high CPU usage (1000%+) and can take 10+ minutes to complete.
Environment
OpenCode version: 1.0.223
OS: Linux (also likely affects macOS)
Shell: fish
Steps to Reproduce
Have a home directory with large hidden folders (common on most systems):
~/.local (can be 100+ GB)
~/.cache (can be 10+ GB)
~/.npm, ~/.cargo, ~/.rustup, etc.
Run opencode in any directory
Observe rg process consuming high CPU for extended periods
Observed Behavior
OpenCode spawns a ripgrep process with the following command:
/usr/bin/rg --files --glob=!.git/* --follow --hidden --glob=**/opencode/config.*
This command:
Uses --hidden flag, which includes all hidden directories
Uses --follow flag, which follows symlinks (potential for infinite loops)
Searches recursively from the current or home directory
Takes 9+ minutes and consumes 1000%+ CPU on systems with large hidden directories
Activity monitor showing the issue:
Process running for 9+ minutes at high CPU usage
Expected Behavior
Config file search should:
Only search in documented config locations (~/.config/opencode/, project root, $OPENCODE_CONFIG)
Exclude common large directories (.cache, .local, node_modules, etc.) by default
Complete within seconds, not minutes
Workaround
Creating a ~/.ignore file with the following content resolves the issue:
.cache/
.local/
.npm/
.bun/
node_modules/
.cargo/
.rustup/
go/
.gradle/
.m2/
After adding this file, the search completes in ~0.01 seconds instead of 9+ minutes.
Suggested Fix
Consider one of these approaches:
Search only documented locations - Instead of recursive glob search, directly check:
~/.config/opencode/opencode.json
./opencode.json (project root)
$OPENCODE_CONFIG env var
Add default ignore patterns - Include common large directories in the search exclusion list
Limit search depth - Use --max-depth flag to prevent deep recursive searches
Remove --follow flag - Prevent potential infinite loops from symlinks
Additional Context
The glob pattern */opencode/config. also doesn't match the actual config filename opencode.json, which may indicate the search is looking for something else (plugins? legacy config names?). If this search is intentional, the ignore patterns should still be added to prevent scanning irrelevant directories.
This issue appears to be related to #3176 in that both describe OpenCode performing expensive operations (git add in #3176, ripgrep search in this issue) on entire home directories without proper safeguards, causing severe performance degradation. While the specific operation differs, they share the root cause: lack of size limits and default exclusions for large hidden directories.
Both issues would benefit from a unified solution that:
Adds sensible defaults for directory exclusions (.cache, .local, node_modules, etc.)
Implements size/depth limits for recursive operations
Provides configuration options to customize search behavior
The suggested fix in this issue's workaround (using ~/.ignore file) demonstrates that ripgrep is responsive to proper configuration - this should be applied by default or configurable rather than requiring manual user intervention.
Activity
github-actions commentedon Jan 3, 2026
This issue appears to be related to #3176 in that both describe OpenCode performing expensive operations (git add in #3176, ripgrep search in this issue) on entire home directories without proper safeguards, causing severe performance degradation. While the specific operation differs, they share the root cause: lack of size limits and default exclusions for large hidden directories.
Both issues would benefit from a unified solution that:
The suggested fix in this issue's workaround (using ~/.ignore file) demonstrates that ripgrep is responsive to proper configuration - this should be applied by default or configurable rather than requiring manual user intervention.
devxoul commentedon Jan 5, 2026
This really sucks. It consumed my weekly limits in a few seconds :(
Morphius22 commentedon Jan 29, 2026
Please fix - it's killing me
RovshanMuradov commentedon Jan 29, 2026
Yeah me too haha. I'll need to look how it could be fixed
github-actions commentedon Mar 31, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.