2 ms·

For anyone reading this later. I read a little from sandvault and they suggest sandbox-exec doesn't allow recursive sandboxing, so you need to set flags on xco

For anyone reading this later. I read a little from sandvault and they suggest sandbox-exec doesn't allow recursive sandboxing, so you need to set flags on xcodebuild and swift to not sandbox in addition to the correct SBPL policy. (I don't think sandvault has a swift/xcode specific policy because they're dumping everything into a sandvault userspace. And it doesn't really concern itself with networking afaict either.)

e1g 7mo ago
Yes, you're correct about 'no nested sandboxing'. This also applies to sandboxing an Electron app: Electron has its own built-in sandboxing via sandbox-exec, so if you're wrapping an Electron app in your own sandboxing, you have to disable that inner sandbox (with Electron's --no-sandbox or ELECTRON_DISABLE_SANDBOX=1). In the repo, I have examples for minimal sandbox-exec rules required to run Claude Code[1] and VSCode[2] (so you can do --dangerously-skip-permission in their destop app and VSCode extension) [1] https://github.com/eugene1g/agent-safehouse/blob/a7377924efadf5e3b9eac6924dcf979f1dec0f8e/profiles/65-apps/claude-app.sb https://github.com/eugene1g/agent-safehouse/blob/a7377924efa... [2] https://github.com/eugene1g/agent-safehouse/blob/a7377924efadf5e3b9eac6924dcf979f1dec0f8e/profiles/65-apps/vscode-app.sb https://github.com/eugene1g/agent-safehouse/blob/a7377924efa...