Consistent 5-second delay when opening historical tasks after Computer Use is started

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

• #37398
• #37397

Powered by Codex Action

Independent reproduction on an older macOS release, which suggests this is not specific to macOS 26.x.

Environment

• ChatGPT/Codex Desktop: 26.803.41515 (build 6321)
• Bundled app-server: 0.147.0-alpha.6.5
• Computer Use service: 26.804.1000633
• macOS 14.6.1, Apple Silicon / arm64
• SkyComputerUseService was running during the reproductions

Representative timing

15:27:32.691 maybe_resume_started
15:27:37.693 maybe_resume_owner_discovery_failed errorMessage=timeout
15:27:37.711 thread/read completed (4 ms)
15:27:37.913 thread/resume completed (182 ms)

The owner-discovery wait was 5,002 ms. The underlying thread read/resume completed immediately afterward.

Frequency and isolation

• 30 owner-discovery timeouts across 21 distinct local threads in one day
• 4 timeouts immediately after a fresh desktop-app launch
• Reproduced across transcript sizes from approximately 2.9 MB to 91 MB
• Local SQLite PRAGMA quick_check returned ok
• Maximum observed thread/read duration that day was 193 ms
• A hidden avatarOverlay renderer also logged Conversation state not found and unknown-conversation turn events

This independently supports the diagnosis that a secondary IPC client is blocking thread-owner discovery until the five-second watchdog expires. In this session, both SkyComputerUseService and the hidden avatar overlay renderer were present. I did not terminate the Computer Use service during this evidence collection, so I have not independently verified the workaround yet.

No thread IDs, local paths, prompts, or raw logs are included.

Confirming this exact issue with an independent reproduction on macOS.

Environment

• ChatGPT/Codex Desktop: 26.803.41515 (build 6321)
• Bundled Codex: 0.147.0-alpha.6.5
• macOS 26.6.1, arm64
• SkyComputerUseService is running and started with the desktop app session

Reproduction in the current app session

Five out of five primary-window cold thread resumes followed the same sequence:

maybe_resume_started
~5001–5003 ms
maybe_resume_owner_discovery_failed errorMessage=timeout
thread/read

After the owner-discovery timeout, thread/read completed in only 6–9 ms. This makes the fixed delay distinct from transcript loading.

Controls / health checks

• codex doctor: state databases healthy; thread inventory agrees with state DB
• WebSocket connected successfully (HTTP 101 Switching Protocols)
• Read-only PRAGMA quick_check returned ok for state_5.sqlite, logs_2.sqlite, and memories_1.sqlite
• No swap activity; system memory and disk space were healthy
• The same desktop log contained 710 unknown conversation events and 136 Conversation state not found events, predominantly from the hidden avatarOverlay renderer

There are 215 active rollout files totaling about 2.8 GB, which could amplify general UI latency, but it does not explain this deterministic five-second wait because the actual thread read remains in the single-digit millisecond range.

I did not terminate SkyComputerUseService because active work was running, so this is a read-only confirmation rather than a workaround test. The evidence strongly supports a registered local IPC/client surface failing to answer thread-owner discovery, forcing Desktop to wait for the full watchdog before falling back.

Please make non-owner clients answer immediately, exclude non-thread/hidden surfaces from owner discovery, or avoid blocking thread/read on the full five-second watchdog. Sanitized timing excerpts can be provided if needed; raw logs and thread contents are intentionally not attached.

Regression after today's desktop update (Aug 11, 2026)

The issue is still present in the newly updated build.

• ChatGPT desktop: 26.803.61601 (build 6396)
• Bundled Codex: 0.147.0-alpha.6.5
• macOS: 26.6.1 (arm64)
• App launch: 13:06:41 Asia/Shanghai
• Immediately after the update, historical tasks opened without the pause.
• Within minutes, the deterministic task-opening delay returned.
• In this single post-update app session, the sanitized app log already contains:
• 21 maybe_resume_owner_discovery_failed ... timeout events (13:10–13:33 local time)
• 73 Conversation state not found errors
• 250 unknown conversation errors
• SkyComputerUseService has remained active since 13:06:47.

No service was killed, no project files or settings were changed, and the recurrence happened under normal use. This strongly suggests the update did not fix the owner-discovery/watchdog path; at best it temporarily masked the issue immediately after launch.

This is a severe usability regression because every task switch can impose the same fixed wait. Please make owner discovery non-blocking (or fail immediately when no owner responds) rather than holding task resume for the full watchdog timeout.

Post-update regression evidence (2026-08-11, CST / UTC+8)

The issue persists in ChatGPT/Codex Desktop 26.803.61601 (build 6396), embedded codex-cli 0.147.0-alpha.6.5.

The app initially felt smooth immediately after updating, but the deterministic delay returned in the same fresh process (started 13:06:41 CST).

Snapshot from this process:

• 22 maybe_resume_started events
• 21 maybe_resume_owner_discovery_failed timeouts
• Latest reproduction: 13:33:45.600 start -> 13:33:50.604 timeout (5.004s)
• maybe_resume_success at 13:33:50.893
• 44 Conversation state not found events
• 132 unknown conversation events

Point-in-time control checks remained healthy: WebSocket HTTP 101, read-only SQLite quick_check passed, thread inventory agreed, and CPU/memory/swap/disk/SMART/thermal checks showed no system pressure. This supports a desktop client/app-server owner-discovery coordination regression rather than general Mac slowness or slow thread reads.

Impact: cold/historical task switching repeatedly blocks for about 5 seconds before fallback succeeds. Please escalate to the desktop/app-server owner-discovery path.

Independent confirmation on the current desktop build, with sleep/wake and network timing controls.

Environment

• ChatGPT/Codex Desktop: 26.803.61601 (build 6396)
• Bundled Codex: 0.147.0-alpha.6.5
• Computer Use service: 26.804.1000633
• macOS 26.5.2 (25F84), Apple Silicon / arm64
• SkyComputerUseService was running during these observations

Reproduction on the current build

On 2026-08-14 (UTC+8), three different cold/unhydrated local threads were opened in the same desktop process. All three followed the same fixed-delay sequence:

| Cold resume | Owner-discovery wait | thread/read | thread/resume |
|---|---:|---:|---:|
| 1 | 5,002 ms | 21 ms | 358 ms |
| 2 | 5,002 ms | 7 ms | 64 ms |
| 3 | 5,002 ms | 8 ms | 82 ms |

Each sequence was:

maybe_resume_started
~5002 ms
maybe_resume_owner_discovery_failed errorMessage=timeout
thread/read
thread/resume
maybe_resume_success

Threads already hydrated in the same renderer switched back almost immediately. This confirms that the delay is not transcript parsing or SQLite read time.

Sleep/wake and network isolation

A separate reproduction occurred immediately after a real macOS full wake:

• Full wake recorded at 19:07:43 local time.
• The local proxy/TUN was already processing traffic within about one second of wake, and successful proxied external connections were present before the affected thread was opened.
• The cold thread was opened at 19:07:55.
• Owner discovery still waited the full five-second watchdog before the local read/resume fallback completed.

The host was local, so this supports the existing diagnosis that the deterministic wait is in local IPC/client coordination rather than Internet reachability, proxy port availability, or remote transcript loading.

I have not terminated SkyComputerUseService, so this is an independent read-only confirmation rather than a verification of the reported workaround.

No thread IDs, local paths, prompts, transcript content, or raw logs are included.

This issue has been resolved in ChatGPT for macOS version 26.810.41047 (build 6570). After updating to this version, the problem no longer occurs. This issue can be closed.