Description

When I try to open a deep directory path using the "Open Project" dialog in the Web UI, my fans start spinning loudly and CPU usage spikes to 100% across all cores. The system becomes very hot but the browser remains responsive. Memory usage jumps from ~350MB to 7.9GB and stays there.

This happens consistently when I paste or type paths with many directory segments.

Steps to reproduce

My Setup:

• OS: Arch Linux (kernel 6.18.9-arch1-2)
• CPU: Intel Core i7-11700F @ 2.50GHz (8 cores, 16 threads)
• RAM: 46GB
• OpenCode: Running as systemd user service

  systemctl --user status opencode-serve.service
  # Active: active (running)
  # Command: /home/fkxxyz/.opencode/bin/opencode serve --hostname 0.0.0.0
  # Listening on: http://0.0.0.0:4096

• Browser: Chromium 144.0.7559.132-1 accessing http://localhost:4096

What I did:

1. Started OpenCode server (already running as systemd service):

   systemctl --user start opencode-serve.service

2. Opened browser and navigated to http://localhost:4096

3. Clicked the + button on the left sidebar to open the "Open Project" dialog

   • This shows a dialog with an input field at the top
   • Below it shows a list of suggested directories
   • Note: I haven't opened any project yet, just want to navigate to a deep directory to start working

4. Pasted a deep path into the input field:

   /home/fkxxyz/src/company/backend/services/api/modules/auth/controllers
   

   (This is a real path with 9 directory segments)

5. Started typing one more character to continue navigating deeper

What happened:

• Immediately (< 1 second):

  • Fans started spinning loudly (very noticeable)
  • No visible lag in the browser - everything still responsive

• Checked system resources in another terminal:

  # CPU usage - all cores maxed out
  $ top -b -n 1 | grep opencode
  128991 fkxxyz    20   0  79.8g   6.0g  opencode  1600.0  12.6  S
  # ↑ 1600% CPU usage! All 16 threads at 100%
  
  # Multiple ripgrep processes running
  $ ps aux | grep "rg --files" | grep -v grep | wc -l
  12
  # ↑ Many ripgrep processes running simultaneously
  
  # Memory usage jumped dramatically
  $ systemctl --user status opencode-serve.service | grep Memory
  Memory: 7.9G (peak: 8.4G)

• Duration: Fans kept spinning for about 30-40 seconds

• Result:

  • Dialog showed results normally
  • Browser remained responsive throughout
  • Could close the dialog anytime without issues
  • Memory stayed at 7.9GB even after the CPU spike ended

Important observation:

After the first trigger, the issue doesn't happen again when typing the same or similar deep paths. This suggests the scanned directories are cached in memory (which explains why memory stays at 7.9GB).

This also happens with:

• Non-existent paths: /aa/d/f/fc/e/d/f/dd/ss/d/s

  • Even worse because it tries to fuzzy match every segment

• Any path with 8+ segments:

  • /home/user/projects/deep/nested/path/with/many/segments
  • The more segments, the worse it gets

• Paths starting from root:

  • /var/log/journal/... (scans entire /var)
  • /usr/share/... (scans entire /usr)

This does NOT happen with:

• Short paths like /home/fkxxyz/projects
• Paths with only 2-3 segments
• Using fuzzy search without typing full paths

Workaround I'm using now:

Instead of pasting the full path, I have to:

1. Type the first segment (e.g., /home)
2. Wait for the list to appear
3. Type the next segment (/home/fkxxyz)
4. Wait for the list to appear
5. Repeat for each segment...

For deep filesystem paths, this makes opening new projects extremely inefficient.

Plugins

None - this is core functionality, no plugins installed

OpenCode version

v1.2.15 (also tested on latest dev branch from February 2026 - same issue)

$ opencode --version
1.2.15

Screenshot and/or share link

Before triggering the issue (fresh OpenCode server):

$ opencode serve --hostname 127.0.0.1 --port 4097 &
$ ps aux | grep "opencode serve" | grep 4097
fkxxyz  189355  41.6  0.7  74128528  362140  opencode serve
# ↑ Baseline: ~350MB memory usage

During the issue:

$ systemctl --user status opencode-serve.service | grep -E "Memory|CPU"
Memory: 7.9G (peak: 8.4G)  # Was ~350MB before!
CPU: 24min 30.535s  # jumped dramatically in 30-40 seconds

$ ps aux | grep "rg --files" | grep -v grep
# Multiple ripgrep processes, each at ~100% CPU

Can provide monitoring screenshots if needed

Operating System

Arch Linux (rolling release)

• Kernel: 6.18.9-arch1-2
• Architecture: x86_64

Terminal

Web UI (primary usage)

• Browser: Chromium 144.0.7559.132-1
• Accessing: http://localhost:4096

Note about other interfaces:

• Desktop App: Haven't tested, but likely has the same issue
• Terminal UI: Does NOT have this issue - Terminal UI starts directly in the current working directory and doesn't support multi-project switching, so there's no "Open Project" dialog

Impact

Severity: High

This makes the "Open Project" dialog very inefficient for:

• Projects in deep directory structures (common in monorepos)
• Navigating to directories outside common locations
• Any path with more than 5-6 segments

User experience:

• Fans spinning loudly for 30-40 seconds (embarrassing in office/meetings)
• CPU at 100% across all cores
• Memory usage jumps from ~350MB to 7.9GB and never goes back down
• Have to input paths segment by segment, waiting after each one
• Very slow workflow for opening new projects in deep directories

Current workaround:

• Type path segment by segment, waiting for results after each segment
• Extremely inefficient for deep directory structures