Resolve the Xcode sandbox error that blocks SwiftLint from reading your source files during the build phase, caused by the user script sandboxing build setting.
Your SwiftLint build phase is set up correctly and the binary is found, but the build fails with a sandbox message — something like "Sandbox: swiftlint deny file-read-data" pointing at your source files.
Instead of linting your code, SwiftLint is being blocked from reading it. The build phase runs, but the operating system refuses the file access it needs.
This started appearing for many teams after a change in newer Xcode versions that turns on script sandboxing by default. Setups that worked fine for years suddenly broke after an Xcode upgrade.
It looks alarming, but the cause is a single build setting, and the fix is straightforward.
Recent versions of Xcode introduced a build setting that sandboxes run-script build phases. When enabled, scripts run with restricted permissions and cannot freely read files outside a narrow allowed set.
SwiftLint's whole job is to read your Swift source files across the project. Under the sandbox, those reads are denied, which is exactly what the error message reports.
Apple added this sandboxing to improve build reliability and security by making script dependencies explicit. The trade-off is that tools like SwiftLint, which scan broadly, run into the restriction.
So the tool is not broken and your script is not wrong — the build environment is simply denying the file access SwiftLint depends on.
Open your project in Xcode, select the project or the relevant target, and go to the Build Settings tab.
Use the search box at the top of Build Settings and type "sandbox" to filter. You are looking for the User Script Sandboxing setting, whose underlying identifier is `ENABLE_USER_SCRIPT_SANDBOXING`.
You will typically see it set to Yes on newer projects or after an Xcode-suggested settings upgrade. That Yes value is what is blocking SwiftLint.
Decide whether to change it at the project level or the target level. Project level applies broadly, while target level is more surgical.
Set User Script Sandboxing to No. This restores the previous behavior where run-script phases can read your source files, allowing SwiftLint to scan the project again.
Clean and rebuild with Command-B. The sandbox error should be gone, and SwiftLint should run normally, reporting violations as expected.
This is the most common and direct fix, and for many teams it is perfectly acceptable, since the linter is trusted first-party tooling in their own build.
If you manage build settings through configuration files rather than the Xcode UI, set the same key to NO there so the change is tracked in version control.
Disabling sandboxing is convenient, but it is worth understanding what you are turning off. Sandboxing exists to constrain what build scripts can access, which has genuine reliability and security benefits.
For most in-house projects running a well-known tool like SwiftLint, turning it off is a reasonable and common choice. The linter is code you already trust.
If your organization has strict security requirements, you may prefer to keep sandboxing on and instead move SwiftLint out of the build phase entirely, which we cover next.
The point is to make the decision deliberately rather than flipping the setting without understanding it.
If you would rather keep script sandboxing enabled, the cleanest alternative is to stop running SwiftLint as an in-build script and run it elsewhere.
Many teams run SwiftLint only in continuous integration, where a pull request is checked automatically without touching each developer's local build. This sidesteps the in-build sandbox entirely because CI does not run inside Xcode's script sandbox.
Another option is running SwiftLint manually or via a pre-commit hook, so it lints outside the Xcode build. Developers still get feedback; it just does not happen during compilation.
These approaches trade the convenience of inline Xcode warnings for keeping the sandbox protection in place. Pick based on your team's priorities.
There is a more surgical option than turning sandboxing off entirely. Xcode run-script phases let you declare input and output files, and the sandbox grants access to what you declare.
In practice, broadly listing every Swift file a linter might read is awkward, which is why many teams simply disable sandboxing for the SwiftLint phase instead. Still, it is worth knowing the mechanism exists for scripts with a narrow, well-defined set of files.
SwiftLint's need to scan the whole source tree is precisely what makes strict input declaration impractical for it. A formatter or generator that touches a handful of known files is a better fit for that approach.
Weigh the effort against the benefit. For a trusted linter over your own code, disabling sandboxing on that one phase is usually the pragmatic call, but keep this middle ground in mind for other scripts.
After applying your chosen fix, do a clean build. If you disabled sandboxing, confirm the deny message no longer appears and that SwiftLint violations show up in the issue navigator.
If you moved SwiftLint to CI or a pre-commit hook instead, run that path and confirm violations are reported there. Open a test pull request or run the hook against a file you know violates a rule.
Either way, verify that a genuine violation is actually caught, not just that the error disappeared. A silent linter that reports nothing can look like success while doing no work.
If the sandbox error persists after setting the value to No, make sure you changed it at the level Xcode is actually using, and that no other configuration file re-enables it.
This issue tends to reappear after major Xcode upgrades, which may re-prompt you to enable recommended settings including script sandboxing. When Xcode suggests updating project settings, review what it changes.
Document your team's decision — sandbox off in-build, or SwiftLint in CI only — so new contributors are not surprised when their fresh checkout behaves differently.
Keep build settings in version control where possible, so the sandboxing choice is explicit and reviewable rather than a per-machine mystery.
As always, remember the boundary of the tool. This fix only restores SwiftLint's ability to read and lint your code. It does not affect compiling, signing, or shipping, which Xcode handles and which require an Apple Developer Program membership for release.
Newer Xcode versions enable a User Script Sandboxing build setting that restricts what run-script phases can read. SwiftLint needs to read your source files broadly, so the sandbox denies that access and the build fails.
For most in-house projects running trusted tooling like SwiftLint, it is a common and reasonable choice. If your organization has strict security requirements, consider running SwiftLint in CI instead of disabling the sandbox.
In your target or project Build Settings, search for sandbox. The setting is User Script Sandboxing, identified as ENABLE_USER_SCRIPT_SANDBOXING. Set it to No to let SwiftLint read your files.
Yes. Run SwiftLint in continuous integration or as a pre-commit hook instead of during the Xcode build. You keep the sandbox protection and still get style feedback, just not as inline build warnings.