Skip to content

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

Open
Open
Codex Desktop on macOS cannot trigger Calendar/Reminders TCC prompts for EventKit CLIs#21228
Labels
appIssues related to the Codex desktop appbugSomething isn't working

Description

@wadjj
wadjj
opened on May 5, 2026

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:

    brew tap BRO3886/tap
brew install rem-cli ical

  2. From iTerm, run the tools:

    rem lists
ical today

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

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

    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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    on May 5, 2026

  2. jonnyel commented on May 22, 2026

    @jonnyel
    jonnyel
    on May 22, 2026

    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.

  3. alexeichhorn commented on May 23, 2026

    @alexeichhorn
    alexeichhorn
    on May 23, 2026

    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)

  4. ppeirce commented on Jun 13, 2026

    @ppeirce
    ppeirce
    on Jun 13, 2026

    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.

  5. GURULifeline commented on Aug 31, 2026

    @GURULifeline
    GURULifeline
    on Aug 31, 2026

    Additional reproduction from Codex Desktop on macOS 26.5.2:

    An EventKit-based Swift calendar reconciliation command was launched by the agent under the managed workspace-write execution context. The executable immediately returned:

    Fatal error: Calendar access was not granted.

    The user had already enabled all visible Calendar privacy settings, and this workflow had worked previously. The agent initially interpreted the EventKit result as a TCC grant/signing problem and directed the user to Privacy & Security settings.

    The same executable, with identical arguments and input, was then retried through exec_command using sandbox_permissions: "require_escalated". It succeeded with exit code 0 and completed the Calendar updates. No privacy setting, binary, input, or command argument changed between the failed and successful attempts.

    This suggests a second failure mode alongside the missing usage-description/TCC-prompt problem in the original report: managed sandbox execution can cause EventKit to surface an ordinary-looking Calendar authorization denial, even when the user's TCC grant is correct and an explicitly escalated execution succeeds.

    Requested improvements:

    1. Preserve or request the appropriate execution context for macOS protected-resource workflows such as EventKit.
    2. Distinguish a sandbox-caused denial from a genuine TCC denial where possible.
    3. Teach the agent/runtime to retry via the approval/escalation flow before recommending that users change or reset macOS privacy settings.
    4. Add a regression test covering: same EventKit command under managed workspace execution fails, explicit escalation succeeds, and no misleading privacy-reset guidance is produced.

    Local usernames, paths, calendar identifiers, and event contents are intentionally omitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions