-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Description
Ran into an issue where grep returns "No files found" when working in directories with symlinked content. What's frustrating is that glob and list handle these cases just fine, so the behavior feels inconsistent and broken from a user perspective.
The Problem
When you run OpenCode from a symlink farm (think ln -s /real/project/src src), here's what happens:
glob **/*.tsworks perfectlylistshows all the files you'd expectgrep "pattern"mysteriously finds nothing
How to Reproduce
Set up a quick test case:
mkdir /tmp/symlink-test && cd /tmp/symlink-test
ln -s /path/to/real/project/src src
ln -s /path/to/real/project/packages packagesNow run OpenCode from /tmp/symlink-test and try searching. glob and list cooperate, but grep gives you "No files found" every time.
Diving into the Code
The issue is pretty clear once you look at the implementation. There's an internal inconsistency in how ripgrep is called:
Ripgrep.search()(the internal function) skips the--followflagRipgrep.files()(used by glob/list) correctly includes--follow
So the same tool behaves differently depending on which wrapper function you use.
The Weird Twist
Here's what got me: when ripgrep isn't available and the code falls back to standard grep -r, it actually works. That's because grep -r follows symlinks by default—ripgrep doesn't. So our "better" tool is actually what broke things.
Fix
Need to add --follow flag in two spots:
packages/opencode/src/tool/grep.ts— the CLI argspackages/opencode/src/file/ripgrep.ts— theRipgrep.searchargs
That should make all the file-finding tools behave consistently across symlinked directories.