"Not sandboxing is not the same as not caring. It's trading one boundary you can't use for another one you build and can prove."
Why the Sandbox Doesn't Fit
The macOS App Sandbox is built around user-selected security scopes: an app gets access to a file because the user picked it in an open panel or dragged it in. That model is perfect for a text editor opening one document. It is fundamentally wrong for a file manager, whose entire job is to browse local disks, external drives, and network shares continuously and freely. You cannot ask the user to individually grant every folder on every volume. The sandbox's core assumption breaks against the product's core purpose.
A Deliberate, Documented Choice
So Waygate is deliberately not sandboxed. This is legal precisely because Waygate is directly distributed — not through the Mac App Store, where the sandbox is mandatory. Apple documents both postures; direct distribution may choose the unsandboxed one when the app's purpose requires broad file access. This isn't a shortcut or an oversight; it's a documented architectural decision recorded in the invariants, made because a Finder replacement can't function inside per-file scopes.
The Compensating Boundary Is Strict
Removing the sandbox removes a boundary, so Waygate builds a strict one to compensate. It's signed with a stable internal codesign identity and a stable designated requirement, verified strictly with no ad-hoc fallback. It runs as the user's normal account — no root, no privileged helper. It executes no arbitrary shell, AppleScript, plugin, or downloaded code. Every mutation still crosses the journaled engine. And it surfaces macOS privacy and ACL denials rather than trying to bypass them. If the distribution model or threat assumptions ever change, re-sandboxing is an invariant change, deliberated and documented — never a quiet build-flag flip.