This isn't too bad if you're running Docker in rootless mode.
Adding a user to the docker group while running Docker as root doesn't really make sense though, since it makes it trivial to run things as root.
This isn't too bad if you're running Docker in rootless mode.
Adding a user to the docker group while running Docker as root doesn't really make sense though, since it makes it trivial to run things as root.
You need to use hooks to actually block it from doing things. CLAUDE.md files are just guidance, and it's not guaranteed to follow everything (and the longer the file gets, the more likely it'll ignore stuff - it should be kept as short as possible)
https://code.claude.com/docs/en/hooks
Hooks are code that runs at a certain point (eg after you submit a prompt, before a tool call, after a turn, etc) that can do some validation, verification, logging, etc.
It does still try to work around the blocks though, but it's not as bad as trying to put the restrictions in the prompt.
Giving Docker access to Claude is certainly a choice.
Unfortunately the search tooling is specific to our internal systems. It's essentially just a cronjob that periodically indexes the entire repo and a backend service to do the search.
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.
It makes sense... There's a LOT of examples of using CLI tools in the training data. At work we're moving away from MCP tools to instead using CLIs for everything.
Claude is very good at figuring out how to work around limitations (which is probably one reason why it's also good at finding security issues).
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.
Claude is very good at figuring out how to work around limitations (which is probably one reason why it's also good at finding security issues).
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.
Interesting... The file sharing is extremely quick for me at home.
I haven't figured out how to get it working at work though (between my work phone and my work PC, both on the same network). Might not be possible with their firewalls.
Have you tried KDE Connect? It's cross platform and works on Linux, Windows, MacOS, Android, and iOS. It's what I use for sharing files from my phone to my computer and vice versa. It supports a lot more than just file sharing though.
Open source is great, but these platforms prove that it is not the only acceptable solution.
Signal is open source, including all their client apps as well as their server. Proton's client apps are open source too (but not their server).
Bitwarden's the only "cloud-based" password manager I trust, since their entire stack is open-source.
For self-hosting, they recently released Bitwarden Lite, which is a lot simpler to host than their regular server. One Docker image and you can use SQLite for the database. Different design decisions compared to the regular server which is designed to scale up to handle businesses with tens or hundreds of thousands of employees.
There's also Vaultwarden, which is an unofficial third-party server implementation.