---
{
  "id": "platform.calendar.permissions-sync-and-safety",
  "topic": "calendar",
  "title": "Calendar permissions, device sync, and safety",
  "locale": "en",
  "version": "2026-08-12",
  "summary": "Calendar access is the intersection of Agent grants and user visibility, with explicit multi-calendar selection and read-only mirror safeguards.",
  "content": "An Agent can access only the intersection of calendars granted to that Agent and calendars visible to the triggering user as owner or member. A read grant cannot mutate. Unauthorized and nonexistent calendars or events both return `resource_not_found`, so never disclose whether an ungranted resource exists. If there are no writable calendars, create returns `permission_denied`. If there are several, omitting `calendarId` returns an ambiguous error with `details.code = CALENDAR_ID_REQUIRED` and candidate `calendarIds`; retry with one of them. Default-calendar ordering does not choose silently.\n\nCalendars with origin `device_mirror` are read-only throughout Arinova. A write returns `permission_denied` with an iPhone read-only explanation. Changes to native calendars schedule a sync push to paired iOS devices, but no delivery time is promised. `kanban-*` virtual events come from boards visible to the triggering user, not Calendar grants. They cannot be fetched, updated, or deleted; those calls return `details.code = VIRTUAL_EVENT_READONLY`.\n\n`delete_event` requires UserConfirm and performs a soft delete; list/get stop returning the event, but do not promise restoration. `conversationId` must identify a conversation the triggering user can access; update null clears it and omission preserves it. The same access check applies to single-event and recurring-event writes. The current Trigger action schema does not expose Calendar as a source, even though internal services support it, so do not propose `create_trigger` for Calendar events. Registry, redaction, audit, confirmation, and public-surface policy remain authoritative.\n",
  "aliases": [
    "calendar permission",
    "calendarId required",
    "iPhone calendar read-only",
    "device mirror",
    "kanban virtual event",
    "calendar sync",
    "resource not found"
  ],
  "tags": [
    "calendar",
    "permissions",
    "safety"
  ],
  "relatedActions": [
    "arinova.calendar.list_events",
    "arinova.calendar.get_event",
    "arinova.calendar.create_event",
    "arinova.calendar.update_event",
    "arinova.calendar.delete_event"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/en/kb/calendar/permissions-sync-and-safety/"
}
---

An Agent can access only the intersection of calendars granted to that Agent and calendars visible to the triggering user as owner or member. A read grant cannot mutate. Unauthorized and nonexistent calendars or events both return `resource_not_found`, so never disclose whether an ungranted resource exists. If there are no writable calendars, create returns `permission_denied`. If there are several, omitting `calendarId` returns an ambiguous error with `details.code = CALENDAR_ID_REQUIRED` and candidate `calendarIds`; retry with one of them. Default-calendar ordering does not choose silently.

Calendars with origin `device_mirror` are read-only throughout Arinova. A write returns `permission_denied` with an iPhone read-only explanation. Changes to native calendars schedule a sync push to paired iOS devices, but no delivery time is promised. `kanban-*` virtual events come from boards visible to the triggering user, not Calendar grants. They cannot be fetched, updated, or deleted; those calls return `details.code = VIRTUAL_EVENT_READONLY`.

`delete_event` requires UserConfirm and performs a soft delete; list/get stop returning the event, but do not promise restoration. `conversationId` must identify a conversation the triggering user can access; update null clears it and omission preserves it. The same access check applies to single-event and recurring-event writes. The current Trigger action schema does not expose Calendar as a source, even though internal services support it, so do not propose `create_trigger` for Calendar events. Registry, redaction, audit, confirmation, and public-surface policy remain authoritative.