upvote
> require you to run the agent on your Mac instead of in a Sandbox

You don't have to! All recent Macs come with nearly zero perf cost virtualization. You can easily run Mac or Linux VMs assuming same architecture. Use it all the time for development and whatever.

Use Tart [1] or VirtualBuddy [2], both open-source, for a packaged solution. Or in the spirit of this post, vibe code your own wrapper around the OS API [3]

More recently, there are also Apple containers [4]

[1] https://tart.run/

[2] https://github.com/insidegui/VirtualBuddy

[3] https://developer.apple.com/documentation/virtualization

[4] https://github.com/apple/container

reply
>> I feel like we're back to 1990's security here.

> vibe code your own wrapper around the OS API

Maybe stick with one of the existing projects? Throwing out all of the edge cases and hardening that went into a security-related project just to burn a bunch of resources to generate a worse one you have to maintain yourself is 90s-level security with 2026-level inefficiency, IMO.

reply
Of course, if you're not comfortable with reading or designing code, or don't feel like tinkering, you can use an existing project and they work great

But it is to note that the OS APIs do the heavy lifting, the projects are just wrappers

reply
Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.
reply
RYO is the best way to learn, if you have the time to learn. After building one own solution one is able to assess the strengths and weaknesses of what other more experienced people built. Without the learning phase those other solutions are incomprehensible black boxes. The trick is not to skip the phase in which one researches available solutions.
reply
Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes

On "Hacker" News of all places :)

reply
> don't do anything new, god forbid you may actually learn something

vs

> vibe code your own wrapper around the OS API

reply
In fact, I suggest reviewing the documentation to assess your own level:

https://developer.apple.com/documentation/virtualization/run...

If the below sounds too complex to work with, can review more basics first. Can start with a Swift tutorial

  virtualMachine.start(completionHandler: { (result) in
      if case let .failure(error) = result {
           fatalError("Virtual machine failed to start with \(error)")
      }
  })
reply
all community projects (specially the ones maintained or opensourced by model owners) will certainly have the security-convenience trade offs set all the way to convenience while advertising all the (off by default) security features
reply
"Apple Containers"

I love how people say this like Apple finally created a native solution...

They didn't. It's just a linux vm running normal docker engine.

reply
How else do you want people to refer to Apple’s tool called container?
reply
I've been working on a wrapper harness that runs claude as a separate user named `agent`. I tried this about a year ago and couldn't get it to work because of OAuth and the keychain, but took another pass recently and claude had enough self-knowledge about recent changes to say we could do it with CLAUDE_CODE_OAUTH_TOKEN. It has required building a some tooling around permissions setup with ACLs but it works on macOS today.

In terms of risk, I see it as halfway between stock claude with the sandbox and full-blown container or machine isolation.

I was recently thinking that as Claude's own sandbox gets better I'm doubting the ROI on my belt-and-suspenders project, but your comment reminds me why I'm doing it.

It is not currently published open source but I'm happy to talk about it with strangers.

reply
They should’ve expected that using xAI
reply
I run my AI headless in a docker container and give it access to git – it can only contribute code - when it needs a secret I put it in a docker container in vault. when it needs infra, it makes me a jira ticket. that's my workflow.
reply
This is more challenging for macOS.
reply
I've been doing it just fine on macOS for awhile now. What's challenging about it?
reply
I think particularly for iOS development. I was all in on sandboxed approaches...until I went to build an app, and now unfortunately convenience won
reply
A question, how are you or anyone else doing this is registering bundle identifiers without opening xcode?
reply
I've been running my agents in a docker sandbox that automatically mounts the current directory. It's been a bit of a pain to figure out and maintain the set of tools I provision into the sandbox- but it's fun to watch codex go to the ends of the earth trying to figure out solutions using nodejs (the only runtime).
reply
okay but that doesn't help a single bit with the OPs point. Your xcode tools do not run inside a docker container
reply
You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.
reply
An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/
reply
Seems to me a tool like that would stop the agent from sending those specific keys elsewhere. But a tool like that would not stop the agent who is acting as you from using the SSH keys via the CLI. You would want to combine that with other tactics like having the agent run as some other user.
reply
Secretive (and the similar built-in functionality [1]) both allow you to require TouchID too. I found an okay balance using two SSH keys: one for commit signing (w/o TouchID) and one for everything else (requires TouchID, or PIN on Linux)

So, the actions that I really don't want the agent to take (establishing an SSH connection, pushing to a git remote) always require my manual intervention.

[1] https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...

reply
... you're getting the agent to sign commits for you without manual intervention?
reply
Your sandbox can be a separate Mac user account.

You can also use native Mac VMs.

Many people have created Mac VM projects to do exactly this, I was working on one but was stalled too often because before I started using claude I bought a new laptop with what I KNEW was enough disk space.

The 100 GB or so I need to comfortably do the VM stuff just isn't available on my mac.

reply
On a Mac. Just get a Mac mini. It doesn't have to be a crazy big beefy one, and if you're selling apps, it's a justifiable business expense.
reply