›_ Codex Issues
Codex Issues / #36707

[macOS] Computer Use Mail inspection hangs and drives Mail CPU high

Open 💬 2 comments Opened Aug 3, 2026 by steveoon

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

26.727.51351 (6119)

What subscription do you have?

Not provided.

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6, build 25G70)

What issue are you seeing?

Codex Computer Use cannot inspect Apple Mail on macOS. Calling get_app_state({ app: "Mail" }) hangs for over 60 seconds without returning an accessibility tree or screenshot. The request does not reach any message composition or sending action.

The failure is reproducible after manually quitting and relaunching Mail. Immediately after relaunch, Mail is idle (0% CPU). A single read-only Computer Use inspection causes Mail to climb to roughly 77% CPU and log a rapid repeated sequence of:

Mail: WebProcessPool::initializeAccessibility

The Computer Use helper simultaneously logs repeated:

AccessibilitySupport.UIElementError Code=0
AccessibilitySupport.UIElementError Code=2

The helper did have macOS accessibility permission, and the network callback path was healthy in the failing run (TLS completed and the helper received HTTP 202 responses). This does not look like an account, IMAP, SMTP, permission, or proxy failure.

This appears similar in shape to #20683 (an app-specific get_app_state accessibility traversal failure for Outlook), but the affected application here is Apple Mail and the helper does not produce a crash report; instead, the request remains pending while Mail spins.

What steps can reproduce the bug?

  1. Use Codex Desktop on macOS with Computer Use installed and accessibility permission granted.
  2. Launch /System/Applications/Mail.app and wait until it is idle.
  3. From a Codex task, run the normal read-only Computer Use probe:

``js
await sky.get_app_state({ app: "Mail" });
``

  1. Observe that the call remains pending for more than 60 seconds and returns neither an accessibility tree nor a screenshot.
  2. Inspect Activity Monitor / unified logs while the request is pending:
  • Mail rises from idle to high CPU (about 77-101% observed).
  • Mail rapidly repeats WebProcessPool::initializeAccessibility.
  • SkyComputerUseService emits repeated AccessibilitySupport.UIElementError entries.
  1. Quit and relaunch Mail, then repeat step 3. The same behavior reproduces.

What is the expected behavior?

get_app_state should return a usable Mail accessibility tree and screenshot, or return a bounded, actionable error. It must not hang indefinitely or drive Mail into sustained high CPU usage from a read-only inspection.

Additional information

  • Computer Use helper version: 26.727.1000550 (build 1000550).
  • Mail's IMAP sync was healthy during the original diagnosis; no actual email was composed or sent.
  • Existing-issue search found no public exact match for Mail plus WebProcessPool::initializeAccessibility in openai/codex.
  • All content and account-identifying details have been removed from this report.

View original on GitHub ↗

2 Comments

Yurii201811 · 17 days ago

Retest on newer Computer Use build (2026-08-10)

I reproduced the same failure class on a newer Computer Use build.

Environment

  • Computer Use plugin/helper: 1.0.1000633
  • macOS: 27.0 (26A5406e)
  • Apple Mail: 16.0 (3901.100.1.1.5)

Observed behavior

  • Starting from an idle Mail process, a full Mail/Inbox app-state collection exposed a large accessibility state (about 37.6k characters, including thousands of message-table entries).
  • Mail then sustained approximately 106–196% CPU.
  • A process sample showed hot accessibility traversal involving NSAccessibilityChildren, NSTableViewCellMockElement, and MailUI label/layout work.
  • Stopping only SkyComputerUseService immediately returned Mail to approximately 0–1% CPU. Mail itself did not need to be quit or restarted.

Narrow mitigation tested

Opening a compact blank compose window before the first Mail state request reduced the returned accessibility state to about 3.6k characters. CPU showed only a brief transient peak (maximum observed 46.4%) and did not enter the sustained runaway state.

This newer result suggests the trigger is the breadth of full Inbox/table accessibility traversal rather than mail-account synchronization. Window-scoped inspection, table-row/depth limits, cycle/visited-element handling, and cancellation of active AX enumeration after timeout may be useful product-side safeguards.

No message content, sender information, account identifiers, or local paths are included here.

attilabal · 3 days ago

I can confirm a closely related case, with an additional symptom: the high Mail CPU usage occurred without an active Computer Use request targeting Mail.

Environment:

  • Codex Desktop: 26.818.41509 (build 6962)
  • Codex Computer Use helper: 26.819.1000816 (build 1000816)
  • macOS: 26.5.2 (25F84)
  • Apple Mail: 16.0 (3864.600.51.1.1)

Observed behavior:

  • Switching between already downloaded messages developed a repeatable delay of roughly 0.5 seconds.
  • Mail reached 110.8% CPU while otherwise idle apart from navigating the message list.
  • Changing networks and disabling the VPN made no difference.
  • Local message body loading and parsing were generally fast, so IMAP/network latency did not explain the UI delay.

A 10-second sample of Mail showed substantial main-thread activity in the accessibility hierarchy path:

mshMIGPerform
-> _XCopyHierarchy
-> _AXXMIGCopyHierarchy
-> __AXCopyAttributeValueForHierarchy

The sample also showed accessibility queries forcing NSTableView row lookup/creation, including:

NSTableViewCellMockElement accessibilityColumnIndexRangeAttribute
NSTableRowData rowViewAtRow:createIfNeeded:
Mail RichMessageCellView creation

The macOS TCC log attributed the Accessibility access to:

com.openai.sky.CUAService
SkyComputerUseService (PID 4635 in this run)

A/B result:

  1. Mail CPU before stopping SkyComputerUseService: 110.8%.
  2. Sent SIGTERM only to SkyComputerUseService; Mail and Codex Desktop remained running.
  3. The service exited.
  4. Mail CPU dropped to 3.8%.
  5. The perceptible delay when switching between messages disappeared immediately.

This suggests that SkyComputerUseService may continue traversing Mail's accessibility hierarchy in the background, even when there is no active request to inspect Mail. The traversal appears to force Mail to instantiate message-list rows, causing sustained CPU usage and UI latency.

Expected behavior:

  • Computer Use should not continuously traverse Mail's accessibility tree without an active user request.
  • Mail inspection should be bounded/cancellable and should not force sustained creation of off-screen message rows.