Codex Desktop: opening any unloaded local chat waits ~5 seconds on owner discovery timeout

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #37397

Powered by Codex Action

Confirming this on the same build — ChatGPT desktop 26.803.41515, bundled codex 0.147.0-alpha.6.5, macOS 26.5.2 arm64. From the Electron log (~/Library/Logs/com.openai.codex/, times UTC):

07:11:48.492 maybe_resume_started conversationId=019fdb07-… rendererWindowAppearance=primary
07:11:53.494 maybe_resume_owner_discovery_failed errorMessage=timeout
07:11:53.716 maybe_resume_success

Fixed 5.002 s deadline, then the fallback succeeds 0.22 s later — matches the timing in the report.

Update — root cause identified (refines my earlier "not warm yet" hypothesis): the backend is not slow; a silent client on the desktop IPC bus eats the 5 s discovery watchdog.

• Chain: resume → findThreadOwner → thread-owner-discovery fanned out over ~/.codex/ipc/ipc.sock → the router waits for negatives from every connected client → one client never answers → the fixed 5000 ms watchdog fires → fallback succeeds.
• The silent client is SkyComputerUseService (Computer Use helper, build 26.804.1000633) — the only external client on that socket per lsof (the other accepted connections are in-process loopback pairs of ChatGPT itself). It connects and completes the handshake, but never answers discovery.
• The 5 s hole contains zero app-server traffic (initialize 58 ms at launch, other requests in the window 1–25 ms) — the stall is entirely in the IPC layer.
• Date boundary on this machine: 0 owner-discovery timeouts 08/01–08/06, 4 on 08/07 — the day this helper build was installed (binary mtime matches). This converges with the A/B in #37397 (@zhyuzhyu): kill only the helper → the same probe returns no-client-found in ~4 ms; relaunch → the timeout returns.

This also reframes my earlier observations: it is not really primary vs avatarOverlay — it is whether discovery runs after the helper's socket connect lands (~10 s into each session); resumes with a known owner skip discovery entirely (23–48 ms observed).

Suggested direction: (1) router-side — probe clients at connect (~300–500 ms), mark non-responders silent and exclude them from discovery fan-out, logging the unanswered client id; (2) helper-side — answer discovery with the protocol's negative response (no-handler-for-request / canHandle: false), the shape the open TUI client uses in codex-rs/tui/src/ide_context/ipc.rs (which shares this socket and the same 5 s budget, and is a collateral victim).

(#37397 looks like the same issue.)

Confirming a user-visible variant on the same build. Starting or cold-opening a task can show a red Conversation not found toast after the five-second owner-discovery timeout, even though the task subsequently loads and remains usable.

Across one current app session:

• 16 resumes reached maybe_resume_owner_discovery_failed with the fixed five-second timeout.
• Nine affected resumes then emitted exactly two Conversation state not found errors before maybe_resume_success: one from the hidden globalDictation renderer and one from the hidden avatarOverlay renderer.
• thread/read and thread/resume still succeeded after fallback.
• SkyComputerUseService was running and connected to the local Codex IPC socket.

This looks like collateral from the same silent-client discovery failure rather than missing or corrupt task data. After the watchdog expires, fallback resume succeeds, but hidden surfaces receive the conversation event before or without corresponding local state and surface the toast. That causal interpretation is an inference from the correlated timestamps, not a confirmed source-level trace.

Environment: ChatGPT/Codex Desktop 26.803.41515 build 6321, bundled Codex 0.147.0-alpha.6.5, macOS arm64.

Independent live A/B confirmation from another affected macOS system.

Environment:

• ChatGPT/Codex Desktop 26.803.41515
• Computer Use helper 26.804.1000633
• macOS 15.7.8 (24G817)

Before terminating the helper:

• Computer Use had been disabled in the plugin UI, but SkyComputerUseService remained alive for about nine hours.
• lsof showed the helper still connected to the same Desktop IPC socket used by ChatGPT/Codex.
• A cold local thread in needs_resume state produced:

12:28:51.479 maybe_resume_started
12:28:56.485 maybe_resume_owner_discovery_failed errorMessage=timeout
12:28:56.846 maybe_resume_success

The owner-discovery wait was 5006 ms. After fallback, thread/read took 8 ms and thread/resume took 306 ms.

After running:

/usr/bin/killall SkyComputerUseService

I confirmed that the helper process and its IPC connection were gone. Three different cold local threads in needs_resume state then completed without any owner-discovery timeout:

13:00:42.264 maybe_resume_started
13:00:42.797 maybe_resume_success    # 533 ms

13:00:44.640 maybe_resume_started
13:00:45.243 maybe_resume_success    # 603 ms

13:00:46.867 maybe_resume_started
13:00:47.374 maybe_resume_success    # 507 ms

Thread switching was immediately much faster to the user.

This adds two useful lifecycle observations:

1. Disabling the Computer Use plugin does not terminate or unregister an already-running SkyComputerUseService.
2. Terminating only that helper removes the fixed five-second wait without restarting Desktop or changing thread data, provider configuration, or proxy settings.

This strongly supports SkyComputerUseService being a connected IPC client that does not answer thread-owner discovery. The helper should return a negative capability response immediately, and disabling the plugin should disconnect or terminate the existing helper.

Conversation IDs and raw logs are omitted for privacy.

Additional lifecycle evidence from another affected macOS system. This may explain why disabling the Computer Use plugin does not reliably eliminate the regression.

Environment

• ChatGPT/Codex Desktop: 26.803.41515 (build 6321)
• Bundled Codex: 0.147.0-alpha.6.5
• Computer Use helper: 26.804.1000633
• macOS 26.5.2, arm64

Reproduction after disabling Computer Use

1. Disabled the bundled Computer Use plugin in the UI.
2. Verified the resulting configuration:

• plugins."computer-use@openai-bundled".enabled = false
• mcp_servers.computer-use.enabled = false
• chronicle = false
• js_repl = false

1. Fully quit ChatGPT/Codex and relaunched it.
2. A new SkyComputerUseService process was spawned about five seconds after the new ChatGPT process. Its parent was the current ChatGPT process, so this was not a stale helper surviving the previous app session.
3. The startup log registered the Appshots hotkey (hotkey=DoubleCommand) before the helper appeared.
4. Cold local resumes continued to hit the exact watchdog:

• maybe_resume_started
• 5002–5006 ms later: maybe_resume_owner_discovery_failed errorMessage=timeout
• fallback resume then completed normally.

1. Running /usr/bin/killall SkyComputerUseService removed the helper; two subsequent process checks confirmed it did not immediately respawn.

A read-only inspection of the packaged main-process bundle is consistent with this behavior: the desktop-managed helper is enabled when any of the shared feature gates for Appshots, Computer Use, node REPL, or Skysight/Computer History is active. Therefore, disabling only the bundled Computer Use plugin does not necessarily prevent the affected IPC client from connecting.

There is also a legacy top-level notify = [...SkyComputerUseClient, "turn-ended"] entry on this installation, but it cannot explain the cold-start spawn above: the helper was launched before any turn-ended notification occurred.

Implication for the fix

A plugin-lifecycle-only fix would be incomplete. The helper should always answer thread-owner discovery immediately with a negative capability response when it cannot own a thread, or the IPC router should exclude non-thread-owner clients from the discovery fan-out. Disabling Computer Use should also disconnect/terminate an existing helper when no other shared feature requires it.

No conversation IDs, transcript contents, raw logs, or private paths are included.

Additional local confirmation: on Desktop 26.730.61639, reopening a needs_resume task reached thread/read about 75 ms after resume began. On 26.803.41515, the same path waits 5,001 ms for maybe_resume_owner_discovery_failed, then thread/read takes 5 ms and thread/resume 89 ms.

Local logs also show inactive_thread_unsubscribed occurring for 3600 seconds after the task became inactive. That confirms that task cooling predates the regression.

A one-hour unload is obviously intentional, presummable to reduce memory, but it also feels WAY to frequent. I'd personally want one week.

Independent confirmation from another severely affected macOS user. This is a major desktop usability regression, not a minor performance fluctuation.

Environment:

• ChatGPT/Codex Desktop 26.803.41515, build 6321
• Bundled Codex 0.147.0-alpha.6.5
• Computer Use helper 1.0.1000633
• macOS 26.6.1, arm64

Exact user-visible pattern:

1. Relaunch the app.
2. Open any existing conversation that has not yet been opened during this app process.
3. The conversation blocks for approximately 5 to 6 seconds.
4. Switch away and return to that already-opened conversation: the switch is effectively instant.
5. Relaunch the app again: every conversation becomes slow on first open again.

Normal message submission and response streaming remain fast and reliable. Only conversation navigation is affected. This makes the desktop app materially slower than the web UI for routine chat switching and makes the latest app feel broken after every relaunch.

Sanitized measurements across retained desktop logs:

• 51 maybe_resume_owner_discovery_failed timeouts
• Minimum 5,001 ms
• Median 5,003 ms
• Maximum 5,025 ms
• Actual thread/read on the current day: average 10 ms, maximum 38 ms
• Actual thread/resume on the current day: average 108 ms, maximum 555 ms

The state transition matches the report exactly: an unloaded conversation enters needs_resume, owner discovery waits for the full five-second watchdog, fallback succeeds, and the conversation becomes resumed. Subsequent visits in the same app process reuse that warm state and are instant.

Local root-cause confirmation:

• SkyComputerUseService starts automatically a few seconds after ChatGPT/Codex, even though the user did not explicitly start a Computer Use task.
• The helper is connected to ~/.codex/ipc/ipc.sock while the fixed owner-discovery timeouts occur.
• OpenCodex was initially suspected but ruled out: its service is unloaded and disabled, port 10100 has no listener, Codex is using the native OpenAI provider, and the signed ChatGPT application bundle verifies successfully.
• Network health is normal, including a successful Responses WebSocket handshake. The five-second gap is local and deterministic.

Severity request: please treat this as a high-impact navigation regression. A five-second watchdog paid once per conversation after every app launch compounds quickly for users who work across many tasks. The helper should immediately return a negative owner-capability response, or the IPC router should exclude silent non-owner clients without blocking the UI.

experiencing the same thing, really annoying
➜ ~ /usr/bin/killall SkyComputerUseService helped though

Independent confirmation that this remains reproducible on August 11, 2026.

Environment

• ChatGPT/Codex Desktop 26.803.41515 (build 6321)
• Bundled Codex 0.147.0-alpha.6.5
• macOS 26.6.1, arm64

Fresh-session reproduction

The desktop process had just started. Five different unloaded local tasks were cold-opened over the next several minutes. All 5/5 followed the same sequence:

• maybe_resume_started
• 5,001–5,003 ms later: maybe_resume_owner_discovery_failed errorMessage=timeout
• fallback thread/read: 5–9 ms
• fallback thread/resume: 37–1,705 ms
• total user-visible recovery: approximately 5.1–6.8 seconds

Already-loaded tasks switched quickly; the delay returned on the first open of other unloaded tasks.

Control evidence

• Responses WebSocket connected successfully (HTTP 101)
• No stream disconnected, os error 60, or HTTP-fallback markers during the sampled period
• Read-only integrity checks for the local state/logs/memories SQLite databases returned ok
• No swap use, thermal warning, disk-pressure, or system-wide CPU/memory exhaustion
• SkyComputerUseService was running during the samples
• The hidden avatarOverlay renderer also emitted Conversation state not found

This is consistent with the fixed local owner-discovery watchdog described in this issue, not slow transcript reads or general macOS resource pressure. The exact non-responsive IPC client is not independently proven by these samples.

This regression has recurred across multiple days and substantially affects users who switch among many tasks. No raw logs, conversation IDs, transcript content, private paths, or account information are included.

Same-day recurrence after updating to 26.803.61601 (build 6396)

After installing today's update, task opening was initially fast. The stall returned about four minutes after the new app process started.

Fresh evidence from the updated build:

• 21/21 cold task resumes hit maybe_resume_owner_discovery_failed after 5000–5009 ms (mean 5002.3 ms).
• The following thread/read took 2–24 ms (median 7 ms).
• Example (+08:00): 13:33:45.600 resume started → 13:33:50.604 owner-discovery timeout (5004 ms) → thread/read 7 ms.
• Bundled Codex: 0.147.0-alpha.6.5.

This update did not provide a durable fix: it briefly postponed or cleared the triggering state, then the exact regression returned. For users switching among many tasks, Desktop navigation becomes materially unusable. Please treat #37398 as a high-impact regression and confirm whether this build was expected to address it.

No raw logs, conversation IDs, transcript contents, local paths, or account data are included.

Still reproducible after today's desktop update:

• ChatGPT desktop 26.803.61601 (build 6396)
• Bundled Codex 0.147.0-alpha.6.5
• macOS 26.6.1 arm64
• The app was briefly responsive immediately after updating, then the fixed task-opening delay returned.
• In one post-update launch, the sanitized app log contains 21 maybe_resume_owner_discovery_failed ... timeout events, 73 Conversation state not found errors, and 250 unknown-conversation errors.
• No service was killed and no settings or project files were changed.

The same post-update evidence is documented in #37686, including the observed Computer Use service correlation. This confirms the issue is not limited to the previous desktop build and should be treated as a regression in 26.803.61601.

Additional A/B evidence (sanitized; the installed official app was not modified):

• Baseline on Desktop 26.803.41515 (6321): cold local-thread opens consistently spent ~5.0 s between maybe_resume_started and maybe_resume_owner_discovery_failed errorMessage=timeout; only afterward did thread/read finish in ~4–12 ms and thread/resume in ~40–120 ms.
• A hidden avatarOverlay renderer was prewarmed with rendererWindowVisible=false, received unrelated conversation broadcasts, and sometimes logged Conversation state not found, even with the pet tucked and Computer Use PIP hidden.
• Destroying that renderer was not durable because Desktop recreated it.

In an isolated test copy based on official Desktop 26.803.81509 (6415), disabling both normal-navigation followExistingOwner and hidden avatarOverlay/secondary-window prewarming reduced cold switches to 24–54 ms, with no owner-discovery timeout and no avatar renderer traffic.

This is isolation evidence, not a proposed end-user patch. It supports a product fix that:

1. starts thread/read without serially blocking on the 5 s ownership watchdog (or reconciles ownership asynchronously);
2. excludes hidden/non-thread surfaces such as avatar/PIP from owner discovery and thread broadcasts;
3. does not prewarm those surfaces when the feature is disabled/tucked; and
4. logs client/window identity on discovery timeout.

The Computer Use trigger may be another instance of the same IPC-client class; see #37686. Full detail was also added to #37397. No raw logs, thread IDs, prompts, project paths, or account data are included.

Still reproducible on the latest macOS desktop build (independent confirmation)

Tested today on the unmodified official desktop app:

• ChatGPT/Codex Desktop: 26.803.81509 (build 6415)
• Bundled Codex CLI: 0.147.0-alpha.6.6

Three cold opens of unloaded local tasks in the same post-update session all hit the same fixed watchdog before fallback:

| Resume started | Owner discovery timeout | Wait |
| --- | --- | --- |
| 11:51:15.797 | 11:51:20.798 | 5,001 ms |
| 11:51:29.952 | 11:51:34.953 | 5,001 ms |
| 11:55:27.485 | 11:55:32.487 | 5,002 ms |

For the controlled third run, the fallback immediately succeeded: thread/read 9 ms, thread/resume 69 ms, and thread/turns/list 9 ms. This rules out local transcript I/O or thread-database performance as the source of the five-second user-visible delay.

The app had also completed a one-off primary-runtime setup after updating before these tests; the exact 5-second pattern remained afterwards. Database integrity checks passed and the system had no CPU, memory, or swap pressure during reproduction.

A hidden avatarOverlay renderer was created with visible=false despite the overlay being closed, received task events, and logged Conversation state not found following resumes. This is consistent with hidden/secondary clients being involved in the ownership/broadcast path, but this observation alone does not identify the single non-responsive client.

This confirms that build 6415 did not fix the navigation regression. A product fix should avoid serially blocking local task hydration on the 5-second owner-discovery watchdog and should ensure non-owner/hidden IPC clients return an immediate negative response or are excluded from the discovery fan-out.

No raw logs, conversation IDs, paths, prompts, account data, or tokens are attached.

Confirmed this persists in Codex Desktop 26.803.61601 (bundled app-server 0.147.0-alpha.6.5) on macOS 15.7.3 (24G419), Apple Silicon.

Fresh reproduction after quitting and reopening the app:

• Chat active → maybe_resume_started: 45 ms
• maybe_resume_started → maybe_resume_owner_discovery_failed errorMessage=timeout: 5,001 ms
• thread/read: 4 ms
• thread/resume: 91 ms
• Chat active → maybe_resume_success: 5,202 ms

So the fixed owner-discovery timeout still blocks rendering in this newer build; reading and resuming the thread remain fast.

Independent confirmation from another affected Mac; this remains reproducible on August 13, 2026.

Environment

• ChatGPT/Codex Desktop: 26.803.61601 (build 6396)
• Bundled Codex: 0.147.0-alpha.6.5
• Computer Use helper: 26.804.1000633
• macOS 27.0, Apple Silicon / arm64

Current-session evidence

SkyComputerUseService started as a child of ChatGPT about three seconds after the desktop process. In this fresh app session, 4/4 primary-window cold task resumes reached the full owner-discovery watchdog:

13:21:18.041 maybe_resume_started
13:21:23.042 maybe_resume_owner_discovery_failed errorMessage=timeout  # 5,001 ms
13:21:23.083 thread/read completed                                  # 7 ms
13:21:23.234 thread/resume completed                                # 117 ms

13:25:44.881 maybe_resume_started
13:25:49.883 maybe_resume_owner_discovery_failed errorMessage=timeout  # 5,002 ms
13:25:49.923 thread/read completed                                  # 6 ms
13:25:50.050 thread/resume completed                                # 118 ms

The other two sampled primary cold resumes showed the same fixed timeout; their subsequent thread/read operations took 8–10 ms and thread/resume took 61–63 ms.

I also tested with Tailscale fully exited; the same fixed five-second timeout persisted. That makes a VPN/network path unlikely and is consistent with the local IPC/helper diagnosis already documented here.

Impact: task contents are fast to read, but each unloaded task is blocked on owner discovery before fallback. Please have non-owner clients return an immediate negative capability response, or avoid serially blocking local task hydration on this watchdog.

No raw logs, conversation IDs, task contents, account data, or local paths are included.

First data point on the current build pairing: on my machine (macOS 26.5.2 arm64) the stall has not recurred since updating to Desktop 26.814.41407 (build 6720) + Computer Use helper 26.817.1000761 — small sample so far, but a clean same-machine A/B.

From the Electron logs (UTC):

• 26.803.61601 (build 6396), 08/12–08/18: 22 maybe_resume_owner_discovery_failed out of 41 resume attempts. Representative: 00:26:10.666Z started → 00:26:15.668Z timeout (fixed 5.002 s) → 00:26:15.914Z fallback success.
• 26.814.41407 (build 6720), 08/19: 4 resume attempts, 0 discovery failures — three completed in 0.45 s / 0.02 s / 0.5 s; the fourth was a no-op probe of an already-resumed, owner-assigned thread (previousResumeState=resumed previousStreamRole=owner), not a stall.

Notably, the helper is still connected to ~/.codex/ipc/ipc.sock on the new pairing (confirmed via lsof), so if this holds, the improvement looks like a router- or protocol-side change rather than the helper disappearing from the bus — consistent with the silent-client direction discussed above. Labelled hypothesis until more samples accumulate; I will report back if the timeout recurs on build 6720.

More samples for the A/B above, and a correction of an earlier version of this comment.

• 7 resume attempts / 0 owner-discovery timeouts in total since the update, completions in 0.02–1.1 s (e.g. maybe_resume_started 2026-08-19T00:11:32.232Z → maybe_resume_success 00:11:32.254Z), versus 22 timeouts out of 41 attempts on the older builds noted above.
• Correction: helper 1000761 is still connected to ~/.codex/ipc/ipc.sock. lsof shows its client side as a plain unix endpoint (->0x…) whose peer is the socket ChatGPT has bound to the ipc.sock path; an earlier reading of the same output missed that peer mapping and wrongly reported the helper as absent from the bus.

So the improvement on this pairing is not the helper disappearing from the bus: either the router no longer blocks owner discovery on a silent client, or the new helper answers discovery — hypothesis; I can't distinguish the two from outside. Either way, desktop 26.814.x + helper ≥ 1000761 remains the comparison point for anyone still affected on older builds, and I will report back here if the timeout recurs on this pairing.