Chronicle can drive replayd to 100% CPU and make CleanShot / ScreenCaptureKit hang on macOS 26.0

[KaishuShito]

What issue are you seeing?

On one Mac, enabling Codex Chronicle appears to make macOS replayd spin at roughly 99-100% CPU. While this is happening, CleanShot X becomes very slow and ScreenCaptureKit calls can hang or time out. Disabling Chronicle and killing the stale Chronicle / replayd processes immediately restores CleanShot and ScreenCaptureKit behavior.

This looks like a Chronicle + macOS ScreenCaptureKit / replayd interaction. CleanShot seems to be affected because it shares the same macOS screen capture service, not necessarily because CleanShot is the root cause.

Environment

Main Mac where the issue reproduces:

macOS: 26.0 (25A354)
Architecture: arm64
Codex Desktop: 26.422.71525 (bundle version 2210)
Codex Chronicle binary: /Applications/Codex.app/Contents/Resources/codex_chronicle
codex_chronicle sha256: 6a599d41e5b2f4e5efd392526f43a26eff8df5971fe741e237da8247b1aa30e1
codex_chronicle mtime/size: Apr 29 10:40:18 2026, 4427728 bytes
CleanShot X: 4.8.8
Current display setup: built-in Color LCD + external P27FBA-RAGL 1920x1080 @ 100Hz

Codex app entitlements include:

com.apple.security.device.audio-input = true

Comparison Mac mini where Chronicle and CleanShot coexist normally:

macOS: 26.2 (25C56)
Codex Desktop: 26.422.62136
Codex CLI: codex-cli 0.124.0
CleanShot X: 4.8.8
Display: single external P27FBA-RAGL, 1920x1080 @ 100Hz
Observed load: codex_chronicle ~0.5-2.6%, replayd ~0.0-0.7%, CleanShot X ~0.0%
Chronicle latest.jpg stayed fresh on that machine

Symptoms observed on the affected Mac

When Chronicle is enabled:

• codex_chronicle starts and spawns a --list-displays-child process.
• replayd rises to approximately 99-100% CPU.
• CleanShot X becomes noticeably slow.
• Chronicle does not produce a fresh latest.jpg under $TMPDIR/chronicle/screen_recording/.
• Chronicle-generated memory summaries stopped updating. The latest local summary I found was from 2026-04-22 23:17 JST.
• A minimal ScreenCaptureKit test that calls SCShareableContent can hang / time out while the system is in this state.

When Chronicle is disabled in Codex Settings and stale processes are killed:

• replayd drops back to roughly 0.0-0.1% CPU.
• CleanShot X becomes fast again.
• The same minimal ScreenCaptureKit test succeeds quickly. One successful run completed in 0.027s and returned displays 1, windows 25.

At the time of filing, Chronicle is intentionally disabled on this Mac as a workaround. Current process state is stable:

coreaudiod: 0.0% CPU
CleanShot X: 0.0% CPU
replayd: 0.0% CPU
no active codex_chronicle process

Reproduction / isolation steps already tried

1. Enable Chronicle in Codex Desktop.
2. Observe codex_chronicle start.
3. Observe replayd climbing to ~99-100% CPU.
4. Try CleanShot X capture; CleanShot becomes slow.
5. Check Chronicle temp capture directory; latest.jpg is missing or stale.
6. Run a small ScreenCaptureKit / SCShareableContent test; it can hang or time out.
7. Turn Chronicle off from Codex Settings.
8. Kill stale codex_chronicle and restart/kill replayd if needed.
9. Observe CleanShot and ScreenCaptureKit recover immediately.

I also tried removing the external display and leaving only the built-in display. Chronicle still triggered the bad state, so this does not appear to be caused solely by multi-display capture. However, multi-display capture may still be a contributing factor or amplifier.

Expected behavior

Chronicle should not put replayd into sustained 99-100% CPU, and it should not make other ScreenCaptureKit-based apps such as CleanShot X unusable.

If Chronicle cannot acquire screen capture cleanly, it should fail or back off rather than leaving replayd saturated and failing to write fresh capture frames.

Actual behavior

Chronicle appears to enter a bad capture state where replayd stays saturated, Chronicle capture output is not fresh, and other screen capture apps become slow until Chronicle is disabled and stale processes are cleared.

Related issues

This seems related to several recent Chronicle / macOS capture issues, but I did not find an exact CleanShot + replayd report:

• Chronicle on macOS repeatedly re-triggers the "private window picker" screen/audio prompt after Allow #19134: recurring macOS private-window-picker / screen-and-audio prompt after Allow
• Codex Chronicle triggers high coreaudiod CPU with Rogue Amoeba ARK / SoundSource #19126: Chronicle triggering high coreaudiod CPU with Rogue Amoeba ARK / SoundSource
• Desktop: orphaned codex_chronicle after killed app causes lock-wait loop and high CPU #19516: orphaned codex_chronicle after killed app causes lock-wait loop and high CPU
• Chronicle: allow selecting captured displays and add a global pause/resume shortcut #19341: request for selected-display capture and pause/resume controls

The lifecycle aspect in #19516 is especially plausible here because this affected Mac had a Codex app freeze during an update before the issue was noticed.

Workaround

Keep Chronicle disabled on the affected Mac. If it has already entered the bad state, disable Chronicle, then stop stale helpers:

pkill -f '/Applications/Codex.app/Contents/Resources/codex_chronicle'
killall replayd

After that, CleanShot and ScreenCaptureKit recover.

Additional notes

The comparison with the Mac mini suggests that high refresh rate alone is probably not the whole explanation: the Mac mini is using the same external display at 100Hz and runs Chronicle + CleanShot normally. The affected Mac is still on macOS 26.0, while the healthy Mac mini is on macOS 26.2, so this may involve a macOS ScreenCaptureKit / replayd bug that newer macOS builds handle better.

[KaishuShito]

Follow-up with a narrowed repro and likely fix direction from the same affected Mac.

Environment:

macOS: 26.4.1 (25E253), arm64
Codex Desktop: 26.506.31421
Codex bundle version: 2620
prod codex_chronicle sha256:
dd7aa739aad2477cf8798d29e38b4588790bb5c5cf13402dbd18c9780ddf115a

This is still the latest prod appcast entry I see. The installed helper matches the official prod zip helper. The beta helper for 26.506.31421 / bundle 2619 also fails the same way.

Direct child request:

printf '%s\n' '{"request":"list_displays"}' \
  | /Applications/Codex.app/Contents/Resources/codex_chronicle --screen-capture-child

Result:

rc=124
ScreenCaptureKit child exceeded 5000ms timeout; forcing exit

This also reproduces when:

• running from a /tmp copy of the helper
• running with a nearly empty environment
• running an ad-hoc re-signed /tmp copy
• after restarting replayd

TCC/unified logs show TCC Allow; this does not look like a permission denial.

I sampled the helper while it was stuck:

codex_chronicle::screen::child::run_screen_capture_child
  codex_chronicle::screen::macos::get_displays_direct
    screencapturekit::shareable_content::SCShareableContent::get
      screencapturekit::utils::completion::SyncCompletion<T>::wait
        _pthread_cond_wait

The timeout thread was sleeping in:

codex_chronicle::screen::subprocess::arm_screen_capture_subprocess_timeout

The important narrowed finding: default SCShareableContent enumeration hangs on this machine, but filtered enumeration succeeds.

Default API:

SCShareableContent.getWithCompletionHandler { ... }

Result:

timeout default

Equivalent Rust screencapturekit = 1.5.4 default call also hangs:

SCShareableContent::get()

Filtered API:

SCShareableContent.getExcludingDesktopWindows(false, onScreenWindowsOnly: true) { ... }

Result:

ok 0.038s displays 2 windows 52 apps 12

onScreenWindowsOnly: true appears to be the key option:

getExcludingDesktopWindows(true, onScreenWindowsOnly: false)
timeout

getExcludingDesktopWindows(false, onScreenWindowsOnly: true)
ok 0.038s displays 2 windows 52 apps 12

Suggested fix direction for Chronicle's display inventory path:

let content = SCShareableContent::create()
    .with_on_screen_windows_only(true)
    .with_exclude_desktop_windows(false)
    .get()?;

I used exclude_desktop_windows(false) because it still returns the full display list locally; the important part appears to be on_screen_windows_only(true). Since the Chronicle list_displays path only needs display inventory, this should avoid the local replayd hang caused by enumerating all/off-screen windows.

With Chronicle disabled locally:

chronicle = false

there is no active codex_chronicle process, replayd returns to idle, and filtered Swift/Rust SCShareableContent probes succeed.

[Korkyzer]

Confirming this on a third machine with identical Codex / macOS versions.

Environment

macOS: 26.2 (25C56), arm64 (M5)
Codex Desktop: 26.506.31421
Codex bundle version: 2620

Quantified replayd saturation

While Chronicle was enabled, replayd was accepting short-lived client connections at a steady rate. Counted via:

/usr/bin/log show --last 2m --predicate 'process == "replayd" AND eventMessage CONTAINS "accepted client connection"' | grep -c "PID:"

Result: ~70 distinct client PIDs in 2 minutes (range observed: 4097 -> 4395 over 120s). Each PID was a codex_chronicle --screen-capture-child worker spawned by the parent codex_chronicle daemon (PPID match confirmed via ps -axo pid,ppid,command). Each child died within milliseconds, consistent with the documented 5000ms ScreenCaptureKit timeout hitting on the default SCShareableContent::get() call described by @KaishuShito above.

System-wide impact (beyond CleanShot)

The saturation breaks the entire macOS screen capture pipeline, not just third-party tools:

Path	Behavior
cmd+shift+3 / cmd+shift+4	freezes, no file produced
cmd+shift+5 (screenshot toolbar)	freezes
Shottr	freezes mid-capture
/usr/sbin/screencapture -x /tmp/x.png (CLI)	fails with could not create image from display

After codex features disable chronicle + killing the parent codex_chronicle PID, all four paths recovered immediately, no reboot required.

Reboots do not help

Worth flagging for anyone landing here: rebooting does not fix this. Codex auto-launches via macOS modern login items, codex_chronicle respawns within seconds of login, replayd is saturated again, and the system looks broken from a fresh boot. The only durable fix is the config toggle.

Workaround confirmed durable

/Applications/Codex.app/Contents/Resources/codex features disable chronicle

This writes features.chronicle = false to ~/.codex/config.toml. After quitting and relaunching Codex.app, the codex_chronicle daemon no longer spawns at all. replayd returns to 0 client connections / 10s and all screenshot paths work normally. Codex itself (chat, plan mode, app-server, MCP servers, computer_use, browser_use) keeps functioning fully.

Adding this here so future searchers find the systemic impact (not just CleanShot) and the durability of the workaround across restarts.