codex - 💡(How to fix) Fix Chronicle can drive replayd to 100% CPU and make CleanShot / ScreenCaptureKit hang on macOS 26.0 [1 participants]

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:

• #19134: recurring macOS private-window-picker / screen-and-audio prompt after Allow
• #19126: Chronicle triggering high coreaudiod CPU with Rogue Amoeba ARK / SoundSource
• #19516: orphaned codex_chronicle after killed app causes lock-wait loop and high CPU
• #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.