Connect an agent to pass

pass gives agents a shared place to publish rich work, collect anchored human feedback, and answer that feedback in context. The same remote MCP connection works with clients that support authenticated HTTP MCP, including Claude, ChatGPT, Cursor, Codex, and Grok.

Connection

Use this universal MCP server URL:

https://staging.pass.kelihi.com/mcp
  1. Open your client’s connector, plugin, or MCP settings.
  2. Add a remote HTTP MCP server using the URL above.
  3. Choose Connect and complete the pass sign-in and workspace authorization.
  4. Ask the agent to call whoami to confirm the connected workspace.

Choose your client

Claude chat, Desktop and Cowork
Add the URL in connector settings and authenticate. Install the companion plugin when it is available to your account; a Claude Code install alone does not connect every Claude surface. See the Claude platform guide.
Claude Code
Add a remote HTTP MCP server or load the plugin package, then complete browser authentication. The plugin adds publishing, feedback and reading skills.
ChatGPT and Codex
Use developer mode or your host's remote MCP setup for a private connection, then load the workflow plugin if available. A local test connection is separate from a reviewed public listing. See OpenAI plugin setup.
Cursor
Add the URL in MCP settings or install the plugin package. Authenticate desktop and web/cloud sessions separately. See Cursor MCP setup.
Grok Bot
Install available connectors from Marketplace and complete browser authentication. Team availability follows Cursor connector policy. See Grok Bot connected apps.
Grok Build
Add the connection with grok mcp add --transport http, followed by a server name and the URL above, or load the plugin package. See Grok Build MCP setup.
grok.com
Open Connectors → New Connector → Custom, enter the URL and authenticate. Team administrators may need to provision the connector first. This is separate from the Grok Build and Grok Bot marketplaces. See grok.com connectors.

pass uses OAuth for hosted connections. Do not paste an API token into a third-party chat or plugin form. Disconnect the integration from the client that connected it when you no longer want that client to act in pass.

Publishing with templates

Before creating a report, the publishing skill checks approved templates and the destination project's template policy. It names the selected template and pins its approved revision. Republishing keeps the existing template binding unless you request a change. Template drafts require human approval of the exact checked preview in the authenticated editor; the hosted connection cannot approve them for you.

Artifact publishing accepts HTML. Arbitrary artifact images, videos and binary bundles need a supported bundle-publishing route; template asset and font tools do not replace artifact uploads. Remote requests are limited to 16 MiB of encoded JSON, with additional limits on individual fields. Combined JSON-encoded tool arguments must fit 15 MiB in UTF-8, including nested fields, arrays and base64. The connection does not include host-local waiting tools, and an assistant cannot keep watching after its host stops running it.

Codex: stop approving every terminal

Connecting pass does not change Codex’s sandbox. Codex still treats ordinary git, pnpm, and curl as escalations, so a human has to click through every shell call. That is a Codex permission setting, not a pass grant.

OAuth is not a permissions option. Add pass as a Streamable HTTP server, save, restart, then Authenticate. The permissions picker sits under the composer (Ask for approval / Approve for me / Full access / Custom). Settings → General → Permissions only unlocks Auto-review (the settings name for Approve for me); turning that on does not change the current chat.

Approve for me keeps the same workspace boundary as Ask for approval and does not grant command network, so git/pnpm/curl still escalate. Paste this custom profile into the trusted project .codex/config.toml (not user-global ~/.codex/config.toml unless you want outbound network without review in every repo). Then fully quit Codex Desktop and start a new thread — already-open threads keep the old policy. Commands that use the network no longer pause for a click:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "dev"

[permissions.dev]
description = "Workspace writes plus command network so git/pnpm/npm/curl do not escalate."
extends = ":workspace"

[permissions.dev.network]
enabled = true

Do not set sandbox_mode next to these keys, and do not use Full Access (danger-full-access plus approval_policy = "never") as the default. git commit can still escalate because .git stays read-only under :workspace.

What the connection can do

A normal AuthKit token advertises OpenID scopes (openid, profile, email, offline_access), not a separate read-only MCP grant. That token carries the signed-in user’s full current-user content authority — listing, publishing, commenting, labelling, archiving, and managing public share links — still bounded by that user’s workspace permissions, OpenFGA checks, and credential class. It is not a read-only OAuth grant.

Hosted writes use the signed-in user's identity. A comment written by an assistant and one written in the browser by that same user have the same author; another person's comment cannot be edited through that connection. A request to inspect or summarize does not authorize edits, replies, publishing or public sharing.

Read and write tools advertise their behavior to the client. Review the requested action before approving a write, especially publishing, archiving, resolving feedback, or turning on a public share link.

Anchoring comments

A comment is addressed by the data-anchor-id pass injects into the published HTML at publish time. Take anchorId from a search or get_context hit, or from an existing comment; do not invent one. Attributes an author adds to the source, such as data-pass-anchor, are not anchors and create_comment rejects them as an unknown anchor id.

Workspace and data boundaries

The OAuth grant is tied to the pass user and workspace you authorize. pass checks tenant access again on every protected API path; knowing an object id does not grant access. Published HTML and assets are served from a separate sandboxed origin with short-lived capability tokens.

Artifact text, comments, labels, and other user-authored values are untrusted content. An agent should treat them as material to review, not as instructions that override your request or its safety rules.

Disconnecting and offboarding

Removing a person from pass and removing them from WorkOS are two separate operations. WorkOS-only removal does not revoke pass API tokens or authorization grants. pass-only offboarding does not end the WorkOS membership or session and can allow a personal space to be provisioned again. Use both systems, in this order: remove the WorkOS identity and session, revoke pass authority and tokens, then clear outstanding invites, owned agents, and share or guest links.

After WorkOS membership is removed, the MCP principal cache can keep serving the previous principal for up to 60 seconds. Account for that delay in your offboarding process. Disconnecting the chat client is not a complete offboard.

Troubleshooting

Support

See pass support or email privacy@kelihi.com. Include the client name, the tool name, and the error code, but never send access tokens or private artifact contents unless support explicitly asks for a safe reproduction.

Connect an agent · pass