anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

perf: ripgrep config file search scans entire home directory including large hidden directories #4125

New Issue
Open
opened 2026-02-16 17:42:42 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 17:42:42 -05:00
Owner
Copy Link
Copy Source

Originally created by @RovshanMuradov on GitHub (Jan 3, 2026).

Originally assigned to: @rekram1-node on GitHub.

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
  1. 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.
  2. Run opencode in any directory
  3. 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:
  1. Only search in documented config locations (~/.config/opencode/, project root, $OPENCODE_CONFIG)
  2. Exclude common large directories (.cache, .local, node_modules, etc.) by default
  3. 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:
  4. Search only documented locations - Instead of recursive glob search, directly check:
    • ~/.config/opencode/opencode.json
    • ./opencode.json (project root)
    • $OPENCODE_CONFIG env var
  5. Add default ignore patterns - Include common large directories in the search exclusion list
  6. Limit search depth - Use --max-depth flag to prevent deep recursive searches
  7. 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.
Originally created by @RovshanMuradov on GitHub (Jan 3, 2026). Originally assigned to: @rekram1-node on GitHub. 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 1. 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. 2. Run `opencode` in any directory 3. 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: 1. Only search in documented config locations (~/.config/opencode/, project root, $OPENCODE_CONFIG) 2. Exclude common large directories (.cache, .local, node_modules, etc.) by default 3. 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: 1. Search only documented locations - Instead of recursive glob search, directly check: - ~/.config/opencode/opencode.json - ./opencode.json (project root) - $OPENCODE_CONFIG env var 2. Add default ignore patterns - Include common large directories in the search exclusion list 3. Limit search depth - Use --max-depth flag to prevent deep recursive searches 4. 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.
yindo added the perf label 2026-02-16 17:42:42 -05:00
yindo commented 2026-02-16 17:42:42 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (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:

  1. Adds sensible defaults for directory exclusions (.cache, .local, node_modules, etc.)
  2. Implements size/depth limits for recursive operations
  3. 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.

@github-actions[bot] commented on GitHub (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: 1. Adds sensible defaults for directory exclusions (.cache, .local, node_modules, etc.) 2. Implements size/depth limits for recursive operations 3. 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.
yindo commented 2026-02-16 17:42:43 -05:00
Author
Owner
Copy Link
Copy Source

@devxoul commented on GitHub (Jan 5, 2026):

This really sucks. It consumed my weekly limits in a few seconds :(

Image
@devxoul commented on GitHub (Jan 5, 2026): This really sucks. It consumed my weekly limits in a few seconds :( <img width="897" height="141" alt="Image" src="https://github.com/user-attachments/assets/1460e5d2-4410-4194-a935-3f30512e0e7a" />
yindo commented 2026-02-16 17:42:43 -05:00
Author
Owner
Copy Link
Copy Source

@Morphius22 commented on GitHub (Jan 28, 2026):

Please fix - it's killing me

@Morphius22 commented on GitHub (Jan 28, 2026): Please fix - it's killing me
yindo commented 2026-02-16 17:42:43 -05:00
Author
Owner
Copy Link
Copy Source

@RovshanMuradov commented on GitHub (Jan 28, 2026):

Please fix - it's killing me

Yeah me too haha. I'll need to look how it could be fixed

@RovshanMuradov commented on GitHub (Jan 28, 2026): > Please fix - it's killing me Yeah me too haha. I'll need to look how it could be fixed
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 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#4125
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?