Computer History silently stops after repeated SkyComputerUseService SIGTRAP crashes

Summary

Computer History stopped recording during active Mac use on 2026-08-28/29. Its backend process, SkyComputerUseService, crashed seven times within 34 minutes. The final Computer History event was recorded eight seconds before the third crash, and later automatic process relaunches did not resume event capture. No recorder-facing coverage-gap alert was observed.

This concerns the passive Computer History recorder, not an interactive Computer Use session. SkyComputerUseService is named because it is the crashed process.

Environment

• Build: 26.826.1000901 (1000901)
• Bundle: com.openai.sky.CUAService
• macOS: 26.5.1 (25F80)
• Apple silicon (ARM-64)
• Time zone: Asia/Jerusalem (+03:00)

Crash signature

All seven Apple crash reports show:

• EXC_BREAKPOINT / SIGTRAP
• termination namespace SIGNAL, code 5
• _dispatch_assert_queue_fail
• dispatch_assert_queue
• _swift_task_checkIsolatedSwift
• later stack frame -[_NSDisplayLinkForwarder displayLinkDidFire:]

This is consistent with a queue/executor-isolation assertion in the display-link callback path. The exact source line and a deterministic manual reproduction are not known.

Recorder impact

• Last event: 2026-08-28T21:06:28Z (00:06:28 IDT).
• The open segment remained incomplete, without endedAt, eventCount, or suppressedEventCount.
• The event stream did not advance again until 2026-08-29T09:34:18Z, a 12 h 27 m 50 s gap. This is an event-stream gap, not a claim of continuous activity for the entire interval.
• The user reports that the Mac remained in use after recording stopped.
• A later successful restart proves only that capture resumed; it does not prove the crash or overnight survivorship is fixed.

Requested investigation

1. Identify the queue/executor-isolation violation in the display-link callback path.
2. Prevent a backend crash from stranding Computer History with a stale, incomplete segment.
3. Alert when the event file stops advancing while the Mac is active, even if top-level state still appears running.
4. Verify recovery with a long-running capture test that includes repeated backend relaunches.

Related reports

• #39183 has the same Computer History silent-loss outcome, but a different SIGABRT / AXObserverAddNotification crash signature.
• #41326 has the same build and queue/executor assertion family, but it concerns interactive Computer Use actions; this incident concerns passive Computer History recording and includes the display-link callback path.

Seven raw .ips files and the event-stream evidence are retained privately and can be supplied through an authenticated OpenAI support or engineering channel. They are intentionally not attached to this public issue because they contain persistent device/report identifiers and user activity context.

The payload names no repository files or tests. Start with the display-link callback path and the retained crash reports, then trace Computer History segment completion, event-file advancement, and backend relaunch behavior. Done means the isolation crash no longer strands recording, gaps are surfaced, and a long-running repeated-relaunch capture test verifies recovery.