[Bug]: container system status falsely reports apiserver down under Seatbelt sandbox

[renlord]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

Inside the sandbox:
$ container list --all -> works
$ container image list -> works
$ container network list -> works (default 192.168.64.0/24)
$ container run --rm docker.io/library/alpine:latest echo hi -> works end to end
$ container system status
apiserver is not running and not registered with launchd

But the apiserver is plainly running:
$ launchctl print gui/501/com.apple.container.apiserver
state = running
program = /opt/homebrew/Cellar/container/1.2.2/libexec/container-apiserver
pid = 47577

Problem description

container system status (Apple container CLI, Homebrew build 1.2.2) reports the apiserver
as not running whenever the CLI is executed inside a macOS Seatbelt sandbox, even though the
apiserver is running and every other CLI command works. Root cause is the CLI's use of the
legacy launchctl list route, which launchd authorizes with the Seatbelt job-creation
capability - a write/job-submission capability that a read-only status probe should not need.

Environment

- macOS on Apple silicon
- container CLI version 1.2.2 (Homebrew, /opt/homebrew/Cellar/container/1.2.2)
- Caller runs under sandbox-exec with a `(deny default)` profile that allows:
  mach-lookup com.apple.container.apiserver,
  com.apple.container.core.container-core-images,
  com.apple.container.core.machine-apiserver,
  com.apple.container.network.container-network-vmnet.default
  (service names taken from the launchd plists under
  ~/Library/Application Support/com.apple.container/**/*.plist)

Code of Conduct

• I agree to follow this project's Code of Conduct

[shleder]

Great root-cause find. Under a (deny default) macOS Seatbelt profile, launchctl list uses a legacy XPC routine (MIG / xpc_pipe_routine) that launchd gates behind the job-creation MAC hook, whereas launchctl print gui/<uid>/<label> (or querying the Mach service directly via bootstrap_look_up) only requires mach-lookup.

Two clean ways container system status can probe the apiserver without requiring job-creation in caller Seatbelt profiles:

1. Direct XPC / Unix socket health ping first: Since container list and container image list already communicate with com.apple.container.apiserver over its Mach service (mach-lookup com.apple.container.apiserver) or Unix socket, container system status can perform a lightweight ping RPC against the apiserver client directly. If the apiserver responds, it is definitively running even when launchd job introspection is sandbox-restricted.
2. Use launchctl print gui/<uid>/com.apple.container.apiserver (or SMJobCopyDictionary / ServiceManagement) as fallback: Unlike launchctl list, launchctl print targets the specific service domain/label and provides state = running and pid = ... directly.

We hit this exact Seatbelt job-creation denial when running CLI tools inside Vetto's macOS libsandbox profiles (Shape D), where granting job-creation is unsafe because it allows sandboxed agents to persist arbitrary LaunchAgents on the host.

Disclaimer: I am the author/maintainer of Vetto, an open-source kernel sandbox runtime for AI coding agents.

[humairaambreen]

I’m working on this in apple/container. I’m checking the existing health ping before launchd registration, so a Seatbelt restriction on launchctl list can’t mark a responsive apiserver as down. I’ll follow up with the regression test and results.

[humairaambreen]

I moved the health ping ahead of the launchd check and added coverage for the responsive, registered-but-unresponsive, and unregistered cases. SystemStatusTests passes on Xcode 27 (10 tests), and the two changed files pass the repository formatter. I’m preparing the PR now.