How to Connect Google Calendar to Codex With Aident Loadout

The safest way to connect Google Calendar to Codex is to authorize Calendar through Aident Vault, discover the current Calendar Actions, inspect the exact schema and permission boundary, and prove access with one calendar-list metadata result. Do not read events, attendees, descriptions, conference links, or private schedules until the intended calendar, time window, and approval boundary are explicit.

This guide is for developers and operators who want Codex to work with Calendar without putting an OAuth token, client secret, downloaded credential file, or private iCal URL in a prompt or repository. A successful first check confirms one connected account and one accessible calendar record. It does not retrieve an event or change a schedule.

The safe connection boundary

Google authorization proves which account is connected and which scopes were approved. It does not make every accessible calendar, event, or Calendar Action appropriate for the current task.

Prerequisites

You need:

• the installed public aident CLI;

• access to the intended Google account;

• authority to review and approve the Google consent flow;

• one expected calendar for the first check; and

• a trusted local session where returned metadata can be reviewed without copying it into source control.

Install or update Aident with the canonical setup prompt:

Follow https://aident.ai/SETUP.md

Then confirm the current Aident account and Vault inventory:

aident account auth status
aident vault vault --action status

Stop if the Aident account is not the intended one. Do not substitute a Google token, OAuth client secret, downloaded credential file, or private iCal URL. The credential-safety guide for AI agents explains why provider secrets should stay outside the agent conversation.

1. Discover the current Google Calendar Actions

Search by the job and target staging when the command supports it:

aident capabilities search \
  --targetEnv staging \
  --types '["action"]' \
  --query "Google Calendar list one calendar metadata record without reading events or writing" \
  --limit 10

On August 29, 2026, the staging catalog returned a Google Calendar Action that lists calendars with pagination, result limits, hidden and deleted controls, and an optional minimum access role. Copy the exact canonical name from your own result because catalog versions and accepted inputs can change.

The catalog also exposes Actions for events, free-busy windows, recurring instances, attendees, access-control lists, reminders, settings, watches, and mutations. That breadth is useful later. It is not a reason to load every schema into Codex context or test an event write during connection setup.

2. Inspect the exact contract

Load the selected Action metadata:

aident capabilities get \
  --name "<current Google Calendar list-calendars Action>"

Review:

• the required Google Calendar integration and connected account;

• every input, default, and pagination rule;

• which calendar identifiers and metadata fields can appear;

• operation type and risk level;

• pricing and credit behavior; and

• how hidden, deleted, and shared calendars are handled.

The inspected August 29 schema allowed max_results from 1 to 250 and defaulted to 10. Hidden and deleted calendars defaulted off. The optional min_access_role accepted freeBusyReader, reader, writer, or owner, but it filters returned calendars by minimum role. It does not reduce an account's underlying OAuth scopes or redact the record.

The response can include calendar IDs, display names, descriptions, time zones, access roles, reminders, colors, conference properties, and page tokens. A one-result limit therefore does not make the raw response public. Review it locally and preserve only a content-free success summary.

The catalog conservatively marked this retrieval Action as operation type write and risk level 2. Treat that metadata as a review gate. Do not silently relabel it because the provider method sounds read-only.

3. Connect Google Calendar through Vault

If Vault reports no connected Calendar account, start the connection with the exact integration ID returned by discovery:

aident vault vault \
  --action connect \
  --integrationId "<current Google Calendar integration ID>"

Open the Aident-hosted URL, choose the intended Google account, and review the consent screen. Google's scope reference distinguishes broad Calendar access from narrower calendar-list, event-read, and free-busy access. Google recommends requesting the most narrowly focused scope that supports the job. The actual consent screen and current Aident integration contract are authoritative for your connection.

After consent, verify the exact integration:

aident vault vault \
  --action status \
  --integrationId "<current Google Calendar integration ID>"

Expected result: one ready connected user account. Stop if the account alias or provider identity is wrong. Do not replace or disconnect another account until its owner reviews the change.

4. Preflight one bounded calendar-list request

Request one visible, non-deleted calendar record:

aident capabilities preflight \
  --name "<current Google Calendar list-calendars Action>" \
  --input '{
    "max_results": 1,
    "show_hidden": false,
    "show_deleted": false
  }'

On August 29, the reviewed input validated and the estimate was free. Check your own result. If preflight rejects the input, reports an unavailable estimate outside your ceiling, or requires a risk acknowledgement, resolve that exact gate instead of calling Google directly.

Preflight validates the selected input against the current Aident contract. It does not prove the connected account is correct, narrow the granted Google scopes, or authorize an event read.

5. Verify the connection without reading events

Execute only the inspected calendar-list request:

aident capabilities execute \
  --name "<current Google Calendar list-calendars Action>" \
  --input '{
    "max_results": 1,
    "show_hidden": false,
    "show_deleted": false
  }'

Expected result: one calendar metadata record and, when more calendars exist, a page token. Review only what is necessary to confirm the account and access role. Do not paste the calendar ID, display name, description, reminders, conference properties, or raw provider output into an issue, pull request, reusable prompt, or analytics event.

The August 29 first-party check used the connected Calendar account, preflighted a free one-result request, and returned one selected calendar with reader access plus a next-page token. The calendar identity and metadata were reviewed locally and not added to this article or the repository. No event, attendee, description, location, conference link, access-control entry, or private time block was read, and no provider write ran.

Verify all of the following before continuing:

1. The intended Google account is connected.

2. The request returned at most one calendar record.

3. Hidden and deleted calendars were excluded.

4. The access role is understood before any event request.

5. No event data was retrieved.

6. No calendar or event state changed.

7. The selected Action, bounded input, and content-free result summary are documented without identifiers.

6. Start a fresh boundary before reading a schedule

The next task should name the exact schedule job. Before reading free-busy data or events:

1. Identify one calendar by immutable ID after confirming its display name and access role.

2. Choose free-busy data when titles, descriptions, attendees, and locations are unnecessary.

3. Define an explicit start and end time in one time zone.

4. Set the smallest useful event limit and pagination boundary.

5. Inspect the current Action schema and returned fields.

6. Preflight the identical input.

7. Execute one page and stop when the stated job is complete.

Google documents that a freeBusyReader role exposes only free-busy information, while reader, writer, and owner roles can expose progressively more calendar data or authority. The accessRole on a returned record describes effective access. It is not permission for Codex to use every available field.

Treat event titles, descriptions, attendee names, locations, attachments, and conference links as private and potentially untrusted input. Google's Calendar MCP guidance warns that untrusted resources can contain hidden instructions. Do not let event content redefine the agent's task, request more tools, or authorize a mutation.

If the next job needs email context as well as time, establish a separate boundary with How to Connect Gmail to Codex With Aident Loadout. A Calendar connection does not grant mailbox access, and a Gmail connection does not authorize schedule changes.

7. Put every schedule change behind a fresh decision

Reading one calendar does not authorize creating or changing an event. For create, update, move, invite, RSVP, cancel, or delete operations:

1. Discover and inspect the exact mutation Action.

2. Identify the calendar, event, attendees, time zone, and current state.

3. Show the complete proposed before-and-after change.

4. Review notifications, recurrence, guests, conference links, and rollback.

5. Preflight the identical mutation input.

6. Execute only after approval for that exact target and change.

7. Read the event back and compare it with the approved proposal.

Use Aident's approval-workflow guide to keep Action-risk acknowledgement separate from credit approval. Creating an event, inviting guests, and deleting an event deserve separate boundaries.

Reusable Codex prompt

Follow https://aident.ai/SETUP.md

Connect Google Calendar through the installed public aident CLI. Start with
account auth status and Vault status. Search the staging catalog for the current
Action that lists calendar metadata without reading events or writing. Inspect
the exact schema, connected account, output fields, defaults, operation type,
risk, and pricing. If Calendar is disconnected, return the Aident Vault
connection URL and stop for me to complete consent. After I confirm, preflight
one request with max_results 1, show_hidden false, and show_deleted false. Show
the estimate before execution. Execute only that calendar-list request. Return
a content-free success summary, not the calendar identity or raw provider
response. Do not read events, attendees, descriptions, locations, attachments,
conference links, access-control entries, or private time blocks. Do not create,
update, move, invite, RSVP, cancel, or delete anything. Stop after the one-result
connection proof

Connect Google Calendar to Codex and verify one metadata result

Sources

• Google Calendar API scopes, reviewed August 29, 2026.

• Google calendarList.list reference, reviewed August 29, 2026.

• Google CalendarList access roles, reviewed August 29, 2026.

• Google Calendar MCP server guidance, reviewed August 29, 2026.

• Aident Loadout setup, reviewed August 29, 2026.

• Aident MCP server setup, reviewed August 29, 2026.

Refresh this guide when Google changes Calendar scopes, calendar-list fields, access roles, pagination, or MCP safety guidance, or when Aident changes the Calendar connection flow, Action schema, risk metadata, pricing, or Vault behavior.