4 ms·

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 sol

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.

pianopatrick 3mo ago
You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.
- wrxd 2mo ago
  An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/ https://secretive.dev/
  - pianopatrick 2mo ago
    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.
    - samhclark 2mo ago
      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/5f59f1783e3eaf1a2d4cd8e952bb4acf https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...
      - danielheath 2mo ago
        ... you're getting the agent to sign commits for you without manual intervention?
        samhclark 2mo ago
        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.
        danielheath 2mo ago
        > 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.
        2mo ago
fragmede 3mo ago
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.
- ahk-dev 2mo ago
  [flagged]
gwking 2mo ago
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.
colechristensen 2mo ago
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.
ghjnut 2mo ago
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).
- arianvanp 2mo ago
  okay but that doesn't help a single bit with the OPs point. Your xcode tools do not run inside a docker container
999_cirno 2mo ago
> 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/ https://tart.run/ [2] https://github.com/insidegui/VirtualBuddy https://github.com/insidegui/VirtualBuddy [3] https://developer.apple.com/documentation/virtualization https://developer.apple.com/documentation/virtualization [4] https://github.com/apple/container https://github.com/apple/container
- DrewADesign 2mo ago
  >> 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.
  - 999_cirno 2mo ago
    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
    - DrewADesign 2mo ago
      Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.
      - 999_cirno 2mo ago
        Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes On "Hacker" News of all places :)
theredleft 2mo ago
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.
- saagarjha 2mo ago
  This is more challenging for macOS.
  - danielheath 2mo ago
    I've been doing it just fine on macOS for awhile now. What's challenging about it?
    - mikodin 2mo ago
      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
0xcrypto 2mo ago
A question, how are you or anyone else doing this is registering bundle identifiers without opening xcode?
- NamlchakKhandro 2mo ago
  fastlane
aetch 2mo ago
They should’ve expected that using xAI
LuD1161 2mo ago
[flagged]
justincormack 2mo ago
Use Secretive so your ssh keys are stored in the secure enclave. Keeping private keys in files is the 1990s security…
- MetaWhirledPeas 2mo ago
  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.
  - nedt 2mo ago
    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.
miki123211 2mo ago
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.
mark_l_watson 2mo ago
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.

pianopatrick 3mo ago

You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.

wrxd 2mo ago
An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/ https://secretive.dev/
- pianopatrick 2mo ago
  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.
  - samhclark 2mo ago
    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/5f59f1783e3eaf1a2d4cd8e952bb4acf https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...
    - danielheath 2mo ago
      ... you're getting the agent to sign commits for you without manual intervention?
      - samhclark 2mo ago
        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.
        danielheath 2mo ago
        > 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.
        2mo ago

fragmede 3mo ago

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.

ahk-dev 2mo ago
[flagged]

gwking 2mo ago

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.

colechristensen 2mo ago

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.

ghjnut 2mo ago

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).

arianvanp 2mo ago
okay but that doesn't help a single bit with the OPs point. Your xcode tools do not run inside a docker container

999_cirno 2mo ago

> 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/ https://tart.run/ [2] https://github.com/insidegui/VirtualBuddy https://github.com/insidegui/VirtualBuddy [3] https://developer.apple.com/documentation/virtualization https://developer.apple.com/documentation/virtualization [4] https://github.com/apple/container https://github.com/apple/container

DrewADesign 2mo ago
>> 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.
- 999_cirno 2mo ago
  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
  - DrewADesign 2mo ago
    Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.
    - 999_cirno 2mo ago
      Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes On "Hacker" News of all places :)

theredleft 2mo ago

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.

saagarjha 2mo ago
This is more challenging for macOS.
- danielheath 2mo ago
  I've been doing it just fine on macOS for awhile now. What's challenging about it?
  - mikodin 2mo ago
    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

0xcrypto 2mo ago

A question, how are you or anyone else doing this is registering bundle identifiers without opening xcode?

NamlchakKhandro 2mo ago
fastlane

aetch 2mo ago

They should’ve expected that using xAI

LuD1161 2mo ago

[flagged]

justincormack 2mo ago

Use Secretive so your ssh keys are stored in the secure enclave. Keeping private keys in files is the 1990s security…

MetaWhirledPeas 2mo ago
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.
- nedt 2mo ago
  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.

miki123211 2mo ago

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.

mark_l_watson 2mo ago

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.