We're developing a Mac App Store application that embeds the V8 JavaScript engine (via Electron). The application has shipped successfully on macOS 15.x with the following entitlements:
com.apple.security.app-sandbox= truecom.apple.security.cs.allow-jit= truecom.apple.security.cs.allow-unsigned-executable-memory= truecom.apple.security.cs.disable-library-validation= true
On macOS 26 Tahoe, the exact same signed binary crashes deterministically within ~1.5 seconds on Apple Silicon with EXC_BREAKPOINT (SIGTRAP), ESR 0xf2000000. The crash is in V8's background JIT compilation thread when it attempts to manage memory page protections (transitioning pages between Read-Write and Read-Execute states via mprotect).
The crash does not occur in these configurations:
- macOS 26 + App Sandbox + Intel x86_64 — works
- macOS 26 + Hardened Runtime (no sandbox) + ARM64 — works
- macOS 15.x + App Sandbox + ARM64 — works
This appears to be a regression in how the XNU kernel handles mprotect calls for sandboxed processes on ARM64 under macOS 26, specifically in the context of the allow-jit entitlement.
Has the behavior of allow-jit changed in macOS 26 with respect to runtime code generation memory management on ARM64? Is there a new API or entitlement that V8-style JIT engines should use instead of mprotect-based RW↔RX page transitions?