[GH-ISSUE #228] bug: File explorer search appears to show no results and takes a very long time for any filter #140

New issue

Open

opened 2026-10-18 14:03:19 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-18 14:03:19 +00:00

Owner

Originally created by @JKGeovision on GitHub (Aug 18, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/228

Hello,

The file explorer search ("Search filenames and contents…") appears to never match anything when a filter is entered. Results do eventually appear, but only after a very long delay, which makes it look like no file is ever found. I suspect this is because every keystroke triggers a full content search across the entire file tree instead of a fast filename-only match.

Steps to reproduce:

Navigate to the file explorer.
Click into the search field ("Search filenames and contents…").
Type a single character (e.g. .).
Observe that the file list below stays empty while the search is running. It looks as if nothing will ever match.
Wait on a reasonably large directory tree, results only show up after a very long time (tens of seconds).
Repeat with a full entry such as .claude: folders, files, and content snippets do eventually appear, but with the same long delay.

Expected behavior:
Filtering should respond almost instantly, ideally matching filenames first (or entirely client-side), with the heavier full-content search only as a secondary/explicit step.

Thanks in advance for looking into this!

Best regards,
Joshua Krimmer

Originally created by @JKGeovision on GitHub (Aug 18, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/228 Hello, The file explorer search ("Search filenames and contents…") appears to never match anything when a filter is entered. Results do eventually appear, but only after a very long delay, which makes it look like no file is ever found. I suspect this is because every keystroke triggers a full content search across the entire file tree instead of a fast filename-only match. Steps to reproduce: 1. Navigate to the file explorer. 2. Click into the search field ("Search filenames and contents…"). 3. Type a single character (e.g. `.`). 4. Observe that the file list below stays empty while the search is running. It looks as if nothing will ever match. 5. Wait on a reasonably large directory tree, results only show up after a very long time (tens of seconds). 6. Repeat with a full entry such as `.claude`: folders, files, and content snippets do eventually appear, but with the same long delay. Expected behavior: Filtering should respond almost instantly, ideally matching filenames first (or entirely client-side), with the heavier full-content search only as a secondary/explicit step. <img width="1975" height="243" alt="Image" src="https://github.com/user-attachments/assets/19bee589-74b9-4023-8a65-1804f47a34d1" /> <img width="1964" height="413" alt="Image" src="https://github.com/user-attachments/assets/4fa371db-7bc6-4762-abbe-84e169415db7" /> Thanks in advance for looking into this! Best regards, Joshua Krimmer

bsakaguchi commented

2026-10-18 14:03:19 +00:00

Author

Owner

@owui-terminator[bot] commented on GitHub (Aug 18, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟣 #211 Issue #211
This issue is about the file explorer UI in the same workspace area, so it is the closest potential match among existing reports. However, it focuses on persistent layout rather than search behavior, so it is only loosely related.
by unknown
🟣 #144 bug: Search tool ignores .gitignore and includes unwanted files in results
Both issues involve search behavior in the computer/workspace tooling and concern search scanning too much data. This one is specifically about search respecting .gitignore, which points to the underlying search implementation and performance characteristics that may also affect the slow file explorer search.
by JKGeovision

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (Aug 18, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#211](https://github.com/open-webui/computer/issues/211) **Issue #211** *This issue is about the file explorer UI in the same workspace area, so it is the closest potential match among existing reports. However, it focuses on persistent layout rather than search behavior, so it is only loosely related.* *by unknown* 2. 🟣 [#144](https://github.com/open-webui/computer/issues/144) **bug: Search tool ignores .gitignore and includes unwanted files in results** *Both issues involve search behavior in the computer/workspace tooling and concern search scanning too much data. This one is specifically about search respecting .gitignore, which points to the underlying search implementation and performance characteristics that may also affect the slow file explorer search.* *by JKGeovision* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

No labels

enhancement

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/computer#140

No description provided.

Rows
Columns