Codex Threads Take 5 Seconds to Open? Stop Computer Use Temporarily

If every unopened historical Codex task pauses for almost exactly five seconds, stop any active Computer Use task, save its state, and quit SkyComputerUseService. Current macOS reports show that the helper can remain connected to Codex without answering thread-owner discovery, so Codex waits for its five-second watchdog before reading the task. Quitting that helper restores normal task switching until Computer Use starts it again.

This is a narrow workaround, not a permanent repair. Update Codex and the Computer Use plugin first. Do not delete task history, clear ~/.codex/ipc, reinstall the app, or remove screen-recording permissions just because a task opens slowly.

Confirm the Fixed Five-Second Signature

The useful clue is repeatability. In the affected builds, a historical task that has not been opened in the current app session waits about five seconds. Once the timeout ends, the task itself loads in milliseconds.

Check this sequence before changing anything:

1. Fully quit and reopen Codex.

2. Open one historical local task and time the loading screen.

3. Open two other historical tasks that have not yet been opened in this app session.

4. Compare those results with a task already opened in the current session.

The current reports measured cold-open delays of roughly 5001-5066 ms. Their sanitized logs showed this sequence:

maybe_resume_started
  -> thread-owner-discovery
  -> 5000 ms timeout
  -> maybe_resume_owner_discovery_failed
  -> thread/read

The important split is that thread/read then completed in about 3-7 ms. That points away from a large transcript, damaged rollout file, remote network, or slow MCP startup.

Do not call every slow task this bug. A fixed watchdog interval across several cold opens is the distinguishing evidence.

Stop the Computer Use Helper Safely

First stop any active Computer Use task. Quitting the helper interrupts Computer Use, so do not do this while it is clicking, typing, recording, or waiting for an approval.

On macOS, open Activity Monitor, search for SkyComputerUseService, select it, and choose Quit. If it does not quit normally, use Force Quit only after the Computer Use task is stopped.

The equivalent Terminal command is:

/usr/bin/killall SkyComputerUseService

Expected result:

• SkyComputerUseService exits;

• the next unopened historical task loads without the fixed five-second pause; and

• ordinary task reading, editing, and shell work continue.

Test at least three unopened historical tasks. A single fast open is not enough to distinguish a warm cache from a repaired discovery path.

Computer Use will relaunch the helper when you invoke it again. The delay can return immediately after that. If you need Computer Use, finish that bounded GUI task, stop it cleanly, quit the helper again, and keep consequential app actions behind visible approvals.

Why This Workaround Fits

Codex Desktop coordinates multiple local surfaces over its IPC bus. Before hydrating a task, it can ask connected clients whether another surface already owns that thread. A current report found that SkyComputerUseService 26.804.1000633 stayed connected but did not answer the discovery request with a quick negative response.

That creates a clean A/B test:

• helper running: discovery waits for the full five-second timeout;

• helper stopped: discovery returns no-client-found in about 4 ms; and

• Computer Use invoked again: the helper restarts and the timeout returns.

Two earlier reports documented the same owner-discovery timeout after the 26.803.41515 desktop update. One received a second-machine confirmation, and a new August 9 report tied the recurrence specifically to starting Computer Use. The earlier issue was closed as completed, but the newer reproduction means you should verify your installed build instead of assuming the fix has reached every channel.

The evidence does not show that task data is corrupt. It also does not establish that every IPC warning, hidden renderer, or Computer Use delay shares this cause.

Avoid Destructive False Fixes

The reports already ruled out several tempting detours:

• Do not delete ~/.codex/ipc. A fresh IPC socket still reproduced the timeout.

• Do not strip images or rewrite rollout JSONL files. The delay persisted after large inline image payloads were removed.

• Do not delete historical tasks. thread/read was fast after discovery timed out.

• Do not disable macOS Screen Recording or Accessibility permissions as a latency fix.

• Do not remove Computer Use runtime folders or change their ownership.

• Do not kill unrelated Codex, ChatGPT, replayd, or WindowServer processes.

If replayd or WindowServer also stays busy while Computer Use is idle, that is a separate containment path. Use the Codex Computer Use high-CPU guide and verify the process pair before acting.

Update and Retest the Supported Path

Check the Codex app version in the About dialog and the Computer Use version in its plugin details. Update both through their supported app surfaces, fully quit the desktop app, and start a fresh session.

Retest in this order:

1. With Computer Use still idle, open three historical tasks that are cold in the current session.

2. Record the approximate latency for each.

3. Run one harmless, read-only Computer Use task against a disposable window.

4. Stop that task cleanly.

5. Open three more cold historical tasks.

Success means both groups open without the fixed timeout and Computer Use completes normally. If only the second group regresses, preserve the exact app and helper versions plus sanitized maybe_resume_* timestamps. Add that evidence to the upstream issue rather than opening a duplicate.

Use a Structured Action When the GUI Is Not Required

Computer Use is appropriate when a task truly depends on a graphical interface. OpenAI recommends keeping those actions scoped and reviewing permissions because they can affect state outside the project workspace.

Many monitoring and data-retrieval jobs do not need a GUI. For example, checking whether the upstream issue changed state is safer through a reviewed read-only GitHub Action. Aident Loadout can discover the current Action, show its schema, preflight its cost, and run it without placing a GitHub token in the prompt.

Start with this exact setup phrase:

Follow https://aident.ai/SETUP.md

Then ask:

Check Aident Loadout authentication and Vault status. Search the staging capability catalog for the current read-only GitHub issue lookup Action, inspect its schema, and preflight exact lookups for openai/codex issues 37397, 37398, and 37686. If the estimates are valid and free, execute them and return only issue number, state, updated time, labels, title, and canonical URL. Do not use Computer Use, comment, react, edit, close, create, or expose credentials.

Success is measurable: all three issue states return through the structured integration, no GUI helper starts, no GitHub write occurs, and no provider credential appears.

Set up Aident Loadout and monitor the owner-discovery fix.

Sources

• OpenAI: Computer Use

• OpenAI Codex issue 37397: local threads wait on owner discovery

• OpenAI Codex issue 37398: unloaded chats wait about five seconds

• OpenAI Codex issue 37686: Computer Use restarts the fixed delay

Refresh this guide when issue 37686 changes state, a Codex or Computer Use release removes the A/B, or OpenAI documents the thread-owner discovery fix.