macOS app update leaves pre-update node_repl host unable to authenticate to new Computer Use service

What version of Codex CLI is running?

codex-cli 0.147.0 (also the current npm release when checked on 2026-08-17).

What subscription do you have?

Logged in using ChatGPT; the CLI does not expose the exact subscription tier.

Which model were you using?

Not model-dependent. This occurred in the desktop app's Computer Use tool host.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

ChatGPT/Codex desktop app on macOS.

Codex doctor report

Not included. This report concerns an observed pre-update runtime generation, and the current fresh runtime now succeeds. The in-client feedback was submitted without logs to avoid attaching unrelated session data.

What issue are you seeing?

An in-place Sparkle update left a pre-update node_repl host alive after the desktop app, packaged Node runtime, and Computer Use service had been replaced.

Measured timeline from 2026-08-11:

• The failing node_repl host started at 11:40:17 local time.
• Sparkle replaced the app's node_repl and Node binaries and started Computer Use helper 26.804.1000633 between 12:54:56 and 12:55:18.
• At 13:38, the post-update helper logged 49 consecutive Sender process is not authenticated errors during one five-second retry loop.
• A kernel reset produced a second loop of exactly 49 identical rejections because the replacement kernel was still a child of the old host.
• lsof showed the old host's text image mapped to a deleted Sparkle installation-staging inode. A fresh host mapped the current binary under /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl.
• A newly started post-update host immediately completed sky.list_apps() and ordinary app-state reads without changing Accessibility, Screen Recording, or any other macOS permission.

The user-facing error was only:

Sky Computer Use native pipe startup failed

The nested service-side authentication rejection and the version-skew cause were not surfaced.

What steps can reproduce the bug?

This was observed once with exact process and filesystem evidence:

1. Keep a desktop Computer Use node_repl host alive.
2. Allow Sparkle to replace the desktop app and bundled Computer Use runtime in place.
3. From the still-live pre-update host, call sky.list_apps() (or another Computer Use operation).
4. Observe the generic native-pipe startup failure while the new service logs repeated Sender process is not authenticated.
5. Reset only the JS kernel; the failure persists because the parent tool host is still pre-update.
6. Start a genuinely fresh tool host from the updated app; the same call succeeds.

A deterministic test could hold a host from build N open across installation of build N+1, then exercise the new helper before the old host is retired.

What is the expected behavior?

After an app update, the desktop app should retire or refresh pre-update Computer Use/node_repl hosts before they call the new native service.

If an old host cannot authenticate, the UI should surface an actionable version-skew/restart message instead of only the generic native-pipe startup error.

Additional information

• OpenAI /feedback thread: 01a010fa-6a6f-7c63-8ddc-8c538c4fa856 (submitted without logs).
• Current control on 2026-08-17: app 26.810.41047 (build 6570), Computer Use helper 26.812.1000717 (build 1000717), and fresh sky.list_apps() succeeds.
• This is distinct from #35234, where a fresh full relaunch still fails, and #25744, which tracks helper/process accumulation. Here, only the pre-update live host failed and a fresh post-update host was the successful control.