Turbo Launcher on macOS

The Turbo Launcher on macOS runs native apps in policy‑driven, isolated sessions. Because it enforces filesystem, networking, and DLP controls at the operating‑system level, it relies on Apple’s Endpoint Security, Network Extension, and File Provider frameworks. These frameworks require components to be approved before they can run — either interactively by the user or, on managed fleets, preapproved through MDM.

This page describes what macOS requires to run the Launcher, what the installer puts in place, the approvals involved on first run, and the recommended enterprise (MDM) deployment.

What You'll Learn

• macOS system requirements and supported hardware
• Which components are installed and why each one exists
• The approvals macOS requires on first run (managed vs. unmanaged Macs)
• The MDM payloads needed for a silent, managed rollout
• Setup‑app states and common troubleshooting

---

System Requirements

Requirement	Details
macOS version	macOS 26 (Tahoe) or later
Architecture	Apple Silicon (arm64)
Disk space	A few hundred MB for the client, plus space for managed app images and sandbox storage
Privileges	Administrator rights (or MDM) to install the package and approve system software
Management (recommended)	User‑Approved MDM (UAMDM) for silent system‑extension and background‑service approval

Managed networking, Endpoint Security enforcement, and Turbo Drive storage depend on Apple frameworks and system‑extension behaviors that Turbo targets on macOS 26 (Tahoe) and later. Earlier macOS releases are not supported.

---

What Gets Installed

The package installs a small set of cooperating components:

Component	Location	Purpose
Sandbox Manager daemon	/usr/local/bin/sandboxmanager launchd plist: net.turbo.sandboxmanager.macos	Root service that owns session lifecycle, policy enforcement, mounts, confidential storage, and the managed‑networking control plane. The daemon is the sole policy authority — user processes can request launches but cannot supply or override policy.
Turbo Setup (setup/repair)	/Applications/Turbo Setup.app	Submits system‑extension activation requests, creates/repairs Network Extension records, and reports whether the Mac is Ready, Needs approval, or Needs reboot.
Turbo Drive host	/Applications/Turbo Drive.app	Hosts the File Provider extension so Finder presents managed storage as Turbo Drive. Also the long‑lived home for ongoing Diagnostics….
System extensions	embedded in the setup bundle	Endpoint Security client, transparent proxy, and content filter (see below).
File Provider extension	embedded in Turbo Drive.app	Registers the Turbo Drive storage domain in Finder.
Policy & config	/Library/Application Support/Turbo/policy.json, .../managed-networking.json	Administrator‑authored fallback policy and managed‑networking configuration.

System extensions

Three system extensions provide the OS‑level enforcement:

Extension	Bundle identifier	Role
Endpoint Security	net.turbo.launch.macos.esextension	Session/process enforcement
Transparent Proxy	net.turbo.launch.macos.neproxy	Managed networking / egress routing
Content Filter	net.turbo.launch.macos.nefilter	Fail‑closed network filtering backstop

These are issued under Apple Team ID CQNYXT2BWD.

---

Architecture, Storage & Network

Processes

Process	Runs as	Lifetime	Role
sandboxmanager (daemon)	root (launchd)	always	Policy authority, session lifecycle, storage mounts, managed‑networking control plane
Endpoint Security / Transparent Proxy / Content Filter extensions	root (system extensions)	always	OS‑level process, egress, and network enforcement
Turbo File Provider extension	user (via fileproviderd)	on demand	Presents Turbo Drive in Finder
Turbo Launcher	user	foreground app	The user‑facing launcher UI
xvm (launch helper)	user	one per managed‑app launch	Prepares the isolated session and launches the managed app
Managed apps (Word, Chrome, …)	user, inside the Turbo sandbox	while open	The actual applications, under policy enforcement

Storage

All Turbo state lives under /Library/Application Support/Turbo/ (root‑owned), plus the apps in /Applications and the per‑user Turbo Drive mount:

Location	Contents
…/Turbo/policy.json, …/managed-networking.json	Fallback policy + managed‑networking config (MDM‑managed preferences take precedence)
…/Turbo/AppProfiles/u<uid>/…	Per‑app encrypted (AES) persistent profiles — app‑private data, caches, temp
…/Turbo/SessionStorage/…	Per‑container storage the Files tab / Turbo Drive browse (shared user documents)
…/Turbo/Sessions/…	Per‑launch ephemeral session state
…/Turbo/ManagedApps/u<uid>/<bundleid>/	Turbo‑prepared copies of managed apps
…/Turbo/Logs/, audit.jsonl	Diagnostics and audit trail
/Applications/Turbo Launcher.app, Turbo Drive.app, Turbo Setup.app	The client, Drive host, and setup/repair apps
/Library/SystemExtensions/…	The activated system extensions (managed by macOS)
~/Library/CloudStorage/…Turbo Drive…	The per‑user Turbo Drive mount shown in Finder

Confidential storage is encrypted at rest and access‑restricted — an ordinary user or process (including the user’s own Finder) cannot read it; only apps launched through Turbo can.

Network & ports

Channel	Exposure	Purpose
Loopback NFS on 127.0.0.1	localhost only — never off‑box	The daemon serves session/container storage to managed apps
Local XPC / Mach services	on‑box IPC only	Launcher, CLI, and extensions talk to the daemon
Managed networking (transparent proxy + content filter)	egress control only — no inbound listener	Routes/filters managed apps’ outbound traffic per policy, optionally via a configured upstream proxy

• Turbo opens no externally reachable listening ports on the endpoint. Session storage is loopback‑only; the enforcement extensions act on outbound traffic.
• Outbound endpoints you configure: your MDM server (enrollment/policy) and, optionally, a Turbo Server/Hub for licensing, policy delivery, and Turbo container package delivery — both administrator‑controlled and unrelated to the on‑box isolation.

---

Approvals on First Run

macOS requires explicit approval before system software can run — granted interactively by the user in System Settings, or preapproved through MDM on managed fleets:

Approval	Seen on a managed Mac?	Seen on an unmanaged/dev Mac?
System extensions (Endpoint Security, proxy, filter)	No — preapproved by MDM	Yes — approve in System Settings › Privacy & Security
Background item for the sandboxmanager daemon	No — locked on by MDM	Yes — a “Background Items Added” notification
Network Extension records	No separate decision after extension approval	Created/repaired by Turbo Setup
File Provider (Turbo Drive) registration	No security prompt	No security prompt
Full Disk Access / Screen Recording	Managed via PPPC/TCC where the policy requires them	Approved manually only if the deployed feature needs them

Don’t disable the background item

If macOS shows a “Background Items Added” notification for Turbo or sandboxmanager, leave it enabled. Turning it off in System Settings › General › Login Items & Extensions stops the daemon — which breaks daemon health, managed launches, Turbo Drive browsing, and network authorization even though the system extensions remain installed. On managed fleets, lock this on with a Service Management profile (below).

---

First‑Run Experience

Managed (enterprise) Mac

On a correctly managed Mac the flow is short and requires no security decisions from the user:

1. IT deploys the package and the MDM approval profiles.
2. IT runs the headless activation command (below), or opens Turbo Setup only for interactive repair.
3. Turbo Setup reports Ready.
4. Finder shows Turbo Drive as a storage provider.
5. The user launches managed apps from Turbo Launcher.

A restart may still be requested after first install, an extension replacement, or a macOS upgrade — the only user action is to restart.

Unmanaged or development Mac

Without MDM preapproval, the user approves the extensions themselves:

1. Install the package.
2. Open Turbo Setup and click Activate & Repair.
3. When prompted, open System Settings › Privacy & Security and approve Turbo system software.
4. If macOS requests a restart, restart.
5. Open Turbo Setup again and click Refresh (or Activate & Repair).
6. Turbo Setup reports Ready.

If Turbo Setup reports a signing, provisioning, or missing‑MDM error instead, that is a build/management problem — approving again will not resolve it. Contact your administrator or install a correctly signed and managed build.

Setup states

State	Meaning	User action
Ready	Installed, activated, and reachable	None
Needs approval	macOS is waiting for local approval	Approve Turbo in System Settings › Privacy & Security
Needs reboot	Activation accepted, restart required	Restart, then reopen Turbo Setup
Needs repair	Components present but config/activation incomplete	Click Activate & Repair
Missing MDM approval	Managed build expects a management profile that isn’t present	Contact IT
Signing/provisioning failure	Build isn’t signed with the required capabilities	Install a corrected build
Background service disabled	The sandboxmanager daemon was turned off or isn’t running	Re‑enable it in Login Items & Extensions, or deploy the Service Management profile

Verifying permissions and versions in Turbo Setup

Turbo Setup surfaces a live readout so an administrator can confirm a deployment without the command line:

• Components lists the required privacy permissions — Screen Recording, Accessibility, and Full Disk Access — with each one’s current grant state. When a permission isn’t yet granted, a Fix button deep‑links straight to the relevant System Settings › Privacy & Security pane. On a managed Mac these are satisfied by the PPPC profile (below) and should read as granted with no action.
• System Extensions lists each Turbo extension (Endpoint Security, Transparent Proxy, Content Filter) with its activated version. If the installed package bundles a newer extension than the one macOS currently has activated, the row flags it as not yet applied and prompts a restart — useful for confirming an extension update actually swapped in after a package upgrade rather than silently staying on the old version.

---

Enterprise Deployment (MDM)

The Launcher is designed for managed deployment. The recommended model has three layers:

1. A package that installs the daemon, apps, extensions, and configuration.
2. MDM profiles that preapprove the system extensions and lock on the background service.
3. The activation flow, run once per enrollment, that submits the system‑extension activation requests.

MDM payload checklist

Payload	Required?	Purpose
Package deployment	Required	Installs the daemon, apps, helper binaries, policy, and launchd plist
System Extensions (com.apple.system-extension-policy)	Required	Preapproves the three extensions by Team ID + bundle ID so users see no prompts
Service Management (com.apple.servicemanagement)	Required on managed fleets	Prevents users from disabling the root daemon (net.turbo.sandboxmanager.macos)
Managed preferences (runtime policy) — com.apple.ManagedClient.preferences	Strongly recommended	Delivers administrator‑authored policy in the net.turbo.sandboxmanager.macos domain via PolicyJSON/PolicyJSONBase64; takes precedence over on‑disk policy.json (details below)
Managed networking config	Required when managed networking is enforced	Supplies proxy/filter bundle IDs and metadata to the daemon
PPPC/TCC — Full Disk Access	Recommended	Grants Full Disk Access (kTCCServiceSystemPolicyAllFiles) to the Endpoint Security extension (net.turbo.launch.macos.esextension) so it can enforce policy across protected locations — part of the standard managed profile set
PPPC/TCC — Screen Recording	Recommended	Lets the Launcher locate managed apps' windows to draw the green managed‑window border, and drives the snipping/screen‑capture feature. Grant to the launcher bundle ID net.turbo.launch.macos.app.
PPPC/TCC — Accessibility	Recommended	Lets the Launcher manage managed apps' windows (position, focus, border tracking). Grant to net.turbo.launch.macos.app.

User‑Approved MDM is required

The system‑extension policy payload is only honored when delivered by User‑Approved MDM (UAMDM). A plain, locally installed configuration profile is not a substitute in production.

System‑extension preapproval

This payload is required. Payload type com.apple.system-extension-policy, allow‑listing the three extensions by Team ID → bundle ID:

<key>PayloadType</key>
<string>com.apple.system-extension-policy</string>
<key>AllowUserOverrides</key>
<true/>
<key>AllowedSystemExtensions</key>
<dict>
  <key>CQNYXT2BWD</key>
  <array>
    <string>net.turbo.launch.macos.esextension</string>
    <string>net.turbo.launch.macos.neproxy</string>
    <string>net.turbo.launch.macos.nefilter</string>
  </array>
</dict>

Use the explicit per‑bundle AllowedSystemExtensions dict (tighter than a blanket team allow‑list). Do not also list CQNYXT2BWD under AllowedTeamIdentifiers — macOS rejects a profile (NSPOSIXErrorDomain 22) that names the same team in both keys.

Launcher privacy (Screen Recording + Accessibility)

A PPPC (com.apple.TCC.configuration-profile-policy) profile grants the Launcher two privacy services so the managed‑window border and window management work without user prompts. Add one identical entry under both kTCCServiceScreenCapture (Screen Recording) and kTCCServiceAccessibility:

<key>Identifier</key>
<string>net.turbo.launch.macos.app</string>
<key>IdentifierType</key>
<string>bundleID</string>
<key>CodeRequirement</key>
<string>identifier "net.turbo.launch.macos.app" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = CQNYXT2BWD</string>
<key>Authorization</key>
<string>Allow</string>

The Launcher uses Screen Recording to locate managed apps' windows so it can draw the green managed‑window border. macOS never prompts for this permission on its own: if the grant is missing, the border simply doesn't appear, which is why granting it via profile (or checking it in Turbo Setup) matters.

Screen Recording must come from MDM

A silent MDM Allow for Screen Recording is honored only from a User‑Approved MDM enrollment — a manually installed profile cannot grant it. On an unmanaged Mac the user must enable Turbo Launcher under System Settings › Privacy & Security › Screen Recording (and Accessibility) and relaunch the Launcher.

Full Disk Access (Endpoint Security extension)

A second PPPC (com.apple.TCC.configuration-profile-policy) payload grants Full Disk Access (kTCCServiceSystemPolicyAllFiles) to the Endpoint Security extension so it can enforce policy across protected locations:

<key>Identifier</key>
<string>net.turbo.launch.macos.esextension</string>
<key>IdentifierType</key>
<string>bundleID</string>
<key>CodeRequirement</key>
<string>anchor apple generic and identifier "net.turbo.launch.macos.esextension" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = CQNYXT2BWD)</string>
<key>Authorization</key>
<string>Allow</string>

Service Management (keep the daemon enabled)

Payload type com.apple.servicemanagement with a Label rule, so users cannot disable the root daemon in Login Items & Extensions:

<key>PayloadType</key>
<string>com.apple.servicemanagement</string>
<key>Rules</key>
<array>
  <dict>
    <key>RuleType</key>
    <string>Label</string>
    <key>RuleValue</key>
    <string>net.turbo.sandboxmanager.macos</string>
  </dict>
</array>

Policy deployment: personal vs. managed

The daemon loads runtime policy only from administrator‑controlled sources, in order:

1. MDM‑managed preferences at /Library/Managed Preferences/net.turbo.sandboxmanager.macos.plist
2. Package fallback policy at /Library/Application Support/Turbo/policy.json
3. Neither present → the daemon runs with an empty deny‑all policy: nothing matches, managed launches are blocked, and the Launcher shows “No applications in policy.”

Before loading either file, the daemon verifies that the file and every parent directory up to / are root‑owned, non‑writable by group or other users, and contain no symlinks. If an MDM‑managed policy exists but fails validation, the daemon fails closed rather than falling back — this prevents a compromised user process from redirecting policy through a writable path.

Two properties hold in both deployment models:

• There is no per‑user policy location. Nothing under ~/Library is consulted, and the Launcher, CLI, and other user processes read the effective policy from the daemon over XPC (turbo policy --json prints it) but cannot supply or override it.
• Policy is applied automatically. The daemon reloads policy when a managed‑preferences profile is published or the fallback file changes; no manual restart is required.

Personal / unmanaged deployment

On a personal Mac the managed‑preferences tier is absent, so policy comes from the package fallback file:

1. The installer stages a starter policy at /Library/Application Support/Turbo/policy.json (owned root:wheel, mode 0644), alongside managed-networking.json.
2. To change policy, edit that file as an administrator (sudo), preserving root ownership and permissions — a user‑writable or symlinked path is rejected. Standard users cannot author or modify policy.
3. The daemon applies the change automatically; verify the effective policy with turbo policy --json.

If the file is removed and no managed preferences exist, the daemon reverts to the empty deny‑all policy — there is no permissive default.

Enterprise (MDM) deployment

On managed fleets, deliver policy as a managed‑preferences configuration profile instead of modifying files on disk. macOS materializes the profile at /Library/Managed Preferences/net.turbo.sandboxmanager.macos.plist, which takes precedence over any on‑disk policy.json.

Profile field	Value
Payload type	com.apple.ManagedClient.preferences (“Custom Settings” in most MDM consoles)
Preference domain	net.turbo.sandboxmanager.macos
Policy key (one of)	PolicyJSON — the policy document as a JSON string, or PolicyJSONBase64 — the same document base64‑encoded (recommended; avoids plist‑escaping issues)
Scope / flags	PayloadScope = System; PayloadRemovalDisallowed = true

Payload content (the daemon also accepts the keys at the top level of the domain):

<key>PayloadType</key>
<string>com.apple.ManagedClient.preferences</string>
<key>PayloadContent</key>
<dict>
  <key>net.turbo.sandboxmanager.macos</key>
  <dict>
    <key>Forced</key>
    <array>
      <dict>
        <key>mcx_preference_settings</key>
        <dict>
          <key>PolicyJSONBase64</key>
          <string><!-- base64 of the policy JSON document --></string>
        </dict>
      </dict>
    </array>
  </dict>
</dict>

After pushing or updating the profile, the daemon applies the new policy automatically; confirm with turbo policy --json. Keep the on‑disk /Library/Application Support/Turbo root‑owned even when policy comes from MDM — it remains the fallback tier and the daemon’s writable home.

Recommended rollout order

1. Deploy the package.

2. Install policy.json and managed-networking.json (or deliver policy via managed preferences).

3. Push the MDM approval profiles (system extensions + service management).

4. Activate the extensions from the setup bundle, once per enrollment:

   "/Applications/Turbo Setup.app/Contents/MacOS/TurboSetup" \
     --activate --force-activate --timeout=180

5. Verify readiness before allowing managed launches:

   systemextensionsctl list | grep -i turbo
   xvm --daemon-health --json --require-managed-networking-ready

If policy requires managed networking and the machine is not ready, launches fail closed by design.

---

Troubleshooting

Symptom	Likely cause	Fix
Activation says the extension has no policy	System‑extension preapproval profile missing or not user‑approved	Enroll through UAMDM, then push the policy profile
“Activation will complete after reboot”	macOS accepted the request but needs a restart	Restart, then click Refresh
Daemon health fails after a “Background Items” notification	The sandboxmanager background item was disabled	Re‑enable it in Login Items & Extensions; on managed Macs deploy the Service Management profile
Network not ready after extensions activate	Network Extension records weren’t created/repaired	Run Activate & Repair again
Finder shows a stale or missing Turbo Drive provider	LaunchServices/pluginkit cached an old extension	Reinstall with the current package to refresh registration

---

Next Steps

• Overview: Launcher features and interface
• Applications Tab: Launch and manage apps
• Files Tab and Secure Sandbox Storage: Turbo Drive storage on macOS
• Runtime Configuration: Secure Sandbox, device, and data‑motion controls
• Proxy Settings and Security & Networking: Managed networking
• Policy System: Author and deliver policy
• Troubleshooting: Full troubleshooting reference