GitHub Copilot With Bitbucket: Setup and What Needs a GitHub Repository

GitHub Copilot works with Bitbucket repositories because it runs inside your editor, not inside the repository host. You need a GitHub account with a Copilot plan, a supported editor with the Copilot extension, and the code open locally. Where the remote repository is hosted does not affect inline completions or Copilot chat. Tools like fenbs keep task context outside both the editor and the repository host, so work history and project decisions travel with the code regardless of where it is stored.

This guide covers the setup requirements, what to check before you start, and which Copilot features do depend on a GitHub-hosted repository.

What you need to use Copilot with Bitbucket code

Three things are required. First, a GitHub account with a Copilot subscription. This is separate from your Atlassian account for Bitbucket; they do not share a login. Second, a supported editor such as VS Code or a JetBrains IDE with the GitHub Copilot extension installed and signed in. Third, the Bitbucket repository cloned to your local machine and open in that editor.

Once those three are in place, Copilot reads the code in your open files and offers completions and chat. It does not read from Bitbucket directly. Check GitHub's Copilot documentation↗ (opens in a new tab) for the current plan options and the list of supported editors.

Setting up Copilot with a Bitbucket project in VS Code

1. Clone your Bitbucket repository to your local machine using the Bitbucket-provided Git URL.
2. Open the cloned folder in VS Code.
3. Install the GitHub Copilot extension from the VS Code Extensions panel if not already installed.
4. Sign in to GitHub from the Copilot extension using your GitHub account that has Copilot access.
5. Open a source file in the project. Copilot should offer completions as you type.

For team licensing, see GitHub Copilot business plans and GitHub Copilot license. Copilot advanced settings such as public code matching and content exclusions apply based on your GitHub organization settings, not your Bitbucket workspace.

Which features require a GitHub-hosted repository

Inline completions, Copilot chat, and code explanation work with any code open in a supported editor. These features do not care where the remote is hosted.

The Copilot cloud agent, which can create branches, open pull requests, and run tasks autonomously, is tied to GitHub repositories. It creates pull requests on GitHub. If your repository is hosted on Bitbucket, the agent cannot open pull requests there. For those workflows, you would need to either mirror the repository to GitHub or work with the agent on a GitHub-hosted copy of the project.

Copilot knowledge bases, which allow indexing a repository for chat, are also a GitHub-specific feature. Standard chat inside the editor does not require this, but some of the more advanced chat features that reference repository-wide knowledge are designed around GitHub hosting.

Reviewing code Copilot suggests in a Bitbucket project

Reviewing Copilot suggestions is the same whether the repository is on Bitbucket or GitHub: accept inline completions with Tab, review multi-file changes through the diff view, and commit reviewed changes to a branch before merging. The Bitbucket pull request flow is separate from Copilot; you raise pull requests in Bitbucket as normal after committing the changes Copilot helped write.

If your Bitbucket project has custom merge checks or CI pipelines, they apply to Copilot-assisted commits in exactly the same way as to any other commit. Copilot generates code; the standard review and pipeline gates still run. See GitHub Copilot vulnerabilities and security risks for guidance on reviewing Copilot output for security issues before committing.

Keeping task context independent of the repository host

One practical limitation of using Copilot with Bitbucket is that the Copilot chat history stays in the editor session. If you switch machines, hand the project to a colleague, or open a new session, the previous conversation is gone. This is true regardless of where the code is hosted.

An external task record that any connected assistant can read means the project context is not tied to an editor session or a repository host. Whether your code is on Bitbucket, GitHub, or any other host, the tasks, decisions, and where-we-left-off record is available in the same place.

How to do this with fenbs

1. Create a free account and add a project for the Bitbucket repository you are working on.
2. Add the current tasks, their plans, and any branch or PR references that are relevant.
3. Write the project's standing decisions as Decisions and rules: coding conventions, approved libraries, review requirements.
4. Connect your AI assistant over MCP from Integrations. Ask it to read the project context before starting each session.
5. Update Where we left off before ending a session so the next one starts from the current task state.

If you later move the repository from Bitbucket to GitHub, the fenbs project record moves with you without any changes. The task context is not attached to the hosting platform. See GitHub Copilot memory to understand what Copilot itself retains across sessions and how that fits alongside an external record.