›_ Codex Issues
Codex Issues / #36696

macOS: app-server survives WindowServer restart, then Computer Use cannot launch helper

Open 💬 1 comment Opened Aug 3, 2026 by codeitlikemiley

Version

  • ChatGPT/Codex desktop app: 26.727.40816 (build 6067)
  • Bundled Codex app-server: 0.146.0-alpha.9.2
  • Computer Use helper: 26.727.1000550

Subscription

Not provided

Related issues

Related to #11090, #11278, #34534, #34685, and #36627. Those reports cover parts of this failure class; this report connects a WindowServer/loginwindow reset to an orphaned app-server, loss of the macOS GUI bootstrap context, and the resulting Computer Use LaunchServices failure.

Platform

Darwin 25.5.0 arm64 arm
macOS 26.5.2 (25F84)
MacBookPro18,3, Apple M1 Pro, 16 GB

What issue are you seeing?

Computer Use worked normally after the desktop app launched. After macOS watchdog-terminated and restarted WindowServer/loginwindow, the ChatGPT desktop GUI process disappeared, but its child codex app-server process survived and was re-parented to PID 1. The remote/mobile Codex thread remained connected to that surviving backend.

From that point onward, Computer Use could not start its helper and reported only:

Sky Computer Use service startup request failed

The nested failure is:

SkyComputerUseTransportError: Sky Computer Use service startup request failed
Caused by: failed to dispatch LaunchServices open:
/usr/bin/open exited with exit status: 1

The Computer Use helper is installed and intact at:

~/.codex/computer-use/Codex Computer Use.app

Its bundle ID is com.openai.sky.CUAService, the ARM64 executable is present and executable, and its version is 26.727.1000550. However, the orphaned backend can no longer access a valid GUI bootstrap/LaunchServices context:

open -b com.openai.sky.CUAService
# fails to resolve/launch the application

open ~/.codex/computer-use/Codex\ Computer\ Use.app
# fails with kLSNoExecutableErr even though the executable exists

id -un
# returns the numeric UID rather than the user name

dscl ...
# fails to communicate with Directory Services

launchctl asuser 501 ...
# reports: Reentrancy avoided

/usr/bin/log ...
# reports that getpwuid_r cannot resolve UID 501 and cannot connect to logd

No Computer Use service socket is created. Only the stale/coordination lock file exists:

~/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService/IPC/computeruse.sock.lock

This appears to be a desktop lifecycle/recovery defect. The WindowServer failure was the trigger, but I am not claiming that ChatGPT caused the WindowServer failure. The Codex-specific problem is that the app-server survived the loss of its desktop host and continued accepting remote work without recovering its GUI-session connection or terminating so that it could be relaunched cleanly.

Timeline and evidence

All times below are Asia/Manila (UTC+8).

  • 2026-07-31 06:33:49 — ChatGPT desktop app launched normally.
  • 2026-07-31 06:33:52 — Desktop app spawned bundled codex app-server.
  • 2026-08-01 19:23:59 — Browser automation backend logged as ready.
  • 2026-08-01 19:28:42 — Another browser backend session logged as ready.
  • 2026-08-01 19:29:51 — Browser session activity ended normally.
  • 2026-08-01 19:35:21 — Last desktop log entry; there is no clean quit/shutdown sequence.
  • 2026-08-01 19:35:28 — macOS generated WindowServer-2026-08-01-193528.ips. The watchdog reason says WindowServer's main thread had not successfully checked in for 40 seconds.
  • 2026-08-01 19:35:28-19:35:29 — WindowServer and loginwindow restarted.
  • After the restart — The original ChatGPT GUI process was gone, while its child app-server remained alive, became a child of PID 1, and continued serving the existing remote/mobile thread.
  • Current failed state — Computer Use falls back to a LaunchServices openApplication request because no working host-services pipe is available. That request fails in the orphaned process context and is surfaced as the generic Sky startup error.

The timing establishes a clear state transition: GUI automation was healthy immediately before the WindowServer reset; the desktop GUI did not survive it; the app-server did.

Steps to reproduce

I do not have a safe, deterministic end-user reproduction because deliberately killing WindowServer can disrupt the login session. An internal lifecycle test could reproduce the relevant state without asking users to force a system crash:

  1. Launch the ChatGPT/Codex desktop app and start a thread that is also accessible from a remote/mobile client.
  2. Verify that Computer Use can start its helper.
  3. Terminate or invalidate the desktop GUI host/GUI bootstrap session while allowing its child codex app-server to remain alive. A WindowServer/loginwindow restart was the real-world trigger in this case.
  4. Continue the same thread from the remote/mobile client.
  5. Invoke Computer Use.
  6. Observe that the backend accepts the request but cannot launch com.openai.sky.CUAService; it returns Sky Computer Use service startup request failed.
  7. Observe that the app-server remains alive instead of reattaching to the new GUI session, restarting, or reporting that the desktop host is unavailable.

Expected behavior

If the desktop GUI host or its GUI-session bootstrap disappears, the app-server should do one of the following:

  1. Reattach/reconnect to the replacement desktop host and current GUI session; or
  2. Exit so the desktop app can restart it in a valid session; or
  3. Mark GUI-dependent tools unavailable and tell the remote client that the desktop host must be relaunched.

Computer Use should not continue into a stale LaunchServices context, and its user-facing error should preserve the actionable nested cause.

Actual behavior

  • The desktop GUI disappears.
  • The child app-server survives as an orphan under PID 1.
  • The remote/mobile thread still appears functional.
  • GUI-dependent operations run in a context that cannot resolve the logged-in user or access LaunchServices, Directory Services, logd, or the new GUI bootstrap session.
  • Computer Use cannot launch its installed helper.
  • The visible error is the generic Sky Computer Use service startup request failed, obscuring the host-session failure.
  • Restarting individual Computer Use attempts does not repair the process context.

Suggested product-side fixes

  • Add a parent/desktop-host liveness watchdog to codex app-server.
  • On desktop-host death, terminate the app-server or explicitly enter a desktop host unavailable state instead of continuing with stale GUI capabilities.
  • Re-establish the host-services pipe after a WindowServer/loginwindow or desktop-host restart.
  • Treat a missing/invalid NODE_REPL_HOST_SERVICES_PIPE_PATH or GUI bootstrap connection as a host-lifecycle error, not merely a helper-launch failure.
  • Before using the /usr/bin/open fallback, verify that the process is attached to a valid Aqua/LaunchServices session.
  • Surface the nested LaunchServices or host-session cause in the Computer Use error shown to users.
  • Add an integration test where the desktop renderer/host exits while app-server and a remote client remain connected.

Additional information and attachments

Useful local evidence exists in:

~/Library/Logs/com.openai.codex/2026/07/30/
~/Library/Logs/com.openai.codex/2026/08/01/
/Library/Logs/DiagnosticReports/WindowServer-2026-08-01-193528.ips
/Library/Logs/DiagnosticReports/WindowServer_2026-08-01-193535_*.userspace_watchdog_timeout.spin

The full desktop logs can contain thread IDs, project paths, and other local metadata. The WindowServer spin report contains a system-wide process list. I can provide them privately, but they should be reviewed and redacted before attaching them to a public GitHub issue.

No application bundle, helper executable, or project data was found missing or corrupted. The installed helper is present; this failure is tied to the surviving process's invalid desktop-session context.

Concise maintainer summary

The OS-level initiating event was a WindowServer watchdog restart. The actionable Codex bug is process lifecycle resilience: codex app-server outlived its ChatGPT desktop host and continued servicing a remote thread after losing its macOS GUI/bootstrap context. Computer Use then failed downstream while trying to launch an otherwise valid helper. The app-server should reattach, restart, or fail closed with an explicit desktop-host-unavailable status.

View original on GitHub ↗

1 Comment

toumix-agents · 9 days ago

Additional downstream impact: Metal/PyTorch MPS becomes unusable in the surviving remote Codex worker after the desktop GUI/login context is lost.

Environment

  • Mac mini, Apple M4, 16 GB
  • macOS 26.5.2 (25F84)
  • bundled codex-cli 0.146.0-alpha.3.1
  • Python 3.14.6
  • PyTorch 2.13.0
  • Codex doctor reports filesystem sandbox: unrestricted, approval policy Never, and the stable code_mode_host feature enabled

The machine was purchased specifically as an always-on local Codex compute host. GPU workloads had been run on it previously outside this failed Codex process context.

Trigger / process state

The desktop GUI/login session was lost while the remote Codex thread remained active. The surviving code-execution context now reports:

$ id
uid=502 gid=20(staff) ...

$ id -un
502

$ launchctl manageruid
Could not get manager UID.

$ launchctl managername
Could not get manager name.

Attempts to inspect or enter the normal user's launchd domains fail with error 141 (Reentrancy avoided). Meanwhile, MTLCompilerService processes exist under the real login UID 501, not UID 502.

This matches the invalid bootstrap/Directory Services state described in the issue body, but the failure is not limited to Computer Use or LaunchServices.

Minimal MPS reproduction

PyTorch can enumerate the Metal backend:

import torch

print(torch.backends.mps.is_built())      # True
print(torch.backends.mps.is_available())  # True
torch.ones(1, device="mps")               # fails

The first real GPU kernel launch fails:

RuntimeError: Unable to reach MTLCompilerService.
The process is unavailable because the compiler is no longer active.
Latest invalidation reason:
Connection init failed at lookup with error 141 - Reentrancy avoided

So device/framework discovery succeeds, but shader compilation cannot cross from the surviving UID 502 code host into the UID 501 Metal XPC/bootstrap context.

Impact

Codex Desktop presents the task as local execution with full/unrestricted access, but cannot use the host's Apple GPU. The only functioning architectural workaround is to run Codex separately through a real UID 501 login shell (for example via SSH/CLI), which defeats the purpose of using the Mac as the Desktop app's local compute host and breaks the normal Remote feedback loop.

Expected behavior

After loss or replacement of the desktop/login bootstrap context, the app-server/code-mode host should:

  1. reattach to the valid user/bootstrap session;
  2. restart under a valid host-user context; or
  3. fail closed with a clear desktop host unavailable diagnostic.

An opted-in full-access local task should be able to use user-scoped host services such as Metal, or Codex should explicitly report that GPU access is unavailable rather than allowing mps.is_available() to pass and failing at the first kernel.

Relation to #17644

This is related but appears distinct from #17644. That report concerns Seatbelt/IOKit blocking MLX device enumeration. Here the filesystem sandbox reports unrestricted, PyTorch successfully enumerates MPS, and the failure occurs later at MTLCompilerService XPC lookup because the process has no valid user/bootstrap manager.