Posted by speckx 5 hours ago
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.
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]
[2] https://github.com/insidegui/VirtualBuddy
[3] https://developer.apple.com/documentation/virtualization
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.
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...
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.
Surprisingly, it's very easy. This works like a charm: https://github.com/xtool-org/xtool
You do not need to upload to TestFlight or the App Store; you can just install the app locally to your iPhone via usb -- even from Linux!
When in doubt, just ask your coding agent of choice to help you create and upload a Hello World iOS app. It's really easy.
I should blog about more this, but I also went to some effort to add support free iOS provisioning with just an Apple ID (using internal APIs); and creating a nice DMGs for macOS app distribution (reverse engineered .DS_store files for this). And there's also a built-in command to install skills for coding agents, which was fun.
This [1] is an example app I built with it, a simple utility to manage macOS file extension handling.
In addition to a deep roster of skills and agencts, Axiom includes several for-LLM tools². xclog, xcprof, xcsym, and xcui are designed to be used by LLMs, and expose capabilities in a token-efficient way. These tools are equally helpful for non-Axiom skills/agents.
¹ Axiom: https://charleswiltgen.github.io/Axiom/ ² Axiom CLI tools: https://charleswiltgen.github.io/Axiom/tools/
> I had Claude Code create mine: I told Claude, more or less: I want to archive, Developer ID-sign, notarize, staple, and install this app to /Applications without ever opening Xcode. Write me a script that does the whole chain and fails loudly if any step breaks.
Even though the text we're reading is Claude talking to us as well :)
Also it was weird to see the mention of "ask your LLM" at almost every stage in the blog post:
> point Claude Code or your LLM coding tool of choice to this blog post, and let it figure it out
> When in doubt, ask your LLM of choice about them and have it help you get set up. It’s the one that’s going to be using Xcode for you anyway.
> The whole point of using the LLM in the first place is to avoid doing things manually that you don’t want to do.
> Again, if in doubt, ask Claude Code or your LLM of choice to create this for you.
> Again, this is why you talk to your LLM, tell it what you want, and have it help build your workflow.
If I had to guess, I would say this is the human summarised conversation(s) with a bot.
As for the builds, your agent probably already knows how to do a lot of this from the command line, although explicit suggestions can help it build faster for different situations.
As for XcodeGen, you may find it unnecessary overhead if you're already using Xcode file system synced groups.
For iOS my biggest suggestion would be to enable App Store Connect skills for your agent (https://github.com/rorkai/App-Store-Connect-CLI).
With this not only do you not need Xcode all the time, you also don't even need to be near a MacBook.
Just make changes via Codex on your iPhone, the tell asc to build and upload to TestFlight, download and run the new version, iterate.
Xcode is a [buggy as hell] GUI wrapper for a lot of system-level UNIX utilities and apps [which are generally, not so buggy].
Using CLI to release apps is a pretty old practice; at least as long as I've been doing it (I released my first Xcode app in 2012).
Having spent many years fighting with Xcode professionally, I was thrilled when swift build came out, and then appalled at how badly Xcode adopted it. Eventually I realized that you can set up your entire app as a swift package, and then the Xcode project with a single main source file that calls some `app_main()` (or whatever you want to call it) function in your package.
I cannot remember exactly but there was something annoying about setting up a new project; I think by default Xcode assumes that you want a swift package to be treated as a dependency that is checked out from git, but there was a way to drag and drop a local dependency in the same project directory and then it worked.
What this buys you is that files are no longer tracked by Xcode, so renames/merges no longer trigger project.pbxproj surgery. Instead you specify the swift package directories and are done.
I used this for some large personal projects and was very happy with it.
At one point I also wrote my own build tool that imitated all of the steps that Xcode took so that I could truly be Xcode-free. That also worked (and was not even that hard) but I went back to Xcode because the debugger UI was better than what I could get out of VS Code at the time, and especially because I was playing around with the Metal debugger.
Its basis is React, so the code output quality is much higher than Swift because there is much more React code in LLM training data.
Everything is in the command line, and debugging is a breeze because it's a web view. But once it's compiled to native iOS, it feels like any other native app.
Expo + Fastlane = fully automated iOS submission and deployment. I issue one command and see a new version in the App Store.
Our code broke
It looks like there was an error we need to look at. Sorry about the inconvenience.fwiw, expo seems solid; the uptime of expo.dev won't affect an app built with it.