This is not privilege separation/sandboxing. Separate virtual machine for an agent with limited credentials is reasonably safe approach
I built www.propelcode.app with separate Linux containers, unless you disconnect the container and your computer from the internet the models can escape the sandbox and get information off of your machine. I am open to being corrected and learning from you if you have a better method of sandboxing
The best way to use LLMs is via tmux where it's running on a disposable VM. 0 chance of it getting information from your local machine.
Why are important push secrets in a dev env config? Btw humans devs make this same mistake all the time.
umm lots of providers have cli tools: ‘heroku run rails db:drop —-app {name}’ railway, fly.io etc. so unless you don’t ever use their cli tools locally there’s a vector. Plus CI/CD might also have credentials to do things like run migrations.
Well that’s a developer problem, then. We use fly but prod secrets are not saved locally.
The harnesses we have are almost stunningly incomplete IMHO. I've been trying `pi` recently, and quite like that it comes with a minimal set of tools by default -- and that I can easily override or replace the ones that it ships. I've only just started working with it, but clamping `read/write/edit` to only allow editing files in the current directory, banning `bash` and mandating I write tools for the specific comma…
One of the problems with tools is the permissions for them. I can either grant Claude access to this one specific python command, or free run with python to do whatever it wants, but not “you can execute the python scripts in this directory structure”. Claude’s “api access required” approach means that I can’t even experiment with customising the harness without doubling up…
Yes, that aggravates me too. I noted recently, Claude had a phase where it would write little one-off Python scripts to aid it in analysis -- which is super useful! But when it's written ten scripts in a row, each of which I've had to review and each of which I've had to approve by hand, it gets pretty annoying. If I could bless it with "if it only uses these Python libraries, pre-approve the script", that would've made life a lot simpler, but of course, that's not possible. Sigh.
I built www.propelcode.app with separate Linux containers, unless you disconnect the container and your computer from the internet the models can escape the sandbox and get information off of your machine. I am open to being corrected and learning from you if you have a better method of sandboxing
The best way to use LLMs is via tmux where it's running on a disposable VM. 0 chance of it getting information from your local machine.
I am using tmux but not disposable vm. I have thought about something like that but honestly some of the debugging work makes ephemeral environments hard to work with. How are you doing that in your workflow?
umm lots of providers have cli tools: ‘heroku run rails db:drop —-app {name}’ railway, fly.io etc. so unless you don’t ever use their cli tools locally there’s a vector. Plus CI/CD might also have credentials to do things like run migrations.
Well that’s a developer problem, then. We use fly but prod secrets are not saved locally.
The answer is in the introduction: > Claude Code is running in production across multi-million-line monorepos, decades-old legacy systems, distributed architectures spanning dozens of repositories (…) So it is optimized for the general case, using robust tooling that works everywhere, especially when large & messy. That being said, your remark is right and for well organised smaller repo’s there’s better tooing it ca…
But the general use case is not the most efficient for a greenfield to-be fully managed by an agentic system code-base. It is built to be good around the scaffold(programming like humans) and not the actual problem space. Anthropic's target should be a codebase designed for agentic comprehension from the first commit. Here the codebase adapts to the agent. You can enforce conventions, structured metadata, semantic in…
So if 100k codebase is considered large, this is how i do it. I keep a documentation folder, one for the backend one for the frontend and i try to keep these as up to date as possible. So every time i start a new feature or try to fix a bug, i tell claude to read what it needs from the documentation first and mention the thing we need to focus on. I dont know if the focus on documentation is even needed that much but with this flow i have seen claude sucessfully do some pretty complicated stuff and not a problem with exploring the codebase.