[Bug]: `container system start` discards launchctl bootstrap failures, yielding a misleading XPC error in non-login (CI) sessions

[cap10morgan]

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

On a session whose launchd context is not a logged-in user session — a GitHub Actions macos-26 runner reproduces this deterministically:

sudo installer -pkg container-installer-unsigned.pkg -target /
sudo container system start --enable-kernel-install

Output (instant, no retry helps — 15 consecutive attempts fail identically):

Launching container-apiserver...
Testing access to container-apiserver...
Error: internalError: "failed to get a response from apiserver: interrupted: "XPC connection error: Connection invalid""
Ensure container system service has been started with `container system start`.

log show --predicate 'subsystem == "com.apple.container"' over the failure window is completely empty — container-apiserver never launched at all.

Problem description

Two layered problems:

1. The launchctl bootstrap failure is silently discarded. ServiceManager.register (Sources/ContainerPlugin/ServiceManager.swift) pipes launchctl's stdout/stderr to /dev/null and ignores its exit status:

public static func register(plistPath: String) throws {
    let domain = try Self.getDomainString()
    _ = try runLaunchctlCommand(args: ["bootstrap", domain, plistPath])
}

When the bootstrap fails, SystemStart proceeds to "Testing access to container-apiserver..." and dies with a generic XPC error that points the user back at the very command that just failed ("Ensure container system service has been started with container system start"). The actual launchctl error — which names the domain and the real reason — is never shown. This cost us several debugging round-trips chasing the XPC layer before reading the source revealed the ping was doomed before it ran.

2. The computed domain is wrong for sudo-in-a-background-session. getDomainString() maps launchctl managername + getuid(): Aqua → gui/<uid>, Background → user/<uid>. Under sudo in a CI runner's session, that computes user/0/gui/0, which can't be bootstrapped into — so registration always fails there. This is the same class of problem as #1514, but note the service plist already includes System in LimitLoadToSessionType, so the system domain looks intended to be supported.

Suggested behavior:

• At minimum: register() should check launchctl's exit status and surface its stderr in the thrown error. That one change would have made the root cause obvious from the first failure.
• Ideally: when running as root (euid 0) outside an Aqua session, bootstrap into the system domain. We verified this works end to end as a workaround — after container system start writes the plist, running sudo launchctl bootstrap system <plist> and re-running container system start brings everything up (apiserver, machine-apiserver, plugins, kernel install), and Mach lookups chain gui → user → system so the service is reachable from any session. Working example: https://github.com/cap10morgan/whalebridge/blob/7de7456/.github/workflows/ci.yml (the "Start apple/container services" step; also being adopted by ci: replace deprecated tmate with direct launchd system-domain bootstrap socktainer/socktainer#325).

Environment

• OS: macOS 26 (GitHub Actions macos-26 runner image, Apple silicon)
• Xcode: Xcode 26 (runner default)
• Container: container CLI version 1.1.0 (release pkg)

Code of Conduct

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

[rogerneal]

@cap10morgan - Hello! Is anyone working with you on this issue? I'm looking for tickets to contribute to.

[singhible]

@rogerneal As far as I can tell nobody is. It is still unassigned, with no linked PR and no maintainer reply. I have started on the first of the two suggestions in the issue, but if you had already begun, say so and it is yours.

[rogerneal]

Draft PR: #2045

What changed

1. ServiceManager.register now checks launchctl bootstrap status and includes stderr in the thrown error.
2. Root outside Aqua bootstraps into the system domain instead of user/0 / gui/0.

What has been tested

• Unit tests for domain selection (ServiceManagerTests)
• Real launchctl failure through register() with a missing plist (error now names launchctl bootstrap and the status)
• Local Aqua system start: registration loaded the apiserver LaunchAgent and the process started

What has not been tested

• Exact GitHub Actions macos-26 Background / non-login sudo container system start reproduction
• Full healthy XPC / container system status end-to-end in that CI environment

That CI path still needs a macos-26 runner to fully prove the system-domain fix.

[rogerneal]

@singhible - Hello! Do you want to check what I have so far and look at the PR?

[singhible]

Sure @rogerneal, I can take a look.