At work, the monorepo is enormous and files are loaded on-demand as needed. This isn't uncommon with huge repos - Microsoft have VFS for Git (although I hear that's deprecated now), Meta have EdenFS, and Google has some proprietary solution.

We have a hook that blocks find and grep because they can be extremely slow, and tells it to instead use some significantly faster MCP tools to search the codebase, powered by a search index with local changes overlaid.

GPT-5.5 has no problem with this. Claude Opus mostly does it, but sometimes it loves to find workarounds rather than following the instructions. Things like: Try alternative commands like egrep. Create a symlink to grep and run that to see if it bypasses the filtering. Run it with a different shell like zsh. Write a Python script that execs grep. Write a Python script to reimplement grep.

I'm trying Hermes Agent at home, but I have it in its own VM with restricted permissions.

[–] bitjunkie@lemmy.world 5 points 2 days ago* (last edited 2 days ago) (1 children)

Just aliasing grep to ag solves both issues. I'm unsure as to whether there's a pthread replacement for find, though.

[–] dan@upvote.au 9 points 2 days ago

ag / rg don't work well in this particular scenario either. Because files are loaded on-demand, they end up trying to load the entire repo.

load more comments (20 replies)