Codex Desktop on macOS cannot trigger Calendar/Reminders TCC prompts for EventKit CLIs

Open 💬 3 comments Opened May 5, 2026 by wadjj

Summary

Codex Desktop on macOS cannot trigger or obtain Calendar/Reminders TCC permissions for EventKit-based CLI tools launched from the Codex app terminal/tool context.

The same third-party CLIs work from iTerm after macOS prompts for access, but fail from Codex with immediate access-denied errors and no permission prompt.

Environment

  • Codex Desktop app: 26.429.61741 (CFBundleIdentifier = com.openai.codex)
  • Codex CLI: codex-cli 0.128.0-alpha.1
  • macOS: 26.4.1 (25E253)
  • EventKit CLIs:
  • rem-cli 0.10.2
  • ical 0.9.0
  • Codex.app path: /Applications/Codex.app

Reproduction

  1. Install EventKit-based Calendar/Reminders CLIs:

``sh
brew tap BRO3886/tap
brew install rem-cli ical
``

  1. From iTerm, run the tools:

``sh
rem lists
ical today
``

macOS prompts for Reminders/Calendar access and the tools can be authorized.

  1. From Codex Desktop's app terminal/tool context, run:

``sh
rem lists
ical today
``

Actual behavior

rem lists fails immediately:

Error: failed to initialize Reminders access: reminders: access denied: reminders access denied

ical today fails immediately:

Calendar access denied. Grant access in System Settings > Privacy & Security > Calendars

No macOS permission prompt appears for Codex.

Resetting Codex's TCC entries does not change the behavior:

tccutil reset Reminders com.openai.codex
tccutil reset Calendar com.openai.codex

Running with broader Codex filesystem sandbox permissions also does not change the behavior, so this does not appear to be the Codex workspace/filesystem sandbox.

Expected behavior

When an EventKit-based child process launched by Codex requests Calendar or Reminders access, macOS should either:

  • show a TCC prompt for Codex so the user can grant access, or
  • allow Codex Desktop to declare/support the required Calendar/Reminders usage descriptions so EventKit tools can be authorized like they can under Terminal/iTerm.

Local app metadata

/Applications/Codex.app/Contents/Info.plist contains usage descriptions for Apple Events, audio, camera, and microphone, but does not appear to contain Calendar/Reminders usage descriptions:

NSCalendarsUsageDescription: not present
NSRemindersUsageDescription: not present
NSCalendarsFullAccessUsageDescription: not present
NSRemindersFullAccessUsageDescription: not present

codesign -d --entitlements - /Applications/Codex.app shows:

com.apple.security.app-sandbox = false
com.apple.security.automation.apple-events = true
com.apple.security.cs.allow-jit = true
com.apple.security.cs.allow-unsigned-executable-memory = true
com.apple.security.device.audio-input = true
com.apple.security.files.user-selected.read-write = true
com.apple.security.network.client = true

Notes

This seems related in class to other macOS TCC/entitlement issues, but I could not find an existing Calendar/Reminders/EventKit-specific issue in openai/codex.

View original on GitHub ↗

3 Comments

jonnyel · 3 months ago

I can confirm this is the same root issue with remi in Codex Desktop on macOS.

Environment:

  • Codex Desktop: 26.519.31651
  • macOS: 26.5
  • remi: 0.2.0 via Homebrew

Behavior:

  • In iTerm2, remi list <REMINDERS_LIST_NAME> works correctly.
  • In the Codex built-in terminal, remi list <REMINDERS_LIST_NAME> fails with Error: items.find is not a function.

Additional detail:

  • remi authorize opened System Settings and I granted Codex Full Disk Access.
  • After restarting Codex, Reminders access was still denied.
  • It opened Privacy & Security > Reminders, but Codex did not appear in the app list and could not be added manually.

remi doctor --sync in Codex reports that database access is granted, but Reminders access is not granted and 0 lists are returned.

So this appears to be the same Codex-side Reminders TCC / missing usage-description problem described in this issue, with remi surfacing a bad downstream error instead of a clean permission-denied message.

alexeichhorn · 3 months ago

The fix should be very simple: Codex.app needs to declare Calendar and Reminders privacy usage descriptions in its Info.plist.

At minimum:
NSCalendarsUsageDescription
NSRemindersUsageDescription

And ideally also the newer full-access EventKit keys:
NSCalendarsFullAccessUsageDescription
NSRemindersFullAccessUsageDescription

---

Maybe at some point Codex could even have native skills for such access points (like calendar, reminders, etc)

ppeirce · 2 months ago

I can reproduce this on a newer Codex Desktop build.

Environment:

  • Codex.app: 26.609.41114, CFBundleVersion = 3888
  • Bundle id: com.openai.codex
  • macOS: 15.7.4 (24G517), Darwin 24.6.0 arm64 arm
  • Tools tested:
  • rem at /Users/peter/.local/bin/rem
  • remindctl 0.1.1 at /Users/peter/.local/bin/remindctl

Behavior:

  • rem works from iTerm after granting Reminders permission there.
  • From Codex Desktop's command runner, REM_NO_UPDATE_CHECK=1 NO_COLOR=1 rem lists --count fails immediately with:
Error: failed to initialize Reminders access: reminders: access denied: reminders access denied
  • remindctl status initially reported Not determined, but remindctl authorize did not produce a usable system prompt from Codex Desktop and moved to Denied.
  • tccutil reset Reminders com.openai.codex succeeds, but rerunning the command still fails with no macOS prompt.

Local bundle metadata:

  • /Applications/Codex.app/Contents/Info.plist contains usage strings for Apple Events, audio capture, camera, and microphone.
  • It does not contain NSRemindersUsageDescription, NSRemindersFullAccessUsageDescription, NSCalendarsUsageDescription, or NSCalendarsFullAccessUsageDescription.

TCC log evidence after running rem from Codex Desktop:

AUTHREQ_SUBJECT: msgID=638.2308, subject=com.openai.codex,
-[TCCDAccessIdentity staticCode]: static code for: identifier com.openai.codex, type: 0: 0x880315500 at /Applications/Codex.app
AUTHREQ_PROMPTING: msgID=638.2308, service=kTCCServiceReminders, subject=Sub:{com.openai.codex}Resp:{TCCDProcess: identifier=com.openai.codex, pid=73497, auid=501, euid=501, responsible_path=/Applications/Codex.app/Contents/MacOS/Codex, binary_path=/Applications/Codex.app/Contents/MacOS/Codex},
found auth specifc usage key: NSRemindersFullAccessUsageDescription for desired auth: 2
Refusing authorization request for service kTCCServiceReminders and subject Sub:{com.openai.codex}Resp:{TCCDProcess: identifier=com.openai.codex, pid=73497, auid=501, euid=501, responsible_path=/Applications/Codex.app/Contents/MacOS/Codex, binary_path=/Applications/Codex.app/Contents/MacOS/Codex} without NSRemindersUsageDescription key

This confirms the access request is being attributed to Codex.app as the responsible process, and macOS refuses before displaying a consent prompt because the responsible app bundle does not declare the Reminders usage description.