Building Flutter for macOS doesn't work.

[finnvyrn]

$ fence -m flutter run -d macos

Launching lib/main.dart on macOS in debug mode...
Error: An error occurred when adding Swift Package Manager integration:
  Error: Xcode failed to resolve Swift Package Manager dependencies:
2026-07-09 15:27:44.790 xcodebuild[98572:6382918] Writing error result bundle to /var/folders/cy/7s2q1vb14nz1vbnz9_zxl9480000gn/T/ResultBundle_2026-09-07_15-27-0044.xcresult
xcodebuild: error: Could not resolve package dependencies:
  sandbox-exec: sandbox_apply: Operation not permitted

My AI's analysis:

 Cause in fence source, not your path list.

 What fence actually runs

 ~/my-tmp/fence/internal/sandbox/macos.go
 - WrapCommandMacOS(...) builds shell command:
     - env ... sandbox-exec -p <profile> <shell> -c <command>
 - Source line area:
     - parts = append(parts, "sandbox-exec", "-p", profile, shellPath, shellFlag, command)

 So fence flutter run -d macos means:
 - outer process already inside Apple Seatbelt via fence
 - then flutter -> xcodebuild
 - then xcodebuild tries to run another sandbox-exec for SwiftPM
 - inner sandbox-exec fails with:
     - sandbox-exec: sandbox_apply: Operation not permitted

 Why your config does nothing

 Your config only changes generated profile contents:
 - filesystem rules
 - mach lookup/register
 - network/socket rules

 But failure happens before those matter:
 - second sandbox-exec tries to apply new seatbelt profile
 - kernel rejects nested seatbelt apply

 From fence source:
 - ~/my-tmp/fence/internal/sandbox/macos.go
     - (version 1)
     - (deny default ...)
 - fence always wraps macOS commands in seatbelt
 - schema has no disableSandbox, no per-command bypass, no custom raw profile escape hatch:
     - ~/my-tmp/fence/docs/schema/fence.schema.json

 So:
 - adding /var
 - adding /private
 - adding mach.lookup=["*"]
 - adding allowAllUnixSockets=true
   all irrelevant to this specific error.

 Precise reason

 Not “write denied to /var”.
 Not “missing Mach permission”.

 It is:
 - fence outer sandbox-exec
 - xcodebuild inner sandbox-exec
 - nested seatbelt apply rejected

 Why unfenced works

 Without fence:
 - no outer seatbelt
 - xcodebuild’s own sandbox-exec for SwiftPM can apply normally
 - build proceeds

 Bottom line

 Your fence config cannot fix this. Fence macOS backend hardcodes sandbox-exec -p ..., and Flutter/Xcode SwiftPM also uses sandbox-exec. Two seatbelts collide.

 If you want, next I can point to exact fence source snippets and exact Flutter/Xcode call chain in more detail, file by file.

[jy-tan]

Thanks for the detailed report, the analysis is correct. This is a macOS kernel limitation. Fence wraps the command in a Seatbelt sandbox (sandbox-exec). Xcode's Swift Package Manager integration then tries to start its own sandbox-exec for manifest evaluation, and the kernel rejects applying a second Seatbelt profile to an already-sandboxed process (sandbox_apply: Operation not permitted). Nested Seatbelt sandboxes are not supported by macOS.

Other tools hit the same wall:

• Bazel detects this and silently downgrades to a weaker non-OS sandbox
• Homebrew builds Swift formulas with swift build --disable-sandbox inside its own sandbox for this reason and was blocked when Swift macros added a sandbox layer that couldn't be disabled, until Apple shipped a fix in Xcode 15.3.

I'm not very familiar with the Flutter/Xcode/SwiftPM ecosystem, but it seems there's no flag on flutter run or xcodebuild to disable the manifest sandbox, so the workarounds are config-side (disclaimer: recommended by AI, let me know if this is not favorable):

1. Disable SwiftPM for this project (falls back to CocoaPods, which doesn't use sandbox-exec). In your pubspec.yaml:

   flutter:
     config:
       enable-swift-package-manager: false

   Then flutter clean. See Flutter's docs, including how to remove the already-added SwiftPM integration. Note Flutter is deprecating this opt-out as CocoaPods winds down, so it's a temporary fix.

2. Resolve packages outside fence first, then run the fenced build - SwiftPM caches manifest evaluation, so the inner sandbox may not need to run again. E.g. run flutter build macos --config-only (or a plain flutter run -d macos once) unfenced, then retry under fence. If you try this, let me know whether it works.