Chronicle research preview breaks all third-party screen sharing system-wide (macOS) until reboot
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
replaydis 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
- macOS 26.x on Apple Silicon, ChatGPT desktop app with Chronicle research preview enabled and running.
- Leave the app running for a while (failure state accumulates; on this machine it was reliably present after normal use).
- Attempt a screen share from Chrome (Google Meet) or any
getDisplayMedia-based platform. - Observe: share starts and stops within ~1 s;
log show --predicate 'process == "replayd"'shows thestopAllStreams/cs_flagspattern above.
Workaround (verified)
- Disable Chronicle (Settings → Personalization → Memory → Chronicle research preview).
killall codex_chronicle; killall -9 replayd(launchd respawns replayd with clean state).- Screen sharing works immediately in all applications; log confirms no further
stopAllStreamsevents. 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
SCShareableContentenumeration when calls fail, rather than retrying ~1/s indefinitely.
Happy to provide fuller log excerpts on request.