3 ms·
Opus 4.6 is outstanding for code, and for the little I have used it outside of that context, in everything else I have used it with. The productivity with code
by K0balt 8mo ago
Opus 4.6 is outstanding for code, and for the little I have used it outside of that context, in everything else I have used it with. The productivity with code is at least 3x what I was getting with 5.2, and it can handle entire projects fairly responsibly. It doesn’t patronize the user, and it makes a very strong effort to capture and follow intentions. Unlike 5.2, I’ve never had to throw out a days work that it covertly screwed up taking shortcuts and just guessing.
- renmillar 8mo agoThat last part is a real one though, mine tried to debug a Dockerfile by poking around my local environment outside of Docker today.
- josephg 8mo agoI’ve had it make some pretty obvious mistakes. I have to hold back the impulse to “unstick” it manually. In my case, it’s been surprisingly good at eventually figuring out what it was doing wrong - though sometimes it burns a few minutes of tokens in the process.
- tiltowait 8mo agoClaude's willingness to poke outside of its present directory can definitely be a little worrying. Just the other day, it started trying to access my jails after I specifically told it not to.
- teaearlgraycold 8mo agoFor the moment it’s best practice to run it and all of your dev stuff in a VM.
- e1g 8mo agoOn a Mac, I use built-in sandboxing to jail Claude (and every other agent) to $CWD so it doesn’t read/write anything it shouldn’t, doesn’t leak env, etc. This is done by dynamically generating access policies and I open sourced this at https://agent-safehouse.dev https://agent-safehouse.dev
- nowahe 8mo agoBy any chance, do you know what Claude Code's sandbox feature uses under the hood and how that relates to your solution ? From what I remember it also uses the native MacOS sandbox framework, but I haven't looked too deep into it and don't trust it fully
- e1g 8mo agoClaude Code sandboxing uses the same basic OS primitive but grants read access to the entire filesystem and includes escape hatches (some commands bypass sandboxing). Also, I wanted something solid I can use to limit every agent (OpenCode, Pi, Auggie, etc).
- qalmakka 8mo agoOn Linux in a pinch you can use bubblewrap to hide and replace directories for a given process
- caspar 8mo agofor anyone reading this later, claude code's sandbox code is at https://github.com/anthropic-experimental/sandbox-runtime/ https://github.com/anthropic-experimental/sandbox-runtime/
- danw1979 8mo agoThis is great ! Did you have any thoughts about how to restrict network access on macos too ?
- e1g 8mo agoI haven’t found an easy way, but I have a working theory - sandbox-exec cannot filter based on domain names, but it can restrict outbound network connections to a specific IP/port (and drop the rest). If I can run a proxy on localhost:19999, I can allow agents to connect through it and filter connections by hostname. From my research, most agents support $HTTP_PROXY, so I'll try redirecting their HTTP requests through my security proxy. IIRC, if I do this at the CONNECT level, I don't need to MITM their traffic nor require a trusted root cert. Recently, Codex CLI implemented something like DNS filtering for their sandbox, so I'd investigate their repo.