281–290 of 419 posts
What is the main benefit over doing something like: docker run --runtime krun --rm -it -v $(pwd):/workspace/$(basename $(pwd)) -w /workspace/$(basename $(pwd)) --network restricted-net ghcr.io/openai/codex-universal:latest sh That runs the codex OCI in a qemu microvm. From what I can see, more fine grained network and filesystem access control as well as convenience?
A Docker container is not a strong security boundary.
Since everyone is sharing their setup, here’s my approach, just to give people an idea of how others are doing it, however impractical it might look: I run a full Linux VM (with a GUI) on my Linux host. I connect via virt-viewer to run Claude Desktop, as I’m not a fan of using the terminal for this. The VM sits on its own libvirt network in a dedicated firewall zone, and specific directories are shared via filesystem…
Do you find the permanence of a full VM useful? I’ve wondered about something like this but always defaulted to Docker for much the same reasons people use stuff like Ansible. I’m afraid the LLM will heavily customize its environment and I’ll be unable to replicate it when my laptop dies or I can’t upgrade the OS or whatever. Then again, I guess GUI is a pain in Docker. I tend to operate through Zed and an ACP harnes…
Models start going to extreme, damaging lengths to achieve ambiguous prompts[0]. Having good sandboxes is now a must IMO. But sbx is a bit annoying to use with OpenCode for instance (which has zero sandboxing by default, unlike codex CLI or Claude Code). You cannot easily change ~/.config/opencode/opencode.jsonc AFAIK. [0]: Black Hat OpenAI-Hugging Face incident: https://www.youtube.com/watch?v=87DyyMV0kCY&t=1021s
My startup (https://github.com/gofixpoint/amika) copies agent configs into local or cloud sandboxes
We run OpenCode currently, but need to improve the setup for users, so would like understand more of the issues you have sandboxing it, if you can share
https://www.mrafayaleem.com/blog/sandboxing-claude-cli-with-...
I know some people want to run their agents when their computer is off, but I imagine a solution like this will be much more common than paying for a remote sandbox (i.e on fly.io or exe.dev), especially because it'll be free. Though, they need to remove the login requirement.
1. You can run sandboxes locally
2. You can control them securely over the internet, for when you're on the go
3. You can migrate them to cloud VMs if you want
Still early and the local sandboxes are experimental right now
Does anyone have a solution for iOS development? I was all in on sandboxes and safehouse for my agents but the moment I got into iOS development it felt like my hand was forced to just run Claude / codex / pi directly on my machine because nothing else could do the dev loop. It’s been a painful reality for me, I’m going against core pieces of how I feel I should be interacting with agent harnesses and yet, I need to…
1) Enable the xcode mcp server: https://developer.apple.com/documentation/xcode/giving-exter... 2) Add the xcode mcp server to sbx: `sbx mcp add xcode --command xcrun --args mcpbridge` 3) When you create the sandbox, use `--static-mcp xcode`. For example: `sbx create --static-mcp xcode claude .`
Make sure you have at least v0.38.0 of sbx. This makes a bridge from inside the sandbox to the xcode tools on your host, so be aware that it can run whatever tools you give it on the host. But the agent itself is still sandboxed.
Earlier quoted context omitted.
I use Linux Containers managed by Incus for working with Claude. I have a dedicated container for that. It can run its own Docker daemon and other system services if needed. Apart from the Claude login token, it has no SSH keys or other credentials. I push everything I need to it from the local machine. And I pull the Claude generated outputs from it. Of course, this kind of setup requires a stack which can run or at…
Love Incus and I'm using throwaway restricted projects for testing. Highly recommend incus-windows if you need to do any Windows testing. Having agents validate Windows behavior has reduced so much toil for me.
The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…
It also provides a nice TUI for network policy management and prebuilt sandboxes which have claude code, codex, etc.