Connect Cursor and Codex
Wire the ISMS Copilot account MCP into Cursor or Codex with the endpoint URL and a pat-isms Bearer header.
Cursor and Codex both speak MCP over HTTP. The endpoint and the credential are the same as for Claude Code; only the config file differs. They can also connect with sign-in where the client supports MCP OAuth; the setup documented here is the token. This page shows the config shapes and the checks that confirm the connection works.
1. Create a token
In chat.ismscopilot.com, open Settings → Connected apps → Create token. Grant the scopes you need, copy the pat-isms-… value once, and keep it out of committed files.
For the capability list and what each tool can do, see ISMS Copilot for agents. For scopes and token lifecycle, see Tokens and scopes.
2. Endpoint
https://account.ismscopilot.com/v1/account/mcpTransport: HTTP MCP.
Auth: Authorization: Bearer pat-isms-…
3. Cursor config
Cursor reads MCP servers from an mcp.json file: project-level at .cursor/mcp.json, or global at ~/.cursor/mcp.json. As of 2026-09, an HTTP server entry with custom headers looks like:
{
"mcpServers": {
"ismscopilot": {
"url": "https://account.ismscopilot.com/v1/account/mcp",
"headers": {
"Authorization": "Bearer pat-isms-..."
}
}
}
}Add the entry (Cursor Settings, the MCP section, or create the file directly), then restart Cursor and confirm ismscopilot appears in the MCP tool list.
This is a plain HTTP MCP server entry with a custom Authorization header. If a Cursor build only supports OAuth connectors or drops custom headers, it cannot use this path yet; check that client version's MCP documentation before debugging the token.
4. Codex config
Codex reads ~/.codex/config.toml. As of 2026-09, an HTTP MCP server entry looks like:
[mcp_servers.ismscopilot]
url = "https://account.ismscopilot.com/v1/account/mcp"
[mcp_servers.ismscopilot.http_headers]
"Authorization" = "Bearer pat-isms-..."Restart Codex after editing. If your Codex version uses a different key name for HTTP headers, follow its current MCP documentation; the constant parts are the URL and the Bearer pat-isms-… header.
5. Smoke test
Ask the agent to list your ISMS Copilot workspaces. If tools do not appear:
- restart the client after adding the server,
- confirm the token was not truncated when pasted (it starts with
pat-isms-), - confirm the URL is the account host above, not an API host.
If you hit a usage limit
The connection uses the same 4-hour UTC session window as the chat app. If create_conversation or send_message hits the cap, the first error text is the wait-or-upgrade sentence (including the next reset time) and the JSON block includes reset_at. Solo accounts and organization owners also get upgrade_url. Organization members get the team sentence instead: ask the owner for extra usage, or wait until the next 4-hour window. Their JSON carries quota_scope, org_role, and extra_usage_buyable, and no upgrade link.
Wait until reset_at, or open upgrade_url in a browser while logged into the same ISMS Copilot account (solo accounts and organization owners). When the JSON carries fallback_available: true and your plan's overflow is available (solo paid accounts with Advanced Data Protection off; never on a team pool), you can also tell the agent to continue: on your explicit go-ahead it re-sends with overflow_consent: true and the turn runs on the same up-to-2x overflow the web app offers (the reply carries overflow_active: true). Read tools still work after the chat cap.
See What to do when you hit your usage limit.
6. Rotate
For routine rotation, mint a new token, replace the old token in mcp.json (Cursor) or config.toml (Codex), restart the client, and run the smoke test. Then revoke the old token in Settings. If the old token may have leaked, revoke it immediately before configuring the replacement.
A token acts as you. Grant only the scopes you need, and revoke unused tokens.