[macOS] Native Computer Use PiP repeatedly disappears after updates: stale helper registration, failed reconnects, recovery after enabling menu bar

Sanitized incident history: recurring native Computer Use PiP failure

Scope and confidence

This appendix reconstructs an earlier verified recovery and a later recurrence from retained command results, signed-bundle inspection, desktop logs, macOS unified logs, process samples, static code inspection, and visible-preview acceptance. The reporter describes many recurrences, including dozens and failures associated with updates. The retained evidence reviewed here does not establish the total recurrence count or demonstrate that every update causes a failure.

The recurring symptom was that native Computer Use could successfully read a separate desktop application while the live Computer Use Picture-in-Picture preview was absent. The avatar, task pill, a setting saying PiP was shown, and successful tool completion were insufficient acceptance evidence. The final recovery required an established native connection, a published presentation, and a visibly confirmed live Calculator preview.

All runs below use aliases instead of process, thread, request, presentation, or account identifiers. For each timed run, t=0 is its own RemoteHostedPIPContent started private endpoint host event. Times are elapsed durations, not local clock times. Paths use <APP_BUNDLE>, <REFERENCE_APP_BUNDLE>, $CODEX_HOME, <DISPOSABLE_CODEX_HOME>, or <DISPOSABLE_ELECTRON_PROFILE>. No personal screenshots or raw session transcripts are included.

Product and binary identities

The desktop application identifies as com.openai.codex, even though the installed bundle/executable names in these builds are ChatGPT.app / ChatGPT. The native helper is com.openai.sky.CUAService, packaged as Codex Computer Use.app with executable SkyComputerUseService. Both are signed by OpenAI team 2DC432GLL2.

The platform was macOS 26.6.2, arm64. This OS version was already installed before the earlier verified success; an intervening OS update was not established as the explanation.

The reference build remained an untouched signed copy. Both compared builds passed stock signature verification. App, framework, and helper designated requirements and entitlements matched between builds 7746 and 8109. Matching requirements do not prove that every authentication or transport operation succeeded at runtime.

Public binary fingerprints:

Both sky.node files are 1242752 bytes. Their 1568 differing bytes were confined to UUID/build timestamps/signature material in the recorded comparison; no change outside those regions was found. Thus executable native PiP code matched, while the shipped host framework and bundled app-server did change. Both package manifests reported Electron 42.3.0; that manifest field alone does not describe the differing shipped framework versions.

Earlier incident and verified recovery

H1: original installation, build 7658

The native host started its private PiP endpoint, then logged:

RemoteHostedPIPContent CUAService bootstrap failed:
  Error Domain=NSOSStatusErrorDomain Code=-1712

Native Calculator reads already succeeded. Their tool metadata identified the surface as computerUse. Browser Use presentations could publish, which argued against a complete failure of the common overlay/window stack. This localized the observed defect to the native Computer Use publisher connection rather than proving the Computer Use action path was broken.

An earlier hypothesis that the unified Computer Use wrapper stripped the relevant surface metadata did not survive the successful native-result evidence. A diagnostic code_mode_host = false override was removed. Inspection showed the packaged desktop invocation already supplied features.code_mode_host=true; removing the override did not, by itself, restore PiP.

H2: official update to build 7746, still failing

The built-in updater installed official signed build 7746. A fresh host on that build reproduced the bootstrap failure at approximately t+46.665s, even after removal of the ineffective override. The update alone therefore was not the fix.

The canonical helper on disk was build 1000926, UUID 10A60435-199F-373B-B92D-2EC7971E1670, but its exact LaunchServices path still advertised older build 1000919, UUID 51DA0098-9292-37BC-9D4A-3D3C7A1C6222. The discrepancy was between registration metadata and the signed file at the same path, not a demonstrated replacement of the executable.

Only that exact canonical helper bundle was force-registered with LaunchServices:

lsregister -f "$CODEX_HOME/computer-use/Codex Computer Use.app"

Readback then matched the on-disk build and UUID. A native target read immediately afterward succeeded but did not reconnect the already-failed PiP host. A fresh host lifecycle was still needed.

The recorded quit sequence initially remained behind the application's native quit confirmation. Three one-shot delayed ordinary relaunch attempts were recorded before the confirmation was completed. They contained no private PiP reconnect invocation. The eventual successful host appeared about three minutes after the preceding host stopped; the retained action chain does not identify the initiator of that eventual launch precisely. The earlier short-delay scripts alone do not explain the entire gap.

H3: build 7746, verified native PiP

The native connection existed before post-restart target verification. The audited action chain contains no private API reconnect invocation, app injection, publisher-guard activation, or relevant setting write at the successful bootstrap. An old publisher guard was positively observed disabled earlier in the incident, and no recorded command enabled it. This does not exclude unrecorded external activity, but no such activity is needed to explain the recorded action chain.

The last explicit configuration read before this success had computerUseAlwaysHidePictureInPicture = false and mac-menu-bar-enabled = false. No subsequent menu-setting mutation appears in the audited action chain. There was no preference snapshot at the exact instant of connection. Accordingly, enabling the menu bar cannot be presented as a proven necessary condition for every successful PiP connection.

The earlier report characterized stale LaunchServices registration as the root cause. The more careful historical conclusion is that a real registration mismatch was corrected and a subsequent fresh host connected. That sequence established an effective recovery for that incident, not a controlled proof that registration was the only causal factor or a guarantee against recurrence.

Later recurrence on build 8109

R1: normal profile repeatedly fails

The same visible symptom returned on current build 8109: successful native reads of a separate app, absent native Computer Use PiP. The retained records show multiple unsuccessful recovery attempts, but are not a count of every historical recurrence reported by the user.

The exact canonical and bundled helper LaunchServices registrations were checked and narrowly refreshed. Before this refresh, the canonical $CODEX_HOME/computer-use/Codex Computer Use.app record already matched build 1000926, UUID 10A60435-199F-373B-B92D-2EC7971E1670. The bundled <APP_BUNDLE>/Contents/Resources/cua_node/lib/node_modules/@oai/sky/Codex Computer Use.app record still advertised build 1000633, UUID BCCB9608-2C53-34F5-907E-BD3F01FC6038. This is distinct from the earlier incident's stale canonical build 1000919. After the exact refresh, both records matched build 1000926 and the current UUID. Correct registration readback did not restore PiP in the failing normal profile.

Other bounded attempts also failed to restore the normal-profile publisher connection: normal restarts, a language refresh, and a fully closed interval exceeding ten minutes. Successful native Calculator reads continued to establish that action transport could function independently of the absent preview.

The helper and native PiP executable code matched the earlier recovered build. Bounded inspection also found matching logic in the JavaScript canonical-helper refresh path, managed-service callbacks, feature reconciliation, PiP lifecycle controller, and worker PID routing. A straightforward changed-PiP-code explanation was not found in those inspected regions. The framework and app-server differences remained potential variables, not established causes.

During a failed bootstrap lasting approximately 47 seconds, simultaneous host/helper samples showed the host waiting in AESendMessage. No receiver queue appeared in the sampled host stacks. Later helper samples showed one and then two tasks blocked in synchronous endpoint transfer through SAISendNSXPCListenerEndpointOverMachPort, xpc_pipe_routine, and Mach exchange. Sampling could miss a short-lived receiver invocation; the exact receiver exit/error was not captured.

One earlier authorization-related error was examined, but it was absent from later current-build runs that both succeeded and failed. It was therefore not a necessary explanation for the recurring failure. Native-bridge recognition also has a separate path from ordinary parent-ancestry validation; the Codex host/sender being parented by launchd is not itself proof of an invalid caller.

S1 and S2: sequential stock-build comparison, with a discovered harness defect

The user ran a bounded comparison: untouched reference build 7746 first, then current build 8109, using the same disposable state in forward-only order. The older app was never pointed at the live Codex home or live Electron profile. Authentication was not copied. Product-supported process-local configuration selected separate CODEX_HOME and CODEX_ELECTRON_USER_DATA_PATH locations and disabled updates for these test launches. No app patch or injected reconnect code was used.

After the tests, a concrete harness flaw was found: <DISPOSABLE_CODEX_HOME>/ipc/ipc.sock was 116 UTF-8 bytes long. The macOS SDK defines sun_path[104]. Both apps repeatedly failed to bind the IPC router:

[IpcRouterManager] Server error
  errorCode=EINVAL
  errorMessage="listen EINVAL: invalid argument <DISPOSABLE_CODEX_HOME>/ipc/ipc.sock"

The older run recorded 245 such errors and the current run 380. The normal profile did not show this defect. This can affect app initialization and scheduling, so these were not clean frontend or isolated runtime comparisons. The harness was subsequently corrected to a 53-byte socket pathname with an explicit length guard; the corrected comparison was not rerun after native PiP recovered. The original evidence was preserved.

The older build displayed a blank/gray window, not a verified welcome or sign-in screen. Its renderer logged routes mounted, so native initialization ran, but usable UI initialization was not established. It also logged Failed to load config requirements with RPC session was shut down by disposing the main stub. The current disposable run logged onboarding-migration timeout and query-cache invalidation initialization-timeout warnings. No recorded renderer crash, failed-page-load event, or uncaught exception conclusively explained the gray window. The IPC defect is a confound, not a proven exclusive explanation of the visible window.

The lower-level native events remain actual observations despite that flaw:

At normal shutdown, the old helper also logged a -609 reply failure to the exited host. That teardown result does not identify which earlier internal stage stalled.

The S2 connection was a real event from that run, not a stale event from another host. Connection establishment and the later AppleEvent timeout coexisted. No subsequent invalidation was logged before normal shutdown; continuous liveness was not independently probed. A timeout alone is therefore insufficient as a PiP failure verdict, and a connection event alone is insufficient as visible PiP acceptance.

R2: same current build, normal profile, fails again

The normal-profile return to current build 8109 again failed. With its private-host start as t=0, helper listener initialization occurred at t+0.472s, PiPB arrived at t+0.493s, SndR/SkysightStatus followed about 26ms later, and SkysightStart followed. The native connection never appeared; bootstrap timed out at t+46.668s.

In S2, MenuState completed before its first delivered PiPB, and the helper had been listening longer. In R2, PiPB arrived early and overlapped history startup. This supported investigating readiness/concurrent-request timing, while leaving profile scope, feature reconciliation, event-stream activity, and the disposable IPC defect as confounding variables. No unrelated plugin was disabled to manufacture a result.

R3: supported menu preference retained, normal restart, verified recovery

The normal profile had desktop.mac-menu-bar-enabled=false; the disposable profile used the default true. Inspection of shipped startup code showed that enabling the supported Show in menu bar preference creates the native status-item controller and immediately requests MenuState from the helper. The code does not establish a strict readiness barrier. Changing the preference on an already-failed host also does not, by itself, re-arm that host's PiP connection.

Only desktop.mac-menu-bar-enabled was changed from false to true for one normal-profile restart. Every other parsed configuration entry was verified unchanged. The existing Computer History configuration was retained. The user quit and reopened the normal installed app. A scheduled startup sampler expired before this launch; the report relies on retained unified logs and later contemporaneous samples rather than claiming a complete scheduled startup sample set.

The user explicitly confirmed seeing the live Calculator preview. Native actions ceased after verification, leaving normal product-owned lifecycle behavior in place. The persistent menu preference remains enabled because current restoration was verified.

The successful run received PiPB before its first accepted SndR. The initial SndR method names were not retained in the inspected logs; later requests are explicitly named ComputerUseIPCCodexStatusItemMenuStateRequest. Consequently, this run does not prove that MenuState must complete before PiPB, that enabling the menu bar is universally necessary, or that the timing mechanism is fully understood. The earlier verified success also had a last recorded menu preference of false.

Current disposition and remaining engineering questions

Native Computer Use PiP is currently restored and visibly verified on stock build 8109 after the supported menu-setting change and normal restart. This is a verified recovery, not an implemented vendor source fix, a proved single root cause, or a guarantee against future updates.

The evidence supports vendor investigation of suspended PiPB AppleEvent completion, XPC endpoint transfer, helper readiness, and host reconnection after a bootstrap failure. Static inspection found the host can clear its remembered PiP service PID while the managed service still caches a healthy helper and does not emit a new service-available callback. That can leave no automatic reconnection trigger without a new lifecycle event. The reserved AppleEvent repp attribute used in the XPC rendezvous also merits review, but no malformed/error message entering that receiver was captured; this is a protocol concern, not a proved observed failure chain.

Across these recovery efforts, no app was patched or re-signed, no private reconnect API was invoked as a repair, no helper/guardian was forcibly terminated, no control socket was removed, no watchdog/daemon was installed, and no broad LaunchServices or TCC reset was performed. Normal app restarts, exact helper registration refreshes, supported app configuration, and read-only diagnostic inspection were used. The objective is a product-owned fix that survives subsequent ordinary launches and updates without repeating this diagnostic sequence.

Technical appendix: native Computer Use PiP bootstrap and recovery

This appendix separates observations, static code findings, and unproven mechanisms. It contains no raw logs, process identifiers, account data, conversation content, absolute user paths, or wall-clock timestamps. Run times below are relative to that run's native PiP host startup.

Observed outcomes

Run R3 connected at t+0.561 s, published its native presentation at t+47.949 s, and reported visible operations at approximately t+52.558 s and t+52.961 s. The preview was confirmed during an actual native Computer Use read; avatar, task-pill, and preference visibility were not accepted as substitutes. This demonstrates restoration in that configuration, not a proven permanent fix or update-proof behavior.

Disposable comparison confound: both disposable runs used an IPC socket pathname measuring 116 UTF-8 bytes, exceeding the installed macOS SDK's sun_path[104] capacity (usr/include/sys/un.h:79, relative to the SDK root). Both logged repeated IPC-router listen EINVAL errors; the ordinary-profile runs did not. The harness was subsequently corrected to reject oversized paths, but the corrected comparison has not run. S2's endpoint connection is real; the comparison does not isolate build, profile, or scheduling as its cause, and the blank window cannot be conclusively attributed to the pathname alone.

Endpoint protocol and sampled failure

Static inspection of the signed native components establishes this sequence:

1. Host RemoteHostedPIPContentService.connectToServiceWithProcessIdentifier: creates an NSMachPort and inserts a send right. It independently queues receiveEndpointsFromPort: on com.openai.codex.remote-hosted-pip.receive and AppleEvent bootstrap on .bootstrap.
2. sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt: sends (SkCu, PiPB) to the managed helper using an exact process descriptor, with a 15-second AppleEvent timeout.
3. The helper suspends the AppleEvent and dispatches its Swift continuation. After authentication and lifecycle checks, it obtains an XPC listener endpoint and validates the supplied rendezvous descriptor: type port, four bytes, and a Mach send right.
4. SAISendNSXPCListenerEndpointOverMachPort creates an XPC dictionary containing endpoint and calls synchronous xpc_pipe_routine. Its wrapper supplies no explicit timeout. The AppleEvent is resumed only after this exchange returns.
5. The host receiver calls xpc_pipe_receive, validates the endpoint, and sends xpc_pipe_routine_reply before dispatching connectToEndpoint:rendezvousPort: to the main queue. The normal reply therefore does not require a completed UI connection.

In R1, PiPB reached the helper at t+0.475 s, t+15.806 s, and t+31.654 s; terminal bootstrap timeout occurred at t+46.649 s. Five two-second host samples spanning early startup through approximately t+36 s all contained an AppleEvent bootstrap wait, but none contained the receiver queue, receiveEndpointsFromPort:, xpc_pipe_receive, or endpoint connection stack.

The helper's early samples contained no persistent endpoint-transfer wait. Later samples contained one, then two, tasks in this stack:

PiPB continuation, static offset 0x178898
SAISendNSXPCListenerEndpointOverMachPort +132
_xpc_pipe_routine
Mach message wait

Separate post-timeout sampling found the same blocked transfer shape minutes later. These tasks had reached endpoint transport; a general failure to schedule the helper task or produce an endpoint does not explain them. Samples cannot distinguish send-space wait from reply wait.

Sampling limit: the first sample began approximately 370 ms after the first PiPB receipt. Intermittent samples prove no sampled receiver wait, not that the receiver never ran. An earlier receiver exit or a valid but incorrectly routed port remains possible. No runtime Mach messages or port rights were captured.

Silent receiver exits and managed recovery gap

Static receiver branches return without an explicit diagnostic when receive fails or returns no message, endpoint is absent or has the wrong type, a reply cannot be created, or reply transmission fails. Those branches prevent the retained logs from identifying the first failure.

The inspected JavaScript recovery paths also expose a concrete gap:

• PiP connection loss clears its remembered helper process identifier.
• ensureServicePidForEnabledFeatures() can return a healthy, expected, already-managed helper without invoking onServiceAvailable again.
• PiP's setServiceProcessIdentifier is reached through that availability callback; merely returning the cached identifier does not rearm native PiP.
• invalidateServicePid preserves a healthy expected helper. Locale refresh cannot reconnect after PiP's own remembered identifier has been cleared.

These bounded paths match in both compared builds. They describe a preexisting recovery weakness; they do not establish which update introduced the triggering failure. A healthy helper should be reusable through explicit native reconnection rather than requiring process termination.

Authorization scope: corrected interpretation

The bootstrap sender is the Codex host executing its native bridge, not the target application being controlled. The helper's NSAppleEventDescriptor.senderPID getter reads read-only AppleEvent attribute spid. SDK-relative System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/Headers/AEDataModel.h:210 documents this sender identifier; the audit token is a separate attribute.

Shared sender validation first checks the audit token/signing identity and recognizes authenticated native bridges using the API-version property, sending application's bundle identity, and signing requirement. Host and helper agree on ClVn=CodexComputerUseNativeBridge-1. When this recognition succeeds, the ordinary parent/ancestor classifier is skipped. Consequently launchd parentage alone is not an authorization defect and does not justify a launcher workaround.

One R1 error template was traced to shared sender authorization, but the retained error did not identify the exact request or failed authorization check. Both ordinary SndR and PiPB use that routine. The isolated first-sample signing-validation stack was conclusively SndR, not PiPB. The authorization error was absent from both S2 and R2, so it cannot explain every failure. No persisted authorization cache was identified in the inspected resolver; live parent/responsibility/ancestor identity and constant signing requirements were used. No authorization weakening or privacy reset is proposed.

Reserved repp: protocol concern, not proven root cause

The host puts the XPC rendezvous port in AppleEvent attribute repp, and the helper reads that same attribute as its endpoint-transfer destination. This is a reserved AppleEvent reply-routing attribute:

• SDK-relative System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/Headers/AEMach.h:57–63 describes keyReplyPortAttr as the Mach reply destination.
• Lines 65–67 document an anonymous reply port with AESendMessage and kAEWaitReply.
• Lines 79–80 define keyReplyPortAttr = 'repp'.

Hypothesis: an ordinary/error AppleEvent reply could reach the port whose receiver expects an XPC dictionary, cause a silent receiver exit, and leave later synchronous endpoint transfers without a receiver. This coherently explains some observed states but has not been traced. The precedence of the explicit attribute versus anonymous wait-reply port remains unresolved; the first message and first receiver return status were not observable. The shared authorization error cannot be assigned to the first PiPB or treated as a necessary trigger.

S2 connected at t+1.819 s and then logged an AppleEvent timeout approximately 15 seconds later, with no subsequent connection invalidation logged until normal quit about 188 seconds after connection. Continuous endpoint liveness was not independently probed. AppleEvent timeout alone is therefore not a reliable PiP-failure verdict. Endpoint connection, AppleEvent completion, and visible presentation need separate status.

Menu setting and concurrency: what the successful run changes

The supported mac-menu-bar-enabled setting creates the native status controller. Its constructor requests updateMenuState(), which obtains/ensures the helper and sends ComputerUseIPCCodexStatusItemMenuStateRequest through ordinary native transport. This changes startup work and timing; the code does not establish a readiness barrier before PiPB.

In S2, PiPB followed a completed MenuState request. In R2, PiPB closely followed helper initialization and overlapped ordinary status work. However, restored run R3 received PiPB at t+0.507 s, then SndR at t+0.551 s, and connected at t+0.561 s. Thus a completed SndR request before PiPB is not necessary for success. Menu enablement is associated with this successful ordinary-profile run, not proven sufficient or necessary across launches. No specific plugin has been established as the cause.

Native code locators and comparison hashes

Offsets below are static locators for the inspected arm64 binaries, not runtime process addresses. Helper addresses include its 0x100000000 image base.

The compared helper executables are byte-identical. Native sky.node files differ only in UUID/build-timestamp/signature regions; their executable __TEXT,__text sections are identical. Relevant bounded bootstrap/recovery JavaScript, designated requirements, and entitlements also match. Other app components differ, including the embedded framework, so this does not establish whole-app equivalence.

Candidate product repair and discriminating diagnostics

The following is design pseudocode, not an implemented or tested patch. A versioned change must coordinate both signed protocol participants.

reconnectPiP():
    helper = managedService.ensureHealthyHelper()
    generation = beginFreshBootstrapGeneration()
    receiver = createEndpointReceiver(generation)
    await receiver.ready
    sendBootstrap(helper, applicationPrivateRendezvousField(receiver), generation)
    await boundedEndpointExchange(generation)
    connectEndpointIfGenerationCurrent(generation)

onFailure(generation, stage, status):
    recordNonSensitiveDiagnostic(generation, stage, status)
    cancelReceiverAndPendingExchange(generation)
    scheduleBoundedReconnectToHealthyManagedHelper()

Required properties: preserve audit-token/signature and lifecycle-owner checks; use an application-private rendezvous field rather than reply-routing attributes; correlate each receiver exit and message type with a bootstrap generation; bound/cancel helper transfers; ensure retries have a live receiver; reissue native connection when the helper is healthy and cached. Unexpected messages must not silently strand retries. Product-owned instrumentation of the first receiver status/message kind and reply-routing decision would discriminate the remaining hypotheses more directly than further equivalent restarts.

Regression coverage should include both menu settings, concurrent ordinary native requests, delayed initialization, malformed/error messages, timeout with an already-established endpoint, recovery with a still-live helper, normal quit/relaunch/update, and an actual published and visible preview. Any disposable comparison must first validate usable UI initialization and equivalent socket-path constraints.

No installed binary was patched or re-signed, no helper was forcibly terminated, no socket was removed, and no security setting or authentication predicate was changed. The current outcome is a verified restored presentation plus a bounded product-repair proposal; the exact triggering defect remains unresolved.