Support native macOS process sandboxes on managed Macs

[shiju-nv]

User Story

As a team deploying OpenShell on managed Macs, we want agents and their tools to run directly as macOS processes with OpenShell's filesystem and network enforcement, so that we can use native tools without maintaining a separate container runtime or Linux guest.

Problem Statement

OpenShell's released MicroVM backend runs Linux workloads on macOS through libkrun and Apple's Hypervisor.framework. It already avoids a separate container runtime, but the workload still needs a Linux guest. OpenShell does not currently provide a released App Sandbox backend for running workloads directly on macOS.

Impact / Why This Matters

Teams whose workloads depend on macOS binaries or Apple SDKs cannot run those tools inside a Linux guest. For example, an agent working on a macOS project may need to invoke the installed Swift toolchain and run the resulting macOS test executable.

Administrators must also provision and update the selected runtime and guest components. Native execution could reduce that maintenance for managed Macs while keeping local agent activity under OpenShell policy. Any startup or memory improvements would need measurement.

Proposed Design

Offer an explicitly selected native macOS backend, initially as an external integration through ComputeDriver. Evaluate Apple's supported App Sandbox APIs as the confinement mechanism.

The user workflow should be:

1. Install a signed native runtime through a documented process suitable for managed Macs, with required permissions and device-management steps explained.
2. Select native macOS execution through OpenShell and supply a host command, working directory and policy. Report unsupported requirements before starting the workload.
3. Run the command and its children with access limited to the accepted policy. Access to files and network destinations outside that policy remains blocked.
4. Use OpenShell to execute further commands, inspect policy decisions and stop or delete the sandbox. Required enforcement must remain active throughout the workload's lifetime.

Acceptance Criteria

• A representative agent task invokes a native macOS tool through OpenShell without a container runtime or Linux guest.
• Filesystem and network allow/deny tests pass for the workload and its descendants, including attempts to bypass the configured proxy.
• Concurrent sandboxes cannot access each other's private files or OpenShell's protected credentials; executable-specific network rules remain enforced.
• Unsupported policies or resource guarantees fail before workload execution with a useful explanation.
• Stopping or deleting a sandbox terminates its descendants. Loss of required enforcement cannot leave workloads unrestricted.
• Installation and updates are documented for supported macOS versions and managed devices, including signing and required permissions. Users can inspect the active protections and policy denials.

Alternatives Considered

The existing MicroVM backend remains useful for Linux workloads and provides a working deployment option today. It does not execute native macOS tools.

Apple Container support (#1887) would integrate another runtime that runs Linux guests. It addresses a different workload requirement.

Running tools directly on the host meets the operating-system requirement but leaves their activity outside an OpenShell-managed native sandbox.

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request

[purp]

Running MacOS inside the sandbox isn't on the near term roadmap. While we're definitely trying to run on all the major OSes, we're keeping the sandbox strictly Linux to maximize workload compatibility across platforms at the moment.