[macOS][Computer History] SkyComputerUseService crashes in AXObserverAddNotification and does not restart, silently losing activity

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

ChatGPT/Codex Desktop 26.810.52044 (build 6662)

Computer History plugin: 1.0.1000717
SkyComputerUseService: 26.812.1000717 (build 1000717)

What subscription do you have?

ChatGPT subscription PRO

What platform is your computer?

Darwin 25.6.0 arm64 arm

• macOS 26.6 (25G72)
• Apple Silicon, Mac15,14

What issue are you seeing?

Computer History silently stopped recording after its native helper crashed and did not restart. The UI provided no warning, and the persisted Computer History configuration remained set to observe applications and URLs by default.

The recorder crash occurred at 2026-08-17 17:56:12 -0400:

Process: SkyComputerUseService
Bundle ID: com.openai.sky.CUAService
Exception: EXC_CRASH
Signal: SIGABRT
Termination: Abort trap: 6

Unrecognized selector:
-[_TtGC14SystemSoftware13WeakReferenceC20AccessibilitySupport22AXNotificationObserver_ length]

Relevant faulting stack:
_swiftObject doesNotRecognizeSelector:
___forwarding___
_CF_forwarding_prep_0
_AXObserverAddNotification
__processObserverForRemoteProcessNotifications_block_invoke

Immediately before the abort, unified logging showed repeated Accessibility errors:

Error Domain=AccessibilitySupport.UIElementError Code=0
Error Domain=AccessibilitySupport.UIElementError Code=2

The observer involved was attached to a normal foreground macOS application during a drag/drop interaction.

ChatGPT itself remained running after the helper aborted, but it did not relaunch the recorder. The Mac woke from sleep at 05:31:14 the next morning and normal user activity resumed, but there was no SkyComputerUseService process and no Computer History event stream.

The helper was finally spawned at 07:00:50, and the first new event was:

{"timestamp":"2026-08-18T11:00:51Z","kind":"session.started"}

Thus approximately 90 minutes of active morning work were never captured. The missing records cannot be recovered because no segment files were written.

This is not an observation-filter issue. The effective Computer History settings at diagnosis were:

{
  "observation": {
    "allowlist": [],
    "blocklist": [],
    "defaultApplicationBehavior": "observe",
    "defaultURLBehavior": "observe"
  }
}

What steps can reproduce the bug?

The exact Accessibility crash trigger is not yet deterministic, but this is the observed sequence:

1. Enable Computer History and leave it in the running state.
2. Use ChatGPT/Codex Desktop normally on macOS while switching among native applications.
3. Perform a drag/drop interaction while the recorder is observing accessibility/window events.
4. SkyComputerUseService aborts in _AXObserverAddNotification with the unrecognized-selector signature above.
5. Leave ChatGPT running; sleep and wake the Mac.
6. Continue normal foreground work.
7. Inspect Computer History status, the SkyComputerUseService process, or the Skysight segment directory.
8. Observe that the recorder remained absent after the crash and wake, with no segments written until a later interaction caused the helper to launch again.

The crash produced a complete macOS .ips report. I can provide a sanitized or private copy on request.

What is the expected behavior?

• Accessibility observation errors must not abort the recorder.
• If the helper does crash, the parent app should restart it with bounded retry/backoff while Computer History remains enabled.
• A running/enabled state should be reconciled with the actual helper process after crash and wake.
• If automatic recovery fails, the app should visibly report that Computer History is no longer recording.
• Background recording should resume immediately on user activity after wake without requiring a later Computer History interaction.

Additional information

There are two related reports, but neither has this crash signature or this silent non-restart/data-loss behavior:

• #36672 — different SIGSEGV in AsyncStream.yield, affecting Chrome backend availability
• #38697 — same helper build but launch-time SIGSEGV with an unbounded respawn storm

This report is the opposite lifecycle failure: one Accessibility-observer SIGABRT, followed by no automatic restart and silent loss of Computer History records.

Start with the SkyComputerUseService crash report and the AXObserverAddNotification fault signature, then trace how the parent app handles helper exits and macOS sleep/wake. Verify behavior with the documented crash, wake, and foreground-activity sequence. Done means accessibility failures do not abort recording, crashes recover with bounded retries, and an enabled but inactive recorder is reported visibly.