I dont know how to feel about being the only one refusing to run yolo mode until the tooling is there, which is still about 6 months away for my setup. Am I years behind everyone else by then? You can get pretty far without completely giving in. Agents really dont need to execute that many arbitrary commands. linting, search, edit, web access should all be bespoke tools integrated into the permission and sandbox system. agents should not even be allowed to start and stop applications that support dev mode, they edit files, can test and get the logs what else would they need to do? especially as the amount of external dependencies that make sense goes to a handful you can without headache approve every new one. If your runtime supports sandboxing and permissions like deno or workerd this adds an initial layer of defense.

This makes it even more baffling why anthropic went with bun, a runtime without any sandboxing or security architecture and will rely in apple seatbelt alone?

▲

WhyNotHugo 4 hours ago | parent [-]

You use YOLO mode inside some sandbox (VM, container). Give the container only access to the necessary resources.

▲

jdkoeck 3 hours ago | parent | next [-]

But even then, the agent can still exfiltrate anything from the sandbox, using curl. Sandboxing is not enough when you deal with agents that can run arbitrary commands.

▲

TheDong 2 hours ago | parent | next [-]

It depends on what you're trying to prevent.

If your fear is exfiltration of your browser sessions and your computer joining a botnet, or accidental deletion of your data, then a sandbox helps.

If your fear is the llm exfiltrating code you gave it access to then a sandbox is not enough.

I'm personally more worried about the former.

▲

jdkoeck 2 hours ago | parent [-]

Code is not the only thing the agent could exfiltrate, what about API keys for instance? I agree sandboxing for security in depth is good, but it’s not sufficient and can lull you into a false sense of security.

▲

twodave an hour ago | parent [-]

This is what emulators and separate accounts are for. Ideally you can use an emulator and never let the container know about an API key. At worst you can use a dedicated account/key for dev that is isolated from your prod account.

	▲	gessha 11 minutes ago \| parent [-]
		VM + dedicated key with quotas should get you 95% there if you want to experiment around. Waiting is also an option, so much of the workflow changes with months passing so you’re not missing much.

▲

philipp-gayret 2 hours ago | parent | prev [-]

That depends on how you configure or implement your sandbox. If you let it have internet access as part of the sandbox, then yes, but that is your own choice.

	▲	jdkoeck an hour ago \| parent [-]
		Internet access is required to install third party packages, so given the choice almost no one would disable it for a coding agent sandbox. In practice, it seems to me that the sandbox is only good enough to limit file system access to a certain project, everything else (code or secret exfiltration, installing vulnerable packages, adding prompt injection attacks for others to run) is game if you’re in YOLO mode like pi here. Maybe a finer grained approach based on capabilities would help: https://simonwillison.net/2025/Apr/11/camel/

▲

jFriedensreich 2 hours ago | parent | prev [-]

apart from nearly no one using vms as far as i can tell, even if they were, a vm does not magically solve all the issues, its just a part of the needed tools.