SPM `swift test` fails inside `codewhale` sandbox: `sandbox-exec: sandbox_apply: Operation not permitted`

[ShikiSuen]

Description

swift test (and swift build --build-tests, and xcodebuild test) consistently fail inside CodeWhale's shell sandbox when the Swift Package Manager needs to compile the Package.swift manifest. The swift build command for the non-test target works only because it reuses cached build artifacts and does not need to recompile the manifest.

This makes CodeWhale unusable for any Swift project that relies on swift test for verification — the agent can compile code but can never run a single test.

Steps to reproduce

1. Open a CodeWhale session in a Swift Package Manager workspace.
2. Run swift build — it succeeds (cached artifacts are reused).
3. Run swift test --filter SomeTestSuite in the package directory.
4. Observe that SPM attempts to compile the manifest with swiftc inside a sandbox.
5. The build fails before any test code is reached.

Expected behavior

swift test resolves dependencies, compiles the test target, and runs the tests, just as swift build compiles the main target.

Actual behavior

sandbox-exec: sandbox_apply: Operation not permitted
error: 'vchewing_langmodelassembly': Invalid manifest

The failure happens during SPM's manifest compilation phase:

sandbox-exec: sandbox_apply: Operation not permitted

This repeats for every package dependency (the manifest is compiled multiple times with different vfs overlays), and SPM exits with ExitCode(rawValue: 1) before any test binary is linked.

The same occurs with:

• swift build --build-tests
• swift test
• xcodebuild test -scheme ...
• Setting SWIFTPM_DISABLE_SANDBOX=1 has no effect.

A plain swift build (without test target) works because the package was already resolved and the build directory was populated before the sandbox restriction took effect.

Additionally, several org.swift.swiftpm cache directories are reported as inaccessible:

warning: /Users/.../Library/org.swift.swiftpm/configuration is not accessible or not writable
warning: /Users/.../Library/org.swift.swiftpm/security is not accessible or not writable
warning: /Users/.../Library/Caches/org.swift.swiftpm is not accessible or not writable

Impact

This is the single most workflow-breaking issue I have encountered with CodeWhale. It turns the agent from a verifiable tool into a blind code generator for any Swift project.

In concrete terms:

• swift build succeeds, so the agent can produce code that compiles.
• swift test is blocked by the sandbox on every invocation — swiftc is not allowed to compile the manifest.
• The agent ships untested code. When that code is later run manually by the user, failures surface that could have been caught and fixed in-session if the test feedback loop were available.
• This affects all SPM projects, not just one codebase. Any Swift developer using CodeWhale loses their primary verification mechanism.

Without swift test, the agent is operating with one hand tied behind its back: it can write, it can build, but it cannot confirm correctness.

Environment

• OS: macOS 26 (Tahoe)
• codewhale version: 0.8.50
• Install method: Cargo
• Model/provider: deepseek-v4-pro / DeepSeek
• Terminal app: CodeWhale built-in terminal
• Shell: /bin/zsh
• Xcode: 26.5 (26.5)
• Swift: 6.3

Logs, screenshots, or recordings

P.S.: I dunno whether this issue exists on non-Darwin platforms.

[github-actions]

Thanks @ShikiSuen for the report.

This repository is currently observing a maintainer-managed contribution gate in dry-run mode, so this issue is staying open. When enforcement is enabled, issues from contributors who are not listed in .github/APPROVED_CONTRIBUTORS will be closed automatically.

Please read CONTRIBUTING.md for the expected issue shape. A maintainer can grant issue access by commenting /lgtmi on an issue.

[Hmbown]

Thanks @ShikiSuen for the detailed repro. I reviewed this during the v0.8.52 stabilization pass, and it looks like a real macOS sandbox interaction rather than a Swift-only build issue.

My current read: CodeWhale runs shell commands under macOS Seatbelt (sandbox-exec) in the default sandboxed modes, then SwiftPM invokes its own sandbox-exec while compiling package manifests for swift test / --build-tests. macOS rejects that nested sandbox application with sandbox_apply: Operation not permitted, before the test target itself runs. That also explains why a previously warmed plain swift build can appear to work while test manifest compilation fails.

I am not folding a rushed fix into #2626 because the safe repair needs command/policy routing plus a SwiftPM regression case, rather than weakening the sandbox globally for all macOS commands. Keeping this open as a high-priority sandbox follow-up. For a trusted Swift workspace, running that verification path with full-access sandbox policy/YOLO should avoid the nested Seatbelt failure until we have the proper targeted fix. Sorry this blocks the normal Swift test loop; it is exactly the kind of report we should not close on guesswork.