Installed Xcode ProductBuildVersion 27A9275, SwiftBuild 25000.0.222. Synthetic static Swift framework and three arithmetic XCTest cases only. No real app, account, health data or code-signing identity is needed. A Seatbelt profile allows an exclusively owned child of the normal macOS per-user temporary directory, public SDK/toolchain reads and necessary build services, while denying private-home data and writes elsewhere. Network is denied. The process receives TMPDIR, TMP and TEMP set to that owned child. Fresh DerivedData and result-bundle paths also point inside it. A generic iOS Simulator build-for-testing stops at builtin-infoPlistUtility: mkdtemp tries to create swbuild.tmp.* directly in the per-user temporary parent and returns EPERM. The documented -userdefault=value argument syntax accepts -SWBBuildServiceEnvironmentOverrides='{ TMPDIR = "<owned-child>/"; TMP = "<owned-child>/"; TEMP = "<owned-child>/"; }' but a changed synthetic trial still selects the parent. Acceptance is not proof of the runtime dictionary type or transport adoption. A standalone process under the same profile, using installed Foundation, reports getenv("TMPDIR") as the owned child while both FileManager.default.temporaryDirectory and NSTemporaryDirectory return the parent. The installed SwiftBuild Path.temporaryDirectory implementation calls NSFileManager.defaultManager temporaryDirectory. The out-of-process initializer requires a string-to-string dictionary, then applies it to the child environment. Question for Apple: what supported per-invocation control makes built-in tasks use an explicitly owned temporary child on this version, and what supported no-build diagnostic proves its effective adoption? Is this Foundation behavior expected under Seatbelt? We cannot grant access to the shared parent or private home, change trust/keychain access, inject code, or modify installed libraries. CoreSimulator's separate runtime-availability error is not attributed to this temporary-path issue.