Skip to content

[Bug]: Headless GUI launchctl exit 125 prevents service-manager absence proof #7697

Closed

Description

@vibewriter-hand

Client or integration

Codex CLI

Area

Service lifecycle

Summary

On a headless macOS session, launchctl print gui/<uid>/<label> can exit 125 with Could not print domain: 125: Domain does not support specified action. The service-manager probe returns unknown immediately, before it checks the independent user domain or the plist on disk.

Expected: recognize this GUI-domain response, continue to the user-domain query, and retain the existing plist and ownership checks. A user-domain failure, timeout, or spawn failure must still return unknown.

Reproduction

  1. In a headless macOS user session, run /bin/launchctl print gui/$(id -u)/com.opencodex.proxy. The observed status is 125 and the error is quoted below. A user-domain query in the same session answers 113 when the service is absent.
  2. From a source checkout, the following isolated reproduction uses the public probe with those measured responses. It does not query or change the host service manager:
import { mkdtempSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";
import { inspectServiceManagerInstallation } from "./src/service-manager-probe";

const home = mkdtempSync(join(tmpdir(), "ocx-headless-repro-"));
console.log(inspectServiceManagerInstallation({
  platform: "darwin", uid: 501, home,
  run: (_file, args) => ({
    status: String(args[1]).startsWith("gui/") ? 125 : 113,
    stdout: "", stderr: "", timedOut: false, spawnFailed: false,
  }),
}));

Actual: { kind: "unknown", reason: "launchctl print exited 125: " }.
Expected: { kind: "absent" }, after both domains are checked, because the isolated home contains no plist.

The same early return prevents the probe from reporting the homes in a staged plist. A focused regression run against unmodified dev runtime code produced three expected failures and one passing negative case: absence, staged-plist retention, and detection of a loaded user-domain job fail; a user-domain 125 remains unknown.

Version

Reproduced against dev commit 26598df2c4c07d781e344ac6119953fed77ecb27 (package version 2.93.0). The published 2.92.0 source also lacks GUI-domain exit-125 handling.

Operating system

macOS 26.5.2, arm64, headless user session.

Provider and model

Not provider-specific.

Logs or error output

GUI-domain query: exit 125
Could not print domain: 125: Domain does not support specified action

Isolated regression run (Bun 1.4.3):
1 pass, 3 fail, 96 filtered out; 4 tests across 1 file.
Expected kind: absent; received kind: unknown.

Screenshots and supporting files

Source: inspectLaunchd at the reproduced commit.
Related but distinct: #6948 concerns a registered Desktop login item that is not yet loaded. This report concerns the GUI domain rejecting the probe itself.

Redacted configuration

No provider configuration is required. The isolated reproduction uses an empty temporary home and synthetic service-manager replies.

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. added
    bugSomething isn't working
    guiDashboard, tray, settings UI
    serviceService lifecycle (WinSW/launchd/scheduler)
    on Oct 24, 2026
  2. Ingwannu commented on Oct 25, 2026

    @Ingwannu
    Owner

    The supplied isolated reproduction identifies a narrow absence-proof gap: the unreachable GUI domain currently prevents examination of the independent user domain/plist. Draft #7710 is the linked candidate, but it currently targets the wrong branch and is not an integrated fix.

    Please keep the change limited to the measured GUI-domain outcome. The user domain must still be queried, the existing plist/ownership evidence must still be checked, and a user-domain error, timeout or spawn failure must remain unknown. Include those refusal controls alongside GUI-125 plus user-113 plus no-plist. Treating every nonzero launchctl status as absence would defeat the recovery boundary.

    No live launchctl/service change or macOS reproduction was performed on this Linux host. Keeping the issue open pending the corrected dev-targeting candidate and current-head verification.

  3. lidge-jun commented on Oct 30, 2026

    @lidge-jun
    Owner

    Resolved on dev by #7745 (fb81e53e96). PRs into dev do not auto-close linked issues, so this was closed manually. The fix ships with the next release cut from dev; please reopen if it still reproduces on a build that contains it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingguiDashboard, tray, settings UIserviceService lifecycle (WinSW/launchd/scheduler)

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions