Deprecation of Forked Repositories Outside the Parent Workspace

[#1]

Hi Bitbucket Community, 

My name is Adam and I am a product manager with the Bitbucket Cloud team. On February 27, 2026, the ability to create new repository forks will be limited to the parent workspace. Existing forks to other workspaces will continue to function as normal for the time being. Where possible, we will automatically move existing cross-workspace forks to the original parent workspace. We will send another notification when this is planned. Please note, forked repositories where the creator doesn’t have write access to the parent workspace, the repositories will be left in place, and their fork associations with the parent repository will be broken.

Why we’re making this change:
This change positions Bitbucket Cloud to offer greater product reliability and introduce highly requested enterprise-grade controls like data residency.

We know that this will be a significant change for some of our customers, especially the open source community. While forks aren’t core to every Bitbucket customer’s workflow, we recognize that retiring open-source pull request support will be felt by those who depend on it.

What to expect:

• Users will no longer be able to create new cross-workspace forks after February 27, 2026.

• Existing forks to other workspaces will continue to function as normal for the time being.

• Adding the workspace slug is optional when using the Bitbucket Cloud REST API endpoint to fork a repository. Omitting the workspace parameter will assume the same workspace.

• At a later date, existing cross-workspace forks will be moved into the original parent workspace where possible.

  • Associated PRs of the forked repo remain and will function as normal

  • Once moved to the parent workspace, forked repo permissions may change based on the parent workspace.

• If moving a fork to the parent workspace is not possible or fails, you won't be able to file PRs to the parent repo of the fork, but can still file PRs inside the forked repo itself

Have questions or suggestions? We’d love to hear from you, so please leave a comment below.

[Dave Anderson]

Does "we recognize that retiring open-source pull request support will be felt by those who depend on it" mean that you no longer want to work with open-source developers, or is there some sort of work around you suggest for this?

[Colton Anderson]

Do you intend to provide any workarounds, extra settings, or features to help with development across workspaces, or is Bitbucket phasing out of open source work?

[Mouad El Kacem]

I get the technical reasons behind this change, but it’s still a big hit for open-source workflows. Cross-workspace forks make independent contribution possible without extra barriers, and removing that option risks limiting the openness and creativity that open source depends on.

I hope the team can offer an alternative or a clearer path to keep external contributions accessible.

[Tim Govers]

Any reason why I see the warning on top of a forked repository that IS in the same workspace as the parent repository?

[Volodymyr]

Where possible, we will automatically move existing cross-workspace forks to the original parent workspace.

This is a scary change, as original workspace in our company is no longer available to our team and is scheduled for removal. I'm "creator" of repositories and still have access to both organizations, but no-one else does. If this happens, everyone in the team will lose access to source code. 

[Amit Gupta]

@Adam Rouman I have 2 repos-repo1 and repo2. I forked repo2 from repo1. Will repo2 move to workspace of repo1 after this change? I do not want to. what are my options?

[Peter Falck Grony]

@Adam Rouman You say this is for cross-workspace, however I only have repositories within the same workspace (organization) but within different projects, why are these repositories getting the warning?

Will it be possible to not have the fork moved? I would rather severe the tie between the forked repository and the parent repository than having the fork moved - This change would break our organizations' compartmentalization of business logic.

[Christopher Schommer]

Hi, we got the warning for a private fork of a repo that exists in the same project/workspace? That imho doesn't make sense ...

[ccenvcvb]

I don't know what workspace or parent workspace means.

Is this part of the Atlassian "newspeak" where Issues are no longer issues but work items?

We have projects and forks across those projects. Are those affected by this change or not?
Development is a project and all release forks are in release projects.

Will this change prevent a customer with their own Bitbucket account from forking a repo we maintain?

[Adam Rouman]

Hi Folks - there are some great questions here that I will do my best to answer: 

Q: Why am I seeing this message on my fork that is in the same workspace? 

A: We initially wanted to give all users who rely on forking workflows advanced notice of the upcoming changes. Only forks to other workspaces are in scope. Based on the feedback, we are planning to update the in-product messaging to make it more clear which forks are impacted soon.

Q: How do I manage a fork's relationship to the parent repository myself? 

A: Thanks to the feedback here, we are discussing a solution for a self-serve feature that will allow customers to manage the forking relationship yourself. I hope to have an update on this soon. In the meantime, Bitbucket Support would be happy to assist by filing a ticket here and providing the team with the forked repo URL and the support team will be happy to unlink the fork relationship between forked and parent repositories.

Q: What does this mean for support for our open source workflows?

A: We recognize that this change is particularly meaningful for customers using Bitbucket Cloud for open source projects, where the typical contribution model is “fork → branch → pull request” from a different account or organization:

• Public repositories remain available – your open source projects can continue to be public, cloned, and browsed as before.

• What’s changing is the ability for contributors to create a fork into a different workspace and open pull requests back to your repo. That cross‑workspace fork + PR model is being retired.

• For ongoing open source collaboration in Bitbucket Cloud, we recommend:

  • Hosting the project in a designated shared/open source workspace, and

  • Granting trusted maintainers and frequent contributors write access so they can use branches + pull requests within that same workspace, or forks that also stay within that workspace.

• Occasional or “drive‑by” contributors who cannot be granted write access can:

  • Continue to clone your public repository and share changes as patches (e.g., via git format-patch), or

  • Work with your maintainers to agree on a contribution process that fits your project’s governance (for example, using a shared workspace for community maintainers).

We know this is a significant change for some open source maintainers and contributors, and we’re committed to providing clear guidance and migration paths so you can continue to collaborate in Bitbucket Cloud.

Stay tuned for additional updates we will be making soon.

Thanks

[Ulrich Kuhnhardt _IzymesCo_]

Here is an idea that keeps everyone happy:

Disable outside forks by default and let workspace admins enable it via a setting. 

Atlassian has a few public repos like Atlassian Connect Express that have benefited from developer community contributions. 
I find it hard to believe that Atlassian doesn’t see the value of community contributions AND at the same time shipping enterprise features. A simple checkbox and an IF statement in the backend doesn’t sound hard to implement