`ical` works in Codex with Full Access, but not with default permissions

[yvos]

Hi,

I tested ical from OpenAI Codex on macOS.

What works:

• ical works in the normal Terminal
• ical also works from Codex when Codex is given Full Access

What does not work:

• ical does not work from Codex with default permissions
• Example command:

ical upcoming

Output with default permissions:

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

So in my setup:

• Terminal: works
• Codex with Full Access: works
• Codex with default permissions: does not work

It would be great if ical could also work from Codex under default permissions, without requiring Full Access.

Small docs note:
In the skill docs I saw the Codex path listed as:

~/.agents/skills/

In my setup, user-level Codex skills are in:

~/.codex/skills/

[BRO3886]

will test this and let you know what's breaking and how we can fix

[BRO3886]

Thanks for the report, this helped me dig into what's actually going on.

So it's not just a TCC thing. Codex runs commands inside macOS Seatbelt (sandbox-exec) with a deny-all policy by default. What's happening is the sandbox is blocking the com.apple.CalendarAgent mach lookup, so EventKit can't even talk to the calendar store. It never gets far enough for TCC to matter. When you flip to Full Access, Codex just turns off the seatbelt entirely, so everything works because your terminal already has Calendar permission.

Codex's protocol has a permissions.macos.macos_calendar field that skills can declare in their metadata, and the skill loader does parse it. I've added this to the ical skill in #10. However, I wasn't able to verify that Codex actually applies skill-level macOS permissions to the seatbelt policy at runtime. When I tried setting macos_calendar=true via config overrides in codex exec, the sandbox broke entirely (exit -1 on all commands including date). It's possible this only works in interactive sessions where the approval overlay UI can prompt the user, or it might not be fully wired up in the CLI yet.

Either way, the metadata is correct per the Codex protocol spec and does no harm if Codex doesn't honor it yet. If it turns out Codex doesn't apply skill permissions to the seatbelt, that would be worth raising as a Codex issue.

Also adding ~/.codex/skills/ as a separate install target, good catch on that path.

Would you be able to test #10 on your Codex setup? Specifically in an interactive session (not codex exec) with default permissions. Testing instructions are on the PR.