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?

Using devicectl 518.33, I need to check only whether two files exist in an installed development app's App Group container, without launching the app, copying the container, or reading file contents. The request uses: device info files --domain-type appGroupDataContainer --domain-identifier group.ru.ordo.app --subdirectory OrdoEnforcement --no-recurse --verbose --json-output /dev/stdout The device was wired and paired. The command returned exit 1, CoreDevice.ActionError code 3. File existence remains unknown. The local help lists appGroupDataContainer but does not specify its domain-identifier contract. Is metadata-only listing of an iOS App Group container supported? What exact identifier and access prerequisites are required? Is there a documented alternative that does not launch the app, copy its container, or read file contents?