Chronicle on macOS repeatedly re-triggers the "private window picker" screen/audio prompt after Allow

Open 💬 4 comments Opened Apr 23, 2026 by juato4

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop app 26.417.41555 (1858)

What subscription do you have?

Pro

What platform is your computer?

macOS 26.3 (25D125) on Apple Silicon

What issue are you seeing?

When Chronicle is enabled, macOS repeatedly shows the newer system alert:

"Codex" is requesting to bypass the system private window picker and directly access your screen and audio.

Clicking Allow does not stop the alert from returning later. The app appears to keep working, but the permission prompt comes back periodically while Chronicle remains enabled.

This is not the initial one-time Screen Recording permission sheet. This is the recurring private-window-picker / direct-access prompt.

The user wants to keep Chronicle enabled, so disabling Chronicle is not an acceptable workaround here.

What steps can reproduce the bug?

Enable Chronicle in Codex Desktop.
Launch Codex Desktop on macOS.
Keep using Codex with Chronicle active until codex_chronicle is running.
macOS shows the direct-access / private-window-picker alert for Codex.
Click Allow.
Continue using Codex with Chronicle still enabled.
The same alert appears again later.

What is the expected behavior?

After the user allows access, Codex should not keep re-triggering the same direct-access prompt during normal Chronicle use.

If this prompt is expected because of macOS / ScreenCaptureKit rules, Codex should:

minimize how often it triggers the prompt
avoid unnecessary audio-related capture paths
clearly explain in-product that this prompt may recur and why

Additional information

Local observations from this Mac:

running process: /Applications/Codex.app/Contents/Resources/codex_chronicle
bundle id: com.openai.codex
local unified logs on 2026-04-23 08:29:55 (America/Argentina/Buenos_Aires) show TCC attribution involving codex_chronicle / com.openai.codex for:
kTCCServiceScreenCapture
kTCCServiceMicrophone

This makes it look Chronicle-related rather than a generic missing Screen Recording permission.

There are already nearby macOS permission / capture issues in the tracker, but I did not find a public issue specifically for this recurring Chronicle + private-window-picker prompt.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#19126

Powered by Codex Action

juato4 · 4 months ago

Related to #19126, but not a duplicate.

#19126 reports high coreaudiod CPU with Rogue Amoeba SoundSource / ARK and audio-device churn.

This issue reports a different user-facing symptom on macOS: when Chronicle is enabled, Codex repeatedly re-triggers the system "private window picker" / direct screen-and-audio access prompt even after the user clicks Allow.

In other words, the overlap is that both seem Chronicle / capture-path related, but the repro and primary symptom here are the recurring macOS permission prompt, not SoundSource/ARK-specific CPU usage.

chrisvanbuskirk · 1 month ago

Additional confirmed reproduction on a newer build:

ChatGPT/Codex desktop app: 26.707.31428 (build 5059)
macOS: 26.5.1 (build 25F80)
Installed app path: /Applications/ChatGPT.app
Bundle ID remains com.openai.codex
Chronicle enabled (chronicle = true)

The same private-window-picker alert kept returning after clicking Allow, even though the system TCC database already showed kTCCServiceScreenCapture authorized for com.openai.codex (auth_value = 2). This confirms it was not the initial Screen Recording permission flow or a disabled Settings toggle.

A notable process-lifecycle finding: the machine had both:

the current /Applications/ChatGPT.app/Contents/Resources/codex_chronicle process; and
an orphaned /Applications/Codex.app/Contents/Resources/codex_chronicle --screen-capture-child process with PPID 1 that had survived for approximately 29 days.

The old /Applications/Codex.app path no longer existed; the orphaned capture child was still executing the prior signed binary retained in Sparkle's update cache. This suggests the app rename/update did not terminate the old Chronicle screen-capture child and may contribute to repeated macOS reauthorization prompts.

Codesign inspection also showed no com.apple.developer.persistent-content-capture entitlement on the current app or Chronicle capture executable.

The user has now disabled Chronicle as a workaround and is monitoring whether the prompt stops. The dialog on macOS 26.5.1 labels the action simply Allow, rather than Allow for one month.

benzionb · 28 days ago

Reproduced this on a newer build as well:

App: /Applications/ChatGPT.app (Codex desktop), version 26.721.81911, build 5973
Bundle ID: com.openai.codex
macOS: 26.5.2 (25F84), Apple Silicon
Chronicle was enabled and /Applications/ChatGPT.app/Contents/Resources/codex_chronicle was running
System Settings > Privacy & Security > Screen & System Audio Recording already showed ChatGPT: On

The exact prompt still returned every few minutes after clicking Allow. Refreshing the permission by toggling ChatGPT off/on and authenticating did not fix it.

Unified logs during the retry loop included repeated ChatGPT TCCAccessRequest activity and ReplayKit/TCC errors such as missing 'auth_value' in reply message, with capture authorization sometimes moving through TCC Disallow and then TCC Allow.

The only effective workaround was setting [features] chronicle = false in ~/.codex/config.toml and stopping the active codex_chronicle process. After that, the process stayed stopped and the permission requests ceased. Normal Codex Computer Use remains available separately.

This looks like a stale/inconsistent ScreenCaptureKit/TCC authorization path specific to Chronicle's recurring capture, not a missing Screen Recording toggle.