openai / openai/codex

macOS: enabling Computer History causes periodic WindowServer ping timeouts and UI input hitching

Open
#38,562 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug computer-use performance
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

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

ChatGPT/Codex Desktop 26.810.41047 (build 6570)

Bundled Computer Use runtime: 26.812.1000717 (build 1000717)

What subscription do you have?

Not provided; this appears to be a local macOS Desktop/Computer Use performance issue.

What platform is your computer?

Darwin 25.5.0 arm64 arm

  • macOS 26.5.2 (25F84)
  • MacBook Pro, Apple M2 Max, 64 GB RAM
  • One built-in display; no external display connected during the reproduction
What issue are you seeing?

Enabling Computer History in Codex Desktop caused intermittent system-wide UI/input hitching after wake from sleep. The mouse cursor and app switching would briefly catch even though the machine had substantial CPU and memory headroom.

While the problem was occurring, the following Computer Use clients were active:

SkyComputerUseClient computer-history mcp
SkyComputerUseClient event-stream mcp

WindowServer stayed around 39–45% CPU. More importantly, the macOS unified log repeatedly showed the Computer Use client PIDs missing WindowServer pings, followed by event-buffer cleanup and occasional transaction timeouts. Sanitized examples:

WindowServer: pid <computer-history-pid> failed to act on a ping it dequeued before timing out.
WindowServer: pid <event-stream-pid> failed to act on a ping it dequeued before timing out.
WindowServer: Clearing datagram buffer for cid <redacted>.
WindowServer: transaction <redacted> timed out

The ping failures recurred roughly every 10–15 seconds during portions of the affected interval.

This did not look like general system saturation:

  • overall CPU was 75–85% idle after other known workloads were stopped;
  • memory_pressure reported 77% free;
  • there was no active swap I/O;
  • disk I/O was near idle;
  • no GPU reset, GPU hang, AGX timeout, or Metal fault was found;
  • the only remaining Computer Use clients were the two shown above.

After disabling Computer History:

  • SkyComputerUseClient computer-history mcp exited;
  • SkyComputerUseClient event-stream mcp remained active;
  • a 30-second unified-log observation recorded zero ping failures, transaction timeouts, or datagram-buffer clears;
  • WindowServer CPU remained around 41–45%, but the intermittent input/UI hitching disappeared subjectively.

This suggests that the hitching is related to Computer History's event-monitor/client lifecycle rather than simply the baseline WindowServer CPU percentage.

What steps can reproduce the bug?

This is the sequence that reproduced the issue once on the system above:

  1. Launch Codex Desktop on macOS.
  2. Enable Computer History.
  3. Allow the Mac to sleep, then wake it.
  4. Use the Mac normally and observe intermittent cursor/app-switching hitching.
  5. Confirm that both computer-history mcp and event-stream mcp clients are active.
  6. Inspect WindowServer logs for repeated client ping timeouts.
  7. Disable Computer History.
  8. Confirm that the computer-history mcp client exits and the WindowServer ping timeouts stop.
  9. Observe that the intermittent hitching is no longer noticeable.

Useful read-only diagnostic commands, with output sanitized before sharing:

ps -axo pid,ppid,%cpu,%mem,etime,command | rg 'SkyComputerUseClient|WindowServer'

/usr/bin/log show --last 20m --style compact \
  --predicate 'process == "WindowServer"' \
  | rg -i 'failed to act on a ping|transaction.*timed out|Clearing datagram buffer'

Sleep/wake may be part of the trigger; I have not yet confirmed whether enabling Computer History without a sleep cycle reproduces it.

What is the expected behavior?

Computer History should run with low background overhead and should not cause its Computer Use client—or other active Computer Use clients—to miss WindowServer event-delivery pings. Disabling the feature should not be required to keep mouse and UI input smooth.

Additional information

Potentially related, but not an exact duplicate:

  • openai/codex#35659 tracks a stale ScreenCaptureKit stream and event-stream mcp clients driving high WindowServer GPU/CPU. In this reproduction, the distinguishing signal is periodic WindowServer ping failure tied to the computer-history mcp client, and disabling Computer History clears the hitching while one event-stream mcp client remains.
  • openai/codex#25744 tracks accumulated Computer Use/MCP helpers and HID/WindowServer/TCC stalls. This reproduction did not have dozens of SkyComputerUseClient processes; it had one history client and one event-stream client.

No raw unified logs, screenshots, thread contents, workspace paths, hostnames, or other local identifiers are attached.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the sleep/wake sequence with Computer History enabled, then run the provided ps and /usr/bin/log show diagnostics while both SkyComputerUseClient processes are active. Compare the logs before and after disabling Computer History, and investigate the history client lifecycle; done means Computer History no longer causes WindowServer ping failures or UI/input hitching.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos
Domain
desktop, operating-systems, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.