anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #6167] fix(list): remove recursion and file limit for predictable directory listing #11762

New Issue
Closed
opened 2026-02-16 18:16:42 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:42 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/6167

State: closed
Merged: No

Problem

The list tool had a fundamental design issue that caused unpredictable and confusing behavior:

  1. Recursive scanning: Used ripgrep to recursively scan all files in a directory tree
  2. Arbitrary 100-file limit: Stopped after collecting 100 files from anywhere in the tree
  3. Unpredictable output: Only directories containing those first 100 files would appear in the output

Example of the bug:

In a directory with 41 subdirectories:

$ ls -d */ | wc -l
41

But the list tool would only show 2 directories:

/Users/user/Downloads/LLM/
  ooba/
  anti-llm-review/

The other 39 directories were invisible because ripgrep's first 100 files happened to all be in those 2 directories.

Solution

Changed the list tool to behave like a standard directory listing command (ls, os.listdir(), etc.):

  • No recursion: Only lists immediate children of the requested directory
  • No arbitrary limits: Shows all entries at the current level
  • Predictable: Always shows the same output for the same directory
  • Efficient: Uses fs.readdir() instead of recursive ripgrep scanning

Changes:

  • ✅ Removed ripgrep dependency for this tool
  • ✅ Removed 100-file limit
  • ✅ Switched to fs.readdir() with withFileTypes for direct, non-recursive listing
  • ✅ Maintained ignore pattern functionality
  • ✅ Enhanced metadata to show directory/file counts separately
  • ✅ Directories now consistently shown with trailing / for clarity

After the fix:

Same directory now correctly shows all 41 subdirectories plus files:

/Users/user/Downloads/LLM/
  __pycache__/
  agents/
  anti-llm-review/
  asky/
  AutoCisco/
  better_brew/
  BetterOllama/
  browser_use/
  ... (all 41 directories)
  ... (all files at this level)

Benefits

  1. Predictable: Tool now behaves like standard ls command
  2. Complete: Shows all immediate children without arbitrary limits
  3. Fast: No recursive scanning needed
  4. Clear separation of concerns:
    • list → show immediate children (like ls)
    • glob → find files by pattern (like find)
    • grep → search file contents

Testing

Tested with:

  • Directories with 40+ subdirectories ✅
  • Directories with hundreds of files ✅
  • Empty directories ✅
  • Directories with ignore patterns ✅

All cases now show complete, predictable output.

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/6167 **State:** closed **Merged:** No --- ## Problem The `list` tool had a fundamental design issue that caused unpredictable and confusing behavior: 1. **Recursive scanning**: Used ripgrep to recursively scan all files in a directory tree 2. **Arbitrary 100-file limit**: Stopped after collecting 100 files from anywhere in the tree 3. **Unpredictable output**: Only directories containing those first 100 files would appear in the output ### Example of the bug: In a directory with 41 subdirectories: ```bash $ ls -d */ | wc -l 41 ``` But the `list` tool would only show 2 directories: ``` /Users/user/Downloads/LLM/ ooba/ anti-llm-review/ ``` The other 39 directories were invisible because ripgrep's first 100 files happened to all be in those 2 directories. ## Solution Changed the `list` tool to behave like a standard directory listing command (`ls`, `os.listdir()`, etc.): - **No recursion**: Only lists immediate children of the requested directory - **No arbitrary limits**: Shows all entries at the current level - **Predictable**: Always shows the same output for the same directory - **Efficient**: Uses `fs.readdir()` instead of recursive ripgrep scanning ### Changes: - ✅ Removed ripgrep dependency for this tool - ✅ Removed 100-file limit - ✅ Switched to `fs.readdir()` with `withFileTypes` for direct, non-recursive listing - ✅ Maintained ignore pattern functionality - ✅ Enhanced metadata to show directory/file counts separately - ✅ Directories now consistently shown with trailing `/` for clarity ## After the fix: Same directory now correctly shows all 41 subdirectories plus files: ``` /Users/user/Downloads/LLM/ __pycache__/ agents/ anti-llm-review/ asky/ AutoCisco/ better_brew/ BetterOllama/ browser_use/ ... (all 41 directories) ... (all files at this level) ``` ## Benefits 1. **Predictable**: Tool now behaves like standard `ls` command 2. **Complete**: Shows all immediate children without arbitrary limits 3. **Fast**: No recursive scanning needed 4. **Clear separation of concerns**: - `list` → show immediate children (like `ls`) - `glob` → find files by pattern (like `find`) - `grep` → search file contents ## Testing Tested with: - Directories with 40+ subdirectories ✅ - Directories with hundreds of files ✅ - Empty directories ✅ - Directories with ignore patterns ✅ All cases now show complete, predictable output.
yindo added the pull-request label 2026-02-16 18:16:42 -05:00
yindo closed this issue 2026-02-16 18:16:42 -05:00
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 pull-request
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#11762
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?