Hi @braker1nine! I’m Dosu and I’m helping the tuist team.
This issue happens because Tuist’s sandbox profile allows read access to the selected Xcode app directory, but that isn’t always enough for Xcode’s internal libraries like libxcrun.dylib—especially on CI runners where Xcode installs may be symlinked or have different permissions. When you switch Xcode versions with xcode-select, Tuist dynamically updates the sandbox to include the new Xcode path, but if the sandbox doesn’t explicitly allow access to all required subpaths, you can hit errors like “file system sandbox blocked open()” for dylibs inside the Xcode bundle (source).
Workarounds:
- The quickest fix is to disable sandboxing in your manifest using
disableSandboxinTuist.GenerationOptions, but this is discouraged because it can slow down generation and break manifest caching (docs, issue). - The preferred approach is to avoid file system operations in your manifests and use environment variables for configuration data instead (issue).
- If you must select a non-default Xcode, try to ensure the runner’s Xcode install isn’t symlinked and has standard permissions, or stick to the default Xcode version provided by the runner image.
No recent Tuist changes address this directly, so if you need broader access, disabling the sandbox is the only immediate workaround.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.