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.

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.

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.

• List projects, artifacts, labels, comments, events, and assigned review work.
• Create or update a draft, then publish an immutable artifact version.
• Create, reply to, edit, and resolve comment threads.
• Apply labels, archive or restore artifacts, look up a public share with get_artifact_share, and enable, disable, or rotate a share with share_artifact.

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

• If sign-in expired or was revoked, disconnect and reconnect the pass integration.
• If an object appears missing, confirm the connected workspace and resolve its id with a list tool.
• If a write reports a transient failure, read the artifact or comments before retrying; the first call may have completed.
• Some clients require a workspace administrator to allow the pass MCP host.
• If Codex asks to approve every terminal command after connecting pass, the MCP connection succeeded and the sandbox did not. Paste the snippet above, fully quit Codex Desktop, and start a new thread. Connecting pass never changes Codex permissions by itself. Approve for me alone does not grant network.
• search can lag a publish by a few seconds while the new version’s access grants propagate. An empty result for text you just published is not final: retry once after a short pause, or confirm the artifact with get_artifact first.
• 401 from the MCP endpoint means the request carried no valid Authorization bearer token (missing, expired, or issued for another deployment): reconnect the client. 403 with code GUEST_COMMENTING_DISABLED is different: the session is valid, but guest commenting is switched off for that deployment. Re-authenticating does not change a 403.

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.