On macOS 26.6 (25G72), Xcode 26.6 (17F113), xcodebuild -showBuildSettings -json exits naturally with code 74 and reports that the project cannot be read / does not exist.
Minimal control: A synthetic three-file .xcodeproj with one iOS application target, one shared scheme and an internal workspace. It contains no app source, package dependencies, extensions or build scripts. Its plist/XML and object references passed static validation. This does not establish that Xcode accepts the project.
Reproduction outline: Run xcodebuild for this control under a custom sandbox-exec profile, with a clean environment, isolated HOME/cache/DerivedData, Release configuration, iphoneos SDK, generic/platform=iOS, automatic package resolution disabled, signing disabled, and -showBuildSettings -json. No build or device operation is requested.
The profile keeps the control project read-only, restricts access to protected host data, and denies network and Simulator/device services. The exact profile is not attached to this question.
Observed:
- The synthetic control also exits 74 and produces no settings JSON.
- Adding only a literal file-read-metadata allowance for the public data-volume root removed that observed denial, but exit 74 remained.
- Separate Foundation canonical-path and volume-URL metadata queries passed under the resulting policy.
- Owned-process diagnostics did not establish a causal link between another denial and the loader failure.
We have not established the root cause or an Xcode regression. We understand that custom SBPL is not documented for third-party use.
Is there a supported diagnostic interface that exposes the loader's underlying NSError/domain/code at this stage, before building? Do result bundles cover this specific early failure, or is another documented diagnostic method required?