/manifest

description: Generate the add-in manifest XML with your cloud config baked in

Generate add-in manifest

The script fetches the canonical manifest and appends your config as URL query parameters. The add-in reads them at startup. Outlook uses a separate template because Microsoft's `MailApp` schema is distinct from the `TaskPaneApp` schema Excel/Word/PowerPoint share, so ask which apps they're deploying and generate one file per host.

| Host arg | Apps | Template | |---|---|---| | `office` | Excel, Word, PowerPoint | `pivot.claude.ai/manifest.xml` | | `outlook` | Outlook (mail + calendar) | `pivot.claude.ai/manifest-outlook-3p.xml` |

Keys by cloud

Prompt only for the keys their cloud path needs. Don't ask for all eight.

| Cloud | Keys | |---|---| | Vertex | `gcp_project_id` `gcp_region` `google_client_id` `google_client_secret` | | Bedrock | `aws_role_arn` `aws_region` | | Foundry | `azure_resource_name` `azure_api_key` | | Gateway | `gateway_url` `gateway_token` `gateway_auth_header` `gateway_api_format` | | Gateway (`gateway_api_format=vertex`) | also `gcp_project_id` `gcp_region` |

Amazon Bedrock is **not currently supported for the `outlook` host**; the script exits with an error if you pass `aws_*` keys with `outlook`.

Outlook — Microsoft Graph

Outlook reads the user's mailbox and calendar via Microsoft Graph, which requires a one-time tenant-wide admin consent regardless of which cloud serves the model. Run [consent](consent.md#outlook--microsoft-graph-consent) before deploying — otherwise every user hits "Need admin approval" on first open.

If their policy forbids consenting to a third-party app, prompt for `graph_client_id` (their own single-tenant Entra app's client ID with Mail.ReadWrite, Calendars.Read, People.Read, User.Read, offline_access delegated permissions and admin consent granted). Otherwise leave it unset and the add-in uses Anthropic's multi-tenant app.

Sovereign / national clouds (GCC-High, DoD, 21Vianet)

The add-in auto-detects the tenant's national cloud at sign-in (from the authority host Office reports) and resolves the matching Graph + Entra endpoints, so most sovereign tenants need **no cloud config**. The only required step is bringing your own Entra app via `graph_client_id` — Anthropic's multi-tenant app exists only in the commercial cloud; see [entra-app](entra-app.md#gcc-high--dod--21vianet) for the registration steps in the Azure Government / 21Vianet portals. A GCC-High Outlook manifest needs nothing beyond the usual keys:

node "${CLAUDE_PLUGIN_ROOT}/scripts/build-manifest.mjs" outlook manifest-outlook.xml \
  <provider keys> entra_sso=1 graph_client_id=<your-app-guid>

When to set `graph_cloud`

The cloud is configured as a single enum value — never a URL. Each value maps to the fixed Graph + Entra endpoint pair from Microsoft's [national-cloud deployments](https://learn.microsoft.com/graph/deployments) inside the add-in.

| Tenant | `graph_cloud` | Notes | |---|---|---| | Commercial or GCC | `global` | default; may be omitted | | GCC High | `us-gov-high` | auto-detected; set explicitly to pin it in the reviewed manifest | | US Gov DoD | `us-gov-dod` | **always required** — DoD shares an authority host with GCC High, so auto-detect picks GCC High | | China (21Vianet) | `china` | auto-detected; set explicitly to pin it |

A DoD Outlook manifest:

node "${CLAUDE_PLUGIN_ROOT}/scripts/build-manifest.mjs" outlook manifest-outlook.xml \
  <provider keys> entra_sso=1 graph_client_id=<your-app-guid> graph_cloud=us-gov-dod

The build script enforces the same rules the add-in does at load: an unrecognized value is a hard error, and any non-global `graph_cloud` requires `graph_client_id` (without one, sign-in fails with an opaque AADSTS700016).

`graph_cloud` also governs the Entra SSO authority for Word/Excel/PowerPoint — they share the auth path — so include it in the `office` manifest too if you set it.

**Bedrock / WIF note:** a `.us`-issued idToken has issuer `https://login.microsoftonline.us/{tenant}/v2.0` — your AWS OIDC identity provider must be configured with that issuer, not the `.com` one.

Entra SSO

`entra_sso=1` makes the add-in acquire an Entra ID token at startup. Set it when your deployment needs the user's Microsoft identity — Bedrock uses it as the STS web identity, the bootstrap endpoint uses it as Bearer auth, and per-user attrs ([update-user-attrs](update-user-attrs.md)) ride inside it as `extn.*` claims.

**Admin consent is a prerequisite.** Without it, every user hits a Microsoft consent dialog on first open. Run [consent](consent.md) first so `entra_sso=1` is silent for your users.

If you don't need Entra — static gateway config, Vertex with Google OAuth — leave it off. Users won't see a Microsoft prompt for a setup that doesn't involve Microsoft.

**Bring your own Entra app.** By default the token is requested as Anthropic's multi-tenant app (`c2995f31-…`), so its `aud` claim is that GUID. If your bootstrap endpoint or token-exchange service requires `aud` to match an app registered in *your* tenant, set `graph_client_id=<your-app-guid>`. See [entra-app](entra-app.md) for the registration steps (redirect URIs, API setup, admin consent). [consent](consent.md) covers Anthropic's default app only.

**Send an access token instead of the ID token.** With `graph_client_id` alone the add-in still sends an *ID token* to your bootstrap endpoint — `aud` is your app's GUID, but there's no `scp` claim. If your endpoint is a standard OAuth2 protected resource that validates `aud` + `scp`, or an RFC 8693 token-exchange service, set `entra_scope=api://<your-app-guid>/<scope>` and the add-in requests an *access token* for that scope instead. The Bearer it sends carries `aud` = your API's App ID URI and `scp` = the granted scope. In Entra, on your app registration: **Expose an API** (Application ID URI `api://<guid>`), add a scope such as `access_as_user`, and grant the same app delegated pe