[macOS] Computer Use PiP refresh loop can steal foreground focus under Stage Manager

What version of the Codex App are you using (From "About Codex" dialog)?

ChatGPT/Codex Desktop 26.730.61639 (CFBundleVersion 6234)

Bundle identifier: com.openai.codex

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm
macOS 26.5.1 (25F80)

Stage Manager was enabled with its recent-app strip visible.

What issue are you seeing?

Codex Desktop intermittently makes itself the frontmost macOS application while it is in the background under Stage Manager. This interrupts typing and clicking in the application the user intentionally selected. The behavior was also reported while no Codex turn was active.

Diagnostics found a continuous remote-hosted Computer Use PiP reconnect loop in the Codex Desktop log:

2026-08-05T16:10:03.864Z info Refreshing managed Computer Use service for PiP
2026-08-05T16:10:03.870Z info Refreshed managed Computer Use service for PiP processIdentifier=1351
2026-08-05T16:10:20.623Z info Refreshing managed Computer Use service for PiP
2026-08-05T16:10:20.629Z info Refreshed managed Computer Use service for PiP processIdentifier=1351
2026-08-05T16:10:37.365Z info Refreshing managed Computer Use service for PiP

There were 533 refresh cycles at approximately 16.75-second intervals. Every successful refresh returned the same live helper PID (1351), and there were no helper-refresh failures, crashes, or zombie processes. This appears to be repeated reconnection to a healthy helper, not the helper-crash loop from #37084.

One foreground activation correlated closely with a refresh:

16:07:16.318 Codex       Refreshing managed Computer Use service for PiP
16:07:16.321 Codex       Refreshed ... processIdentifier=1351
16:07:16.923 WindowServer Making ChatGPT/Codex the front process

No new physical click occurred between the PiP refresh and the foreground activation. Other activations showed Stage Manager/FuseBoard transitions around the focus change, so this may be an interaction between remote-hosted PiP window lifecycle and Stage Manager rather than a direct unconditional focus() call.

Completion notifications were already disabled:

[desktop]
notifications-turn-mode = "off"

The Appshot hotkey was registered, but the entire affected log contained zero Appshot hotkey pressed or Dispatching appshot hotkey events. There were also no custom launchctl jobs repeatedly opening ChatGPT, distinguishing this from the local cause documented in #33775.

What steps can reproduce the bug?

1. Enable Stage Manager on macOS and leave the recent-app strip visible.
2. Open Codex Desktop with Computer Use available.
3. Switch to Chrome or another application and continue working there.
4. Observe Codex intermittently becoming frontmost without an explicit user action directed at Codex.
5. Inspect the Codex Desktop log and observe Refreshing managed Computer Use service for PiP every approximately 16.75 seconds.
6. Add the following currently hidden desktop preference and fully restart Codex:

``toml
[desktop]
computerUseAlwaysHidePictureInPicture = true
``

1. Observe that the PiP refresh loop disappears and the unsolicited foreground activation stops.

After applying that preference and restarting, the replacement app process logged zero PiP refreshes during an initial verification interval, and the focus-stealing behavior stopped during continued use. Computer Use itself remained available.

What is the expected behavior?

• Background Computer Use/PiP lifecycle activity must not activate the main Codex window or change the user's frontmost application.
• A healthy Computer Use helper should not require reconnecting every approximately 16.75 seconds while idle.
• The persistent PiP preference requested in #32451 should be exposed in Settings rather than remaining an undocumented configuration key.
• Codex should remain well behaved when visible in Stage Manager's live preview.

Additional information

Potential areas to inspect:

1. Why RemoteHostedPIPContent loses or renews its service connection every approximately 16.75 seconds despite ensureServicePid() returning the same healthy PID.
2. Whether reconnect/reconcile paths show, order, or activate an overlay or owner window in a way Stage Manager treats as foreground intent.
3. Whether the PiP host can use a non-activating window/panel path and explicitly preserve the current frontmost application.
4. Adding backoff or a circuit breaker for repeated reconnects even when the helper process remains alive.

Related issues:

• #32451 requests a visible persistent PiP opt-out; its underlying hidden preference is the verified workaround here.
• #37084 reports a much faster retry loop caused by a crashing helper on macOS 14.3; this report has a stable helper PID and no crash.
• #18545 reports a separate Stage Manager live-preview rendering/performance interaction.
• #33775 has the same foreground symptom but was closed after finding unrelated local launchctl jobs; no such jobs were present here.

No project contents, task prompts, account identifiers, host details, or other user data are included.