Followup: filed FB21570087 per Quinn's suggestion. Digging into the behavior for the write-up turned up something my original report missed. The check in xcrun / clang is on the basename of the developer path, not the full path: basename CommandLineTools -> accepted as a CLT install path matches *.app/Contents/Developer -> tried as Xcode (also needs Info.plist + xcodebuild) anything else -> rejected with the "unable to find Xcode installation" error The parent directory isn't checked. My attempt with /Library/Developer/CommandLineTools-26.2.0 failed because of the basename, not the location. Since DEVELOPER_DIR is a per-process env var, not the global xcode-select selection, parallel multi-version CLT actually works: DEVELOPER_DIR=/opt/clt/17/CommandLineTools clang --version # 17.x DEVELOPER_DIR=/opt/clt/16/CommandLineTools clang --version # 16.x Two shells can run these concurrently and each sees its own CLT. /Library/Developer/CommandLineTools can still point at one of them as the default for things like Homebrew that don't read DEVELOPER_DIR. I verified this end to end on macOS 15.7.3 with CLT 26.2.0: xcrun, direct clang, real compile and run, CMake --preset (AppleClang detected fine), Conan 2 install + profile detect, sccache as compiler launcher, ctest. Two parallel processes with different DEVELOPER_DIR each got their own SDK back from xcrun --show-sdk-path. The bug is still worth fixing though: the basename rule is undocumented xcrun behaviour and could break whenever xcode-select -s still rejects non-standard paths even when the basename is right; only the env var path works anything that hardcodes /Library/Developer/CommandLineTools (some Homebrew formulae, random third party scripts) won't pick up DEVELOPER_DIR So for CI and build server setups where you control env per job, there's a workable pattern today. The broader fix is still what FB21570087 is asking for.

Still experiencing this issue on macOS 26 (Tahoe). We are seeing the same storefront region mismatch when testing IAP via TestFlight on macOS. Our observations: Machine-dependent: some macOS 26 machines can complete sandbox purchases, others cannot. Observed working on some 26.2 machines and failing on some 26.3 machines, though we have not confirmed OS version as the sole factor. The workaround of signing out of System Settings > Apple Account > Media & Purchases works, but it also signs out the system account, which is disruptive. The issue appeared after we submitted our build for TestFlight external testing review (public beta). Before that, with internal TestFlight testing only, this was not reported. This follows the same regression pattern others have reported: fixed in 15.2, regressed in 15.3+, and now recurring in macOS 26. Filed as FB22050500 with sysdiagnose logs.

Thank you, Quinn. Your suggestion about using app group IDs worked. After investigation, I found that adding my Team ID-prefixed app group (XXXXXXXXXX.com.mycompany.myapp) to com.apple.security.application-groups in my entitlements resolves both mach-register and mach-lookup without needing any temporary exceptions. Looking at /System/Library/Sandbox/Profiles/application.sb, I can see why this works: (sandbox-array-entitlement "com.apple.security.application-groups" (lambda (suite) ... (allow mach-lookup mach-register (global-name-prefix (string-append suite "."))) ...)) With XXXXXXXXXX.com.mycompany.myapp as the app group, the sandbox allows any Mach service name starting with XXXXXXXXXX.com.mycompany.myapp., which matches Chromium's naming pattern: XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.<pid>. My Developer ID provisioning profile already included XXXXXXXXXX.* in its application-groups, which authorizes any Team ID-prefixed app group. I just needed to explicitly claim it in my entitlements. For Electron developers, here are the specific changes I made to migrate a MAS build to direct distribution with App Sandbox: Set preAutoEntitlements: false in @electron/osx-sign options - The default preAutoEntitlements behavior automatically adds com.apple.developer.team-identifier to entitlements. Even though my Developer ID provisioning profile contains this entitlement, AMFI rejects it: AMFI: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: com.apple.developer.team-identifier This appears to be another certificate-based restriction - com.apple.developer.team-identifier is only honored for Apple Distribution certificates, not Developer ID, regardless of what the provisioning profile authorizes. Add Team ID-prefixed app group to entitlements: <key>com.apple.security.application-groups</key> <array> <string>group.com.mycompany.myapp</string> <string>XXXXXXXXXX.com.mycompany.myapp</string> <!-- Added --> </array> Patch @electron/osx-sign to bypass provisioning profile platform check - By default, osx-sign rejects provisioning profiles that don't match the build platform. I patched util-provisioning-profiles.js to remove this check, allowing my Developer ID provisioning profile to be used with the MAS build. Download Developer ID provisioning profile - When using fastlane sigh, add the --developer_id flag: sigh --platform macos --readonly -a com.mycompany.myapp --developer_id

A further but less important question is that why temporary path is not affected by missing environment variables? If macOS can figure out correct sandbox paths without environment variables, why not all of them doing so?

I finally solved it! It is environment variables that determine the behavior. The helper app was designed to accept some environment variables given by caller, but in our latest developement implementation, only those environment variables are given, without those from electron app. After I added them back, those APIs work as expected. Thanks for your helpful assistance!

Thanks for your kind instructions. I have tried the following steps: I followed your step and reproduced correct behavior. I replaced my helper app with child.app and child.app got /Users/<me> for home. I replaced child.app with my helper app and my helper app got expected home at /Users/<me>/Library/Containers/<app_id>/Data. Now it looks like to have something to do with how helper app is launched by electron app.