Codex Desktop Chronicle screen-capture helper repeatedly triggers macOS systemstatusd high CPU #24367

Summary

Codex Desktop's Chronicle screen-history capture appears to repeatedly spawn short-lived screen-capture helper processes on macOS. Each helper connects through replayd, triggers TCC screen-capture checks, and updates ScreenCapture attribution through systemstatusd. On my machine this causes systemstatusd to sustain very high CPU, often around 90%, with a significant power draw increase.

This is not a request to disable Chronicle or Computer Use. The desired fix is for Chronicle/Computer Use to remain enabled without driving systemstatusd into a high-CPU attribution loop.

Environment

• Codex Desktop: 26.519.41501
• macOS: 15.7.3 (24G419)
• Hardware: Apple Silicon MacBook Air, Apple M4, arm64
• Chronicle enabled
• Screen Recording permission granted to Codex
• Computer Use / screen-aware Codex features intentionally enabled

Observed behavior

• systemstatusd frequently sits around 85-95% CPU.
• replayd itself remains low CPU, but repeatedly accepts clients from:

/Applications/Codex.app/Contents/Resources/codex_chronicle --screen-capture-child

• In a 15-second log capture:
  • replayd accepted 8 Codex Chronicle screen-capture child clients.
  • replayd performed 16 TCC ScreenCapture allow checks.
  • systemstatusd logged 14 identity-resolution failures.

Representative log pattern:

replayd ... accepted client connection PID: <pid>
<pid> <ppid> ... /Applications/Codex.app/Contents/Resources/codex_chronicle --screen-capture-child

replayd ... TCC Allow
replayd ... STMediaStatusDomainPublisher update screenAttribution complete

systemstatusd ... Failed to find any name for executable with identity <STExecutableIdentity ...> {
    auditToken = <BSAuditToken ... PID: <same short-lived pid> ...>;
    isSystemExecutable = NO;
}

The helper process disappears quickly enough that systemstatusd often cannot resolve a display name for that executable identity.

Power / CPU impact

While this is happening:

• systemstatusd: about 90% CPU
• Instant battery telemetry: about -12.3 W

As a temporary diagnostic, restarting replayd caused:

• systemstatusd CPU to drop from about 90% to 0%
• Instant battery telemetry to improve from about -12.3 W to about -8.2 W

The improvement was not durable because the Chronicle screen-capture helper activity resumed. There are other active workloads on the machine, so the power numbers should not be read as the sole drain source; they show this loop is a major contributor.

Signing / identity clues

Codex main app identity looks normal:

Executable=/Applications/Codex.app/Contents/MacOS/Codex
Identifier=com.openai.codex
Format=app bundle with Mach-O thin (arm64)
Info.plist entries=34
TeamIdentifier=2DC432GLL2

Chronicle helper is a standalone Mach-O:

Executable=/Applications/Codex.app/Contents/Resources/codex_chronicle
Identifier=codex_chronicle
Format=Mach-O thin (arm64)
Info.plist=not bound
Sealed Resources=none
TeamIdentifier=2DC432GLL2

The repeated systemstatusd failures line up with short-lived codex_chronicle --screen-capture-child PIDs rather than the main Codex app bundle.

What I checked on the macOS side

I could not find a supported user-level macOS configuration to make systemstatusd ignore this attribution path while keeping screen capture enabled:

• com.apple.systemstatusd LaunchDaemon exposes only the daemon path and Mach services.
• defaults read com.apple.systemstatus and defaults read com.apple.systemstatusd have no domains.
• replayd defaults only showed a device UUID.
• Control Center's visible Audio/Video and Screen Mirroring menu bar items were already hidden.
• SystemStatus resource plists did not expose a screen-capture attribution or per-app ignore switch.
• macOS has privacy-indicator suppression strings/private APIs, but they require Apple/private entitlements and do not look like a safe or supported fix for third-party apps.

Expected behavior

With Chronicle and Computer Use enabled, Codex should not cause systemstatusd to spend a sustained ~one CPU core resolving screen-capture attribution.

Ideally one of these would happen:

• Chronicle uses a stable capture process instead of frequently spawning short-lived --screen-capture-child processes.
• The screen-capture helper has a stable, app-bundle-resolvable identity so macOS SystemStatus can attribute it to Codex without repeated failures.
• Chronicle coalesces screen-capture attribution updates or lowers capture frequency when the user is actively using Codex.
• Codex exposes a setting to reduce Chronicle screen sampling frequency while keeping Chronicle/Computer Use enabled.

Reproduction / diagnostics

1. Enable Codex Desktop Chronicle and grant Screen Recording permission.
2. Keep Codex open during active use.
3. Observe systemstatusd CPU via Activity Monitor or:

ps aux | grep systemstatusd

4. Capture the attribution loop:

/usr/bin/log stream \
  --style compact \
  --level info \
  --predicate 'process == "replayd" OR process == "systemstatusd"' \
  --timeout 15

5. Map accepted replay clients:

ps -p <pid_from_replayd_accepted_client_connection> -o pid,ppid,%cpu,%mem,stat,lstart,command

Actual: the accepted client is repeatedly:

/Applications/Codex.app/Contents/Resources/codex_chronicle --screen-capture-child

and systemstatusd repeatedly fails to find a name for the corresponding executable identity.

Why this matters

Chronicle and Computer Use are useful features and should stay enabled, but this loop makes Codex materially worse for laptop battery life on macOS. A fix on the Codex side would avoid telling users to choose between screen-aware Codex features and normal MacBook battery behavior.