141–150 of 248 posts
Earlier quoted context omitted.
Running a Mac without an Apple ID feels like an exercise in masochism. I wasn’t aware one could even still it through first run without
Why do you need one?
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 ch…
> 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]…
> 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.
Earlier quoted context omitted.
> 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]…
>> 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.
But it is to note that the OS APIs do the heavy lifting, the projects are just wrappers
To anyone who's chased a crash that only reproduces on a physical device knows the fix was never more log statements added by ai but rather a breakpoint, the debugger, and thirty unglamorous minutes of stepping through code line-by-line (terminal lldb technically counts, but barely).
IDEs are dead, prove me wrong.
Earlier quoted context omitted.
Does the iPhone need to remain tethered if it is transferred via USB?
Dev apps need to be re-loaded every week (or two?) last time I did sideloading. The idea behind a dev app, in Apple's mind, is that it is for limited testing, so they have an expiration when not signed/installed through the App store.
Earlier quoted context omitted.
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.
This is more challenging for macOS.
Earlier quoted context omitted.
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.
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.c…
Earlier quoted context omitted.
>> 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.
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