Chronicle research preview breaks all third-party screen sharing system-wide (macOS) until reboot

Start with the codex_chronicle workers and their ScreenCaptureKit getShareableContent calls, then reproduce the failure while watching replayd and securityd with the provided log predicates. Done means Chronicle no longer leaves replayd in a state that stops third-party capture streams, verified in Google Meet or On24 without rebooting; the payload names no repository files or tests.

Environment

• App: ChatGPT desktop for macOS, version 26.715.72359 (build 5718) — bug also present in builds going back ~2 months
• Feature: Chronicle research preview, enabled (Settings → Personalization → Memory)
• OS: macOS 26.5.2 (build 25F84)
• Hardware: MacBook Pro, Apple M4 Max, 128 GB RAM

Summary

With Chronicle enabled, screen sharing fails in all third-party applications (observed in Google Meet and the On24 webinar platform, both browser-based via getDisplayMedia). The share appears to start, then stops within a second. Once the failure state is triggered, it persists until the machine is rebooted (or replayd is manually restarted). The connection to Chronicle is not obvious to users — the visible symptom is "screen sharing is broken in my browser," which is why this went undiagnosed for roughly two months.

Root cause analysis (from unified log, captured during a live failure)

Chronicle's helper (ChatGPT.app/Contents/Resources/codex_chronicle) spawns short-lived worker processes that connect to replayd, enumerate shareable content via ScreenCaptureKit, and exit. The workers exit quickly enough that replayd/securityd cannot complete code-signing entitlement checks on them:

replayd  [com.apple.securityd:SecWarning] SecTaskLoadEntitlements: failed to get cs_flags, error=3, pid=42722
replayd  [ERROR] checkEntitlementArrayForToken:305 error copying entitlment from SecTaskRef, error=<private>

(A new short-lived PID appears every few seconds: 42722, 42732, 42734, 42738, ... — all confirmed via log show --predicate 'processID == <pid>' to be codex_chronicle workers calling +[SCShareableContent getShareableContentExcludingDesktopWindows:...].)

The accumulated failed handshakes leave replayd in a corrupted client state in which it tears down every capture stream roughly once per second:

replayd  [INFO] -[RPClient stopAllStreamsWithError:stopReason:]:1509 stopReason=0

During a Google Meet screen-share attempt (2026-07-22, ~10:17 local), this loop killed the browser's capture stream immediately on every start/retry. TCC screen-recording permission was confirmed granted throughout ("TCC Allow" logged on every check), ruling out a permissions issue.

Timing correlation: the stopAllStreams storm begins at 09:56:15, i.e., the same minute the ChatGPT app launched and codex_chronicle started (09:57) — hours before any user-initiated share attempt.

Impact

• All third-party screen capture/sharing on the machine fails until replayd is restarted or the machine is rebooted.
• The retry storm also generates abnormal load visible to the far end of WebRTC sharing sessions (the On24 platform independently reported "high load" from this client during share attempts).
• Because the symptom appears in unrelated apps, users are unlikely to attribute it to Chronicle.

Steps to reproduce

1. macOS 26.x on Apple Silicon, ChatGPT desktop app with Chronicle research preview enabled and running.
2. Leave the app running for a while (failure state accumulates; on this machine it was reliably present after normal use).
3. Attempt a screen share from Chrome (Google Meet) or any getDisplayMedia-based platform.
4. Observe: share starts and stops within ~1 s; log show --predicate 'process == "replayd"' shows the stopAllStreams/cs_flags pattern above.

Workaround (verified)

1. Disable Chronicle (Settings → Personalization → Memory → Chronicle research preview).
2. killall codex_chronicle; killall -9 replayd (launchd respawns replayd with clean state).
3. Screen sharing works immediately in all applications; log confirms no further stopAllStreams events. Verified in Google Meet and On24.

Suggested fix directions

• Keep Chronicle's capture workers alive long enough for replayd's entitlement validation to complete, or use a single persistent capture client instead of spawn-per-capture workers.
• Rate-limit/back off SCShareableContent enumeration when calls fail, rather than retrying ~1/s indefinitely.

Happy to provide fuller log excerpts on request.