LIVE|CLI v0.144.0·model GPT-5.6 Sol·verified 2026-07-09
Vol. I · No. 1Independent coverage of OpenAI CodexMonday, August 3, 2026
Codex Insider
The unofficial wire for OpenAI Codex.
Codex Insider
Ecosystem

Connect Codex to Atlassian

Published Jul 16, 2026 · Checked against the official docs

The short version

One login gets you into Jira, Confluence, and Atlassian's other cloud tools, using whatever permissions you already have there. But Jira Service Management and Bitbucket won't go through that login — they need the API-token endpoint, so if you only set up OAuth, those two just won't work.

What you get

One connection, five Atlassian Cloud products. Atlassian’s supported-tools reference groups them by intent (read, write, search):

  • Jira: getJiraIssue, getTransitionsForJiraIssue, getVisibleJiraProjects, searchJiraIssuesUsingJql, plus writes createJiraIssue, editJiraIssue, transitionJiraIssue, addCommentToJiraIssue, addWorklogToJiraIssue
  • Confluence: getConfluencePage, getConfluenceSpaces, getPagesInConfluenceSpace, searchConfluenceUsingCql, plus writes createConfluencePage, updateConfluencePage, and the footer and inline comment tools
  • Jira Service Management: getJsmOpsAlerts, getJsmOpsScheduleInfo, getJsmOpsTeamInfo, and the write updateJsmOpsAlert
  • Bitbucket Cloud: bitbucketRepository, bitbucketPullRequest, bitbucketRepoContent, bitbucketPipeline, bitbucketDeployment and friends
  • Compass: getCompassComponent, getCompassComponents, createCompassComponent, createCompassComponentRelationship

Cross-product tools sit on top. Atlassian marks searchAtlassian, fetchAtlassian, getTeamworkGraphContext, and getTeamworkGraphObject as beta on that page.

Ask Codex “what’s the status of PROJ-1234” or “summarize the Q2 planning page” and it resolves the right tool call itself. One OAuth login covers the set, and Atlassian’s docs state that data access respects your existing product permissions. The server doesn’t grant you anything you don’t already have.

Setup

  1. Confirm you’re on Atlassian Cloud. Atlassian scopes this server to Cloud. Data Center is a different product with its own separate MCP packages, and it isn’t what this endpoint serves.

  2. Write the entry. This is a remote server, so it takes url and never command. Add it to ~/.codex/config.toml. See Connect an MCP server for the general shape:

[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/mcp/authv2"
default_tools_approval_mode = "writes"

  1. Authenticate. Run codex mcp login atlassian. A browser tab opens to Atlassian’s consent screen, which Atlassian describes as “powered by secure OAuth 2.1 authorization”. Pick your site, approve, close the tab.

    Atlassian’s own getting-started page gives a one-line equivalent: codex mcp add atlassian --url https://mcp.atlassian.com/v1/mcp/authv2. That flag is real. gpeal added --url and --bearer-token-env-var to codex mcp add in openai/codex #4904, merged 2025-10-08. Use whichever you prefer; they write the same block.

  2. Confirm it connected. codex mcp list should show atlassian. Inside a session, /mcp lists the loaded tools.

  3. Headless or CI, with no browser to click through: use the API-token endpoint and a bearer variable instead of OAuth:

[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/mcp"
bearer_token_env_var = "ATLASSIAN_API_TOKEN"

bearer_token_env_var names an environment variable in your shell or CI secrets store. Codex reads the value from the environment at runtime, so the token itself never lands in config.toml and the file stays committable.

Gotchas

Pick the endpoint that matches your auth. Atlassian’s atlassian-mcp-server README says “The recommended endpoint for most clients is: https://mcp.atlassian.com/v1/mcp/authv2”, which is the OAuth 2.1 path and the right default for a normal Codex install. The bare /v1/mcp path is the one Atlassian documents for API-token setups.

Two tool groups need the API token, not OAuth. The same README says API token authentication “is also required for Jira Service Management and Bitbucket Cloud tools.” Atlassian’s getting-started page calls API-token auth “optional” in general, and both are true: optional for Jira and Confluence, required for those two groups. If JSM or Bitbucket tools fail under an OAuth-only session, that’s the reason.

This entry never takes command. It’s url only. See mcp_servers.<id>.command and mcp_servers.<id>.url for why an entry gets one or the other.

You don’t need the mcp-remote bridge. Guides still circulate that wrap Atlassian’s endpoint in npx -y mcp-remote <url>, which exists to give stdio-only clients a way to speak OAuth over HTTP. Codex is a native streamable HTTP client. A bare url line does the job, and it skips the cold-npx download that makes the bridge path blow the 10s startup_timeout_sec default on first run.

A connected server can still show no tools. openai/codex #4707 reports streamable HTTP servers listing Tools: (none) despite a clean connection. It’s open. If codex mcp list looks healthy but /mcp is empty, you’re likely looking at that, not at a bad config.

Translate, don’t paste. Atlassian publishes install snippets for a lot of clients, and directory sites republish them. Most of those are JSON in Claude Desktop or Cursor shape. Codex wants TOML, and the two are not copy-paste compatible. The table in Connect an MCP server maps the keys across.

One login, a lot of write surface. That single OAuth grant covers Jira, Confluence, Jira Service Management, Bitbucket, and Compass together, and it acts with your permissions. Given how much of that surface writes (createJiraIssue, editJiraIssue, createConfluencePage, bitbucketRepoContent, bitbucketPipeline), set default_tools_approval_mode = "writes" rather than leaving it unset.

Sources

More Ecosystem guides