[macOS][Computer Use] Device Hub AppKit PID -1: direct executable workaround and request for launch-identity fix

Relationship to existing report

Follow-up to #43386 with additional launch/PID evidence and a concrete workaround. That thread contains reports from three users across physical-device and simulator workflows. This report separates the newly isolated process-identity behavior from the original timeout. If maintainers prefer one tracker, please consolidate this evidence into #43386.

Versions and platform

• macOS 27.0, Apple Silicon; historical successful investigation used build 26A428.
• Xcode 27 RC (27A266a), Device Hub 27.0 (255.2.6.6), bundle ID com.apple.dt.Devices.
• Original end-to-end workaround verification: Codex desktop 26.901.51231.
• Recurrence and host-identity recovery on September 11, 2026: desktop 26.903.71938 (8576).
• Subscription: not recorded in the diagnostic evidence.

Observed behavior

cua.getApp("com.apple.dt.Devices") fails with Computer Use server error -10005: timeoutReached; selecting by name also failed. A real DeviceHub process is alive, but NSRunningApplication.runningApplications(withBundleIdentifier:) reports its processIdentifier as -1. Finder reports a valid PID and can be accessed as a control.

In the earlier investigation, launching through Xcode's Device Hub menu reproduced this mismatch. Opening the internal DeviceHub executable through Finder restored matching process/AppKit PIDs and subsequently restored native discovery, physical-device video and reversible input.

The outer app declares DevicesTrampoline as its executable. The successful entry point was instead:

<Xcode.app>/Contents/Applications/DeviceHub.app/Contents/MacOS/DeviceHub

On desktop 26.903.71938, we again observed a live DeviceHub PID versus AppKit -1. The actor and launch route that created that particular instance were not established. After opening the internal executable through Finder, the process PID and AppKit PID matched again, with isFinishedLaunching == true.

Validation limit: on 26.903.71938 we verified host identity recovery only, not subsequent native discovery, capture or input. End-to-end success belongs to the older desktop version above. These observations do not establish whether the underlying defect belongs to Apple, Codex, or their interaction, nor whether every report in #43386 has this cause.

Read-only diagnostic

Compare the actual executable's PID with AppKit's view. Run these in a normal macOS terminal; a sandbox-denied or empty probe is not evidence of a healthy application.

/bin/ps -axww -o pid=,comm= | /usr/bin/grep '[D]eviceHub'
xcrun swift -e 'import AppKit; for id in ["com.apple.dt.Devices", "com.apple.finder"] { for a in NSRunningApplication.runningApplications(withBundleIdentifier: id) { print(id, a.processIdentifier, a.isFinishedLaunching, a.bundleURL?.path ?? "unknown") } }'

Use the intended Xcode installation (DEVELOPER_DIR when set, otherwise xcode-select -p). Multiple installations/processes or a mismatched path need investigation rather than assuming the first PID is correct.

Workaround for the observed PID mismatch

1. Check whether another session is using Device Hub before quitting its existing instance. Prefer Quit and Keep Simulators Running when offered. A second launcher does not repair an already-running bad instance.
2. In Finder, use Go to Folder to open the intended Xcode's Contents/Applications/DeviceHub.app/Contents/MacOS/ directory, then open DeviceHub itself. Avoid the Xcode menu, the outer .app, and DevicesTrampoline for this workaround. Keep any Terminal launch window open.
3. Repeat the PID comparison. Require a positive matching PID, the intended executable path and finished launching before retrying Computer Use.
4. Verify discovery, capture and reversible input separately. Matching PIDs alone do not prove the full workflow works.

No signed-bundle edits or privacy resets are part of this workaround. Earlier cleanup of duplicate Xcode registrations and Xcode reinstalls did not resolve our original symptom.

Requested Codex update

This has recurred and blocks automated iOS inspection. Please prioritize investigation with the Computer Use maintainers:

• Determine how app resolution/accessibility collection handles a live target whose AppKit PID is -1, and whether a safe PID resolution or launch compatibility fix is possible.
• Replace the generic timeout in this case with actionable diagnostics (invalid app identity, selected executable, and recovery instructions), without automatically terminating a shared Device Hub instance.
• Add regression coverage for Xcode 27 Device Hub across the normal and direct launch paths, including both physical-device and simulator views.
• Please confirm a tracking owner/status and the planned release or ETA for a fix, and document the workaround until that update ships.

Start with the read-only ps and xcrun Swift probes, using the intended Xcode installation and the DeviceHub executable path named in the report. Then locate Codex's Computer Use app-resolution and timeout handling for a live target whose AppKit PID is -1. Done requires actionable diagnostics, safe handling of shared Device Hub instances, and regression coverage for normal and direct launch paths.