7/13/2026 at 10:09:44 PM
One down-side to this is that it does require you to run the agent on your Mac instead of in a Sandbox. I do this too and there are lots of problems I can't solve in a sandbox. I know a lot of you are throwing your hands up at the years of security practices we're throwing out the window when we do that.The fact that xAI uploaded someone's home directory, including their SSH keys, is giving me serious pause at my choices here.
Generally, I don't worry about my machine being "blown up". I don't have a TON of unreproducible stuff on my machine. Everything is backed up, committed to git, and the like. I can restore most of it in a couple hours.
That said, I really, really don't want my .SSH directory sent to an AI agent and it's silly to prompt your way around that. You need to block it at the system level. I'm considering a separate user and then 700 permissions on my home directory.
I feel like we're back to 1990's security here. The double-edged sword is that it's helping us get things done at a pace like never before.
I'm not throwing shade here, I'm among the guilty.
by codazoda
7/13/2026 at 10:52:02 PM
> require you to run the agent on your Mac instead of in a SandboxYou 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]
[2] https://github.com/insidegui/VirtualBuddy
[3] https://developer.apple.com/documentation/virtualization
by 999_cirno
7/14/2026 at 1:39:02 AM
>> 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.
by DrewADesign
7/14/2026 at 1:44:26 AM
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 greatBut it is to note that the OS APIs do the heavy lifting, the projects are just wrappers
by 999_cirno
7/14/2026 at 2:10:18 AM
Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.by DrewADesign
7/14/2026 at 5:18:18 AM
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.by pmontra
7/14/2026 at 5:49:50 AM
> RYO is the best way to learn, if you have the time to learnThe problem is that nowadays, people roll their own solution, don’t take the time to learn (somewhat understandably, given the complexity of today’s stuff. You simply cannot learn all details about your hardware, OS, and third-party libraries anymore) but immediately deploy things in production.
Eating your own dog food can be good, but for security related stuff, it can easily be disastrous.
by Someone
7/14/2026 at 1:01:36 PM
Honest question: is there anyone truly good at security who never made a potentially-disastrous dogfooding mistake while learning?Not to decent mistakes or amateur brain surgery, but there has to be some level of risk tolerance among tinkerers.
by brookst
7/14/2026 at 1:59:23 PM
Developing software that has the sole purpose of preventing something dangerous from happening is exactly when people should strive to be engineers, not tinkerers. Beginners often don’t know the difference.by DrewADesign
7/14/2026 at 1:56:21 PM
Learning as you go is great if you’re not basing your core development workflow or data integrity on it.by DrewADesign
7/14/2026 at 2:31:25 AM
Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibesOn "Hacker" News of all places :)
by 999_cirno
7/14/2026 at 1:54:12 PM
Strong “I’ve never had to deal with serious security problems stemming from a weird edge case, so this all seems silly to me” vibes.by DrewADesign
7/14/2026 at 2:43:46 AM
> don't do anything new, god forbid you may actually learn somethingvs
> vibe code your own wrapper around the OS API
by ben_w
7/14/2026 at 2:57:30 AM
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)")
}
})by 999_cirno
7/14/2026 at 2:49:53 AM
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 featuresby iririririr
7/14/2026 at 4:10:50 PM
Setting the convenience knob to very convenient in a system that has a lot more eyeballs on it will always be better than having something that one person who, let’s be real, probably doesn’t even have journeyman-level coding skills, estimates to be very secure based on what the model told them and a quick-skim code review.It’s also a hell of an indictment of this community. FreeBSD is a community project. Qubes is a community project. SELinux is a community project. And people wonder why developers don’t take vibe coders seriously.
by DrewADesign
7/14/2026 at 9:10:40 AM
Does anyone actually use one of those for iOS development?Linux VMs are not relevant here. For downloading Xcode and building apps, I believe one needs to sign in with their Apple account.
Does this work well with a macOS VM?
by user43928
7/14/2026 at 9:17:04 AM
Yes! That is arguably the killer feature. You can virtualize macOS in macOS with (nearly) native speed and this is officially supported. Heck, even can run multiple of them at the same time.See docs here: https://developer.apple.com/documentation/virtualization/vir...
And projects like Tart, VirtualBuddy, etc. provide convenient wrappers for these APIs.
by 999_cirno
7/14/2026 at 9:25:21 AM
The limit is two. You are not allowed to run more than two macOS VMs. Also Tart VMs have problems with signing into icloud and other things that need a real secureID enclave.by fragmede
7/14/2026 at 5:19:11 AM
"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.
by NamlchakKhandro
7/14/2026 at 6:34:26 AM
> It's just a linux vm running normal docker engineOCI compatible, but not docker
https://github.com/apple/container/blob/main/docs/technical-...
Actually makes use of Virtualization.framework mentioned above.
by 999_cirno
7/14/2026 at 5:44:24 AM
How else do you want people to refer to Apple’s tool called container?by sunnybeetroot
7/13/2026 at 10:37:54 PM
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.
by colechristensen
7/13/2026 at 10:31:43 PM
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.
by gwking
7/14/2026 at 9:09:15 AM
Use Secretive so your ssh keys are stored in the secure enclave. Keeping private keys in files is the 1990s security…by justincormack
7/14/2026 at 1:03:49 PM
Genuine question: if the LLM possesses the ability to use Secretive to retrieve secrets are you not back to square 1? I'm not familiar with Secretive but if it's just another way to store secrets that's not enough. For proper security the LLM needs a black box intermediary to do anything privileged. I don't know what that looks like in terms of software.Or better yet it needs dead-end privileges with a system and data that doesn't matter.
by MetaWhirledPeas
7/14/2026 at 5:28:12 PM
They keys are stored in the secure enclave. You can't get them out. You can only let the secure enclave make calculations with it. And it needs your fingerprint to unlock.Akamai akr should be able to do something similar, but would store the private key on your phone. It's the successor of krypton, which was bought by Akamai, and I liked that even more as you really need a second device.
by nedt
7/14/2026 at 10:39:16 AM
There's a spectrum between a restrictive sandbox and full YOLO mode, may 2025 style.You can have something like Claude's auto approvals. You can poke specific holes in the sandbox (E.G. my Codex one can write to ~/go, ~/.cache and ~/.cargo). You can have explicit deny rules that hard-deny and bypass the sandbox and auto-approval. You can allow certain commands to bypass sandbox execution entirely.
While those aren't secure in theory (if you let a third party type prompts into the agent, they will likely be able to exfiltrate your data), they're secure against agent carelessness and AI stupidity in practice.
by miki123211
7/14/2026 at 1:11:54 PM
Well you can use Apple Containers - more convenient than Docker. Alternatively: I am not enthusiastic about Anthropic as a company but I use Claude Code with the three best open coding models (for low cost and speed) and opus when I need it: if you configure Claude Code correctly you protect !/.ssh, etc. I would rather use OpenCode but I am more comfortable with CC (and of course turn off telemetry).re: this article: excellent! I always do about 90% of my Swift dev on the command line and I learned new tricks from the article. Bookmarked.
by mark_l_watson
7/13/2026 at 11:23:44 PM
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.by theredleft
7/14/2026 at 12:50:19 AM
This is more challenging for macOS.by saagarjha
7/14/2026 at 2:02:14 AM
I've been doing it just fine on macOS for awhile now. What's challenging about it?by danielheath
7/14/2026 at 2:39:53 AM
I think particularly for iOS development. I was all in on sandboxed approaches...until I went to build an app, and now unfortunately convenience wonby mikodin
7/14/2026 at 4:19:17 AM
They should’ve expected that using xAIby aetch
7/13/2026 at 10:41:12 PM
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).by ghjnut
7/13/2026 at 11:16:17 PM
okay but that doesn't help a single bit with the OPs point. Your xcode tools do not run inside a docker containerby arianvanp
7/13/2026 at 10:12:50 PM
You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.by pianopatrick
7/13/2026 at 10:35:06 PM
An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/by wrxd
7/13/2026 at 10:47:16 PM
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.by pianopatrick
7/13/2026 at 11:05:37 PM
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...
by samhclark
7/14/2026 at 2:02:57 AM
... you're getting the agent to sign commits for you without manual intervention?by danielheath
7/15/2026 at 1:27:41 AM
Yeah. The agent can create commits and those commits are signed (`commit.gpgsign true`).I'm treating it like...you can hold me accountable for that commit and the commit came from my computer. That feels like the right spirit of things.
How do you do commit signing? I've never worked anywhere it was common, nor worked on a team where anyone else signed commits. I don't know how it's really used in the wild, so to speak.
by samhclark
7/15/2026 at 2:51:55 AM
> I don't know how it's really used in the wild, so to speak.Commit signing primarily exists because linux kernel development happens via email, which isn't a secure channel.
In that context, signing is used to prove provenance; a commit signed by someone with merge rights gets included, and if you repeatedly sign bad code you'll have your right to merge revoked.
> you can hold me accountable for that commit
I wouldn't personally want to be held accountable for a commit I'd never so much as read, so I would never sign (even locally) a commit until I'd looked at it.
by danielheath
7/15/2026 at 3:12:02 AM
Makes sense, thanks for that context. I knew that linux kernel dev happens over email, but didn't piece that together with commit signing.> I wouldn't personally want to be held accountable for a commit I'd never so much as read, so I would never sign (even locally) a commit until I'd looked at it.
I think that's reasonable. I'd say that if I push the commit, then I should be accountable for it whether I read it or not (and no one is going to see it unless I push it).
by samhclark
7/13/2026 at 10:18:46 PM
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.by fragmede
7/14/2026 at 9:46:46 AM
[flagged]by ahk-dev
7/14/2026 at 3:09:16 AM
A question, how are you or anyone else doing this is registering bundle identifiers without opening xcode?by 0xcrypto
7/14/2026 at 5:20:37 AM
fastlaneby NamlchakKhandro
7/14/2026 at 7:35:27 AM
[flagged]by LuD1161