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.