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?