Skip to content

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

Closed

Description

@RovshanMuradov

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.

Activity

  1. added
    perfIndicates a performance issue or need for optimization
    on Jan 3, 2026
  2. github-actions commented on Jan 3, 2026

    @github-actions
    Contributor

    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.

  3. devxoul commented on Jan 5, 2026

    @devxoul
    Contributor

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

    Image
  4. Morphius22 commented on Jan 29, 2026

    @Morphius22

    Please fix - it's killing me

  5. RovshanMuradov commented on Jan 29, 2026

    @RovshanMuradov
    ContributorAuthor

    Please fix - it's killing me

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

  6. github-actions commented on Mar 31, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

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

Metadata

Metadata

Assignees

Labels

perfIndicates 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