ChatGPT Bitbucket Connector: Repository Access Options

There is no first-party ChatGPT Bitbucket connector in OpenAI's standard catalog. You can connect them through a custom connector that uses the Bitbucket API, or by copying repository content directly into a conversation. Both routes have clear access boundaries you should check before relying on them. Tools like fenbs can keep the development decisions and task context that need to survive across AI sessions, separate from the repository data itself.

This page covers the two main routes, what each one gives ChatGPT access to, and the limits to verify before you build.

Copy repository content into a conversation

The simplest way to work with Bitbucket data in ChatGPT is to paste relevant content directly into a conversation: a pull request description, a diff, a README, or a list of open issues. ChatGPT can review the code, suggest improvements, explain a change, or help draft a commit message.

This requires no connector setup and works on any plan that supports pasting text. The limit is that each session starts from zero: ChatGPT does not remember what was discussed in a previous conversation, and it cannot browse the repository on its own.

Build a custom connector with the Bitbucket API

Bitbucket has a REST API with OAuth 2.0 support. You can build a custom connector for ChatGPT that authenticates with Bitbucket and allows ChatGPT to read repository data during a conversation. Building a connector requires developer mode in ChatGPT. Which plans include it is OpenAI's to confirm: check OpenAI's help center↗ (opens in a new tab).

With a working connector, ChatGPT can read repositories, branches, commits, pull requests, issues, and file contents, within the scopes the OAuth app requests and the access the authenticated account has in Bitbucket. The setup is similar to connecting GitHub: for that guide, see how to use chatgpt github connector. For the underlying connector mechanics, see chatgpt connectors api.

What ChatGPT can read with a Bitbucket connector

• Repository metadata: names, descriptions, branch lists and recent commit history.
• Pull requests: titles, descriptions, reviewers, status and comments.
• File contents: source files up to the size limits imposed by the API and context window.
• Issues: if your Bitbucket workspace uses Jira for issue tracking, a separate Jira connector is needed.

Write permissions are separate. Adding write scopes lets ChatGPT create branches, open pull requests or post comments, but only request the permissions your workflow actually needs.

Access limits to check

Bitbucket Cloud and Bitbucket Data Center have different API endpoints and OAuth flows. Build your connector for the environment your team uses. Cloud uses https://api.bitbucket.org/2.0/, while Data Center requires a self-hosted endpoint.

• OAuth token expiry: Bitbucket Cloud tokens expire after one hour by default. Your connector must handle refresh.
• Workspace membership: the authenticated account must be a workspace member. A personal token cannot read a private workspace it does not belong to.
• Repository visibility: private repositories require authentication. A connector configured for public repositories cannot read private ones.

Keeping the task brief and review decisions

A Bitbucket connector gives ChatGPT access to repository data, but not to the agreed approach: which ticket this work covers, what the reviewer said to change, and which decisions about the code are settled. That context lives in chat histories and gets lost when sessions change.

fenbs keeps that context as tasks with plans, Decisions and rules for technical choices, and Where we left off for handoffs between sessions. For privacy considerations with code connectors, see chatgpt connectors privacy.

The practical cost of losing that context is highest during code review. If a reviewer told an AI session that a particular pattern is preferred across the codebase, or that a function should be rewritten rather than patched, that preference does not carry into the next session. A different session given the same pull request may suggest the opposite approach. The reviewer then gets two conflicting recommendations and no clear record of which one the team agreed on. Recording the technical decisions in fenbs removes that inconsistency: every AI session starts from the same agreed rules and does not need to be corrected after making the wrong assumption about the codebase conventions. This is especially useful on repositories where multiple developers each run their own AI sessions, since the shared decision record means everyone applies the same standards regardless of which session they are using.

How to do this with fenbs

1. Create a free account. One person is free with no credit card.
2. Add the development task to fenbs. Write the goal, the current approach, and what has been reviewed.
3. Write Decisions and rules for the agreed technical choices: naming conventions, architecture decisions, and reviewer requirements.
4. Connect ChatGPT to fenbs from Integrations using the MCP setup guide.
5. At the start of each coding session, ask ChatGPT to read the fenbs context. Before stopping, ask it to save progress and record any new decisions made with your approval.

For related connector workflows, see chatgpt connectors for jira if your team uses Jira alongside Bitbucket, and chatgpt connectors and apps for a broader look at what ChatGPT can connect to. For troubleshooting a connector that stops working after initial setup, see chatgpt connectors not working.