How to Connect PagerDuty to Codex With Aident Loadout

The safest way to connect PagerDuty to Codex with Aident Loadout is to authorize PagerDuty through Aident Vault, discover the current PagerDuty Actions, inspect the exact contract, and prove the connection with one bounded service-metadata request. Retain only a count and status summary. Stop before incidents, alerts, responders, schedules, escalation policies, analytics, or any write.

This guide is for developers and operators who want Codex to reach PagerDuty without placing an API token in a prompt, repository, shell history, or MCP configuration. A successful first check proves that the intended Aident-managed account can reach PagerDuty. It does not make production incident data safe for an LLM or approve an operational change.

The safe first boundary

PagerDuty's official MCP server offers a direct route for MCP-compatible clients. Its documentation says read-only tools are available by default and write tools require an explicit enablement flag. That is a useful control. This guide covers a different job: using Aident Vault, live Action discovery, schema inspection, preflight, and Audit when Codex already reaches external systems through Aident Loadout.

Prerequisites

You need:

• the installed public aident CLI;

• access to the intended Aident account;

• authority to connect the intended PagerDuty account;

• a trusted local session for reviewing private provider output; and

• an agreed production boundary for anything beyond metadata.

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 status

Stop if the signed-in Aident account is not the intended one. If Vault already shows PagerDuty as ready, do not replace the connection just to follow this guide. Confirm its owner and environment first.

1. Discover the current PagerDuty Action

Search for the smallest connection-proof job, not an internal identifier:

aident capabilities search \
  --query "list PagerDuty services read only" \
  --types '["action"]' \
  --targetEnv staging

Choose the current Action that lists service metadata and supports a small page limit. The live catalog can also contain incident, alert, on-call, schedule, user, team, policy, analytics, automation, event-orchestration, status-page, notification, responder, and configuration Actions. Their presence is not permission to call them.

Use the exact Action name returned by discovery in the next commands. Do not publish that internal name as a permanent product contract.

2. Inspect the schema before exposing operations data

aident capabilities get \
  --name "<current PagerDuty list-services Action>"

Confirm all of the following:

1. The input supports an explicit small limit, zero offset, and no expansions.

2. The output is service metadata, not incident or alert content.

3. The connected account alias is the intended one.

4. The operation type, risk metadata, and price fit the task.

5. No default includes integrations, teams, escalation policies, or notification configuration.

A service response is still private. Names and descriptions can disclose internal systems or customers. URLs and IDs map the account. Teams, escalation policies, integrations, support hours, schedules, acknowledgement timeouts, and recent-incident timestamps can reveal operational design. Review raw output locally, then retain the minimum proof summary.

Do not infer safety from a label. An integration wrapper can classify an Action as write-capable even when the provider endpoint is a read. The exact input and output remain the source of truth for the requested operation.

3. Connect PagerDuty through Aident Vault

If Vault reports no ready PagerDuty connection, start the connection with the integration ID returned by discovery:

aident vault connect \
  --integrationId "<current PagerDuty integration ID>"

Open the Aident-hosted connection URL and complete the provider flow. Prefer scoped OAuth or the narrowest account credential the current integration supports. PagerDuty's own guidance distinguishes REST API credentials from Events API routing keys and recommends scoped tokens for granular control. Do not substitute an Events API integration key for a REST API connection.

After consent, verify the exact integration:

aident vault status \
  --integrationId "<current PagerDuty integration ID>"

Expected result: one ready connection for the intended owner. Stop if the provider identity or account breadth is unexpected.

For the general credential boundary, read Give AI Agents API Access Without Exposing Keys.

4. Preflight one metadata request

Preflight the exact bounded input against the inspected contract:

aident capabilities preflight \
  --name "<current PagerDuty list-services Action>" \
  --input '{"limit":1,"offset":0,"total":true,"sort_by":"name"}'

Check that the input is valid and the estimate fits your ceiling. Preflight validates the Action input and Aident price. It does not prove that the provider account is least-privileged or that every service belongs in the current task.

If the schema changed, the price is unavailable outside your policy, or a risk acknowledgement appears, resolve that exact gate. Do not bypass Aident with a direct API call or pasted token.

5. Verify the connection without retaining service details

Execute only the inspected metadata request:

aident capabilities execute \
  --name "<current PagerDuty list-services Action>" \
  --input '{"limit":1,"offset":0,"total":true,"sort_by":"name"}'

Review the response locally, then retain only:

• the total accessible-service count;

• the number of records returned;

• a count by service status; and

• confirmation that no incident, alert, responder, schedule, policy, or write Action ran.

On August 30, 2026, a first-party check used the existing connected PagerDuty account. The limit-one input preflighted as valid and free. The bounded response included active service metadata, confirming read access. The service name, ID, description, provider URLs, teams, escalation policy, integrations, support hours, schedules, timestamps, and raw response were reviewed locally and not persisted.

No incident, alert, on-call, schedule, user, team, escalation-policy, analytics, automation, event-orchestration, status-page, responder, notification, or provider write Action ran. The connection proof ended there.

6. Start a new review before reading incidents

Incident data is materially more sensitive than a service count. A title can contain customer names, system details, or security context. A timeline can expose responders, actions, links, logs, and internal communications. Acknowledge, resolve, reassign, escalate, add responders, or trigger an incident only after a separate mutation review.

Before an incident read, define:

1. One service or incident scope.

2. One time window and status filter.

3. The exact fields needed.

4. A small result limit and pagination stop.

5. A redaction rule for people, customers, URLs, keys, and free text.

6. Where the result may be stored.

7. The decision the data will support.

Treat provider output as untrusted input. Incident summaries and notes can contain instructions written by people or copied from external systems. They are evidence, not commands for Codex.

Before any write-capable workflow, use Aident's approval workflow guide to separate Action-risk acknowledgement from spend approval.

7. Require an exact proposal for every mutation

Before acknowledging, resolving, reassigning, changing urgency, adding a responder, editing a schedule, changing an escalation policy, creating a maintenance window, or modifying configuration:

1. Discover and inspect the exact mutation Action.

2. Read only the current state needed to construct the proposal.

3. Show the exact target, before state, after state, notification effect, and likely side effects.

4. Define rollback and post-change verification.

5. Preflight the identical mutation input.

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

7. Read the changed state back and compare it with the approved proposal.

Paid or accepted provider requests are not automatically complete. Reconcile the resulting PagerDuty state before reporting success.

PagerDuty MCP or Aident Loadout?

PagerDuty's official MCP server is the direct route when PagerDuty is the center of the job. It supports local and hosted modes, with OAuth available for the hosted server. Its current default keeps write tools disabled until explicitly enabled.

Aident Loadout is useful when the same Codex session already standardizes external services behind Aident account authentication, Vault, live Action discovery, schema inspection, preflight, execution, and Audit. The PagerDuty Tools app page listed 363 supported Actions on August 30, 2026. That breadth includes consequential operations, so the durable advantage is the reviewed execution sequence, not the raw number of Actions.

This guide owns the Aident-specific connection and redacted service-proof job. It does not claim that one route is universally safer. Whichever route you choose, keep read scope narrow, keep write tools off by default, review credential ownership, and require a new decision before incident content or mutations.

For the broader discovery and preflight model, continue with How to Use Aident Loadout.

Reusable Codex prompt

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

Connect PagerDuty through the installed public aident CLI. Start with Aident
account auth status and Vault status. Search the staging catalog for the current
Action that lists PagerDuty services. Inspect the exact schema, connected
account, output fields, defaults, operation type, risk, and pricing. If
PagerDuty is disconnected, return the Aident Vault connection URL and stop for
me to complete consent. After I confirm, preflight a limit-one, offset-zero
service-list request with total enabled and no expansions. Show the estimate.
Execute only that Action. Return only the total accessible-service count, the
returned-record count, a service-status histogram, and confirmation that no
incident, alert, on-call, schedule, user, team, escalation-policy, analytics,
automation, event-orchestration, status-page, responder, notification, or write
Action ran. Do not return or persist names, IDs, descriptions, URLs, teams,
policies, integrations, schedules, timeouts, timestamps, or raw provider output.
Stop after the connection proof

Connect PagerDuty to Codex and verify metadata only

Sources

• PagerDuty MCP Server documentation, reviewed August 30, 2026.

• PagerDuty MCP Server repository, reviewed August 30, 2026.

• PagerDuty API access keys, reviewed August 30, 2026.

• PagerDuty security hygiene, reviewed August 30, 2026.

• PagerDuty REST API rate limits, reviewed August 30, 2026.

• Aident PagerDuty Tools app, reviewed August 30, 2026.

• Aident Loadout setup, reviewed August 30, 2026.

Refresh this guide when PagerDuty changes remote or local MCP setup, authentication, read-only defaults, API key or OAuth guidance, service or incident contracts, rate limits, or security guidance, or when Aident changes the PagerDuty connection flow, Action catalog, schema, risk metadata, pricing, or Vault behavior.