Deprecation of Forked Repositories Outside the Parent Workspace

[#1]

[Pinned Update 1/9/2026:]

Thank you to everyone who has engaged with this post so far. Based on the feedback we have received, I wanted to provide a clear update (also pinned to the top of this post) on what is happening with forked repositories to other workspaces:

1. This post/update only applies to cross workspace forked repositories. Forked repositories within the same workspace are not affected by this. We will be updating this message in product to only show on cross workspace forked repositories only.
2. Atlassian will NOT be moving any forked repositories into the parent workspace on your behalf. Because of the security and reliability updates we are making to our platform, we plan to, however, automatically break the forked repository relationships. Once forked repository relationships are broken, all pull request functionality will remain as normal/expected.
   1. Please note: Cross-workspace PRs that have already been created will be able to be viewed and merged. You will not be able to create a cross-workspace PR from the fork to the parent if the relationship is broken, but will be able to continue creating PRs from child to parent if both repositories exist in the same workspace.
3. The above change will occur On July 1, 2026. On this date, we will also be removing the ability to create new cross workspace forks. We previously communicated this would be removed February 27, 2026, but are now extending this to July 1, 2026. We want to give enough time to manage outstanding forks and update your software development workflows as needed.
4. If you would like to break the forked repository relationship to the parent repository, you can do so today by contacting support. If you are a repository admin and would like to do this yourself, we are building a self-serve feature to support this. The feature will be available soon and I will update this post again once available.
5. What does this mean for support for our open source workflows?
   • Public repositories remain available – your open source projects can continue to be public, cloned, and browsed as before.
   • 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).

Again, thank you for your feedback and please reach out if you have additional questions.

[Original Post]

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 

[Stefan Prelle]

For that to NOT being a stupid idea, find means that open source projects can have additional users in a workspace without needing to pay for that. Without that, you force every open source project to leave Bitbucket.

[Neill Magill]

I think the issue with killing off pull requests for people outside of the main workspace for open source projects is that it makes reviewing the changes from those contributors much harder, the pull request tools are very valuable for giving good feedback on the changes that people are making; the use of patches will make this much more challenging.

[JAY PRAKASH SAH]

Hi @Adam Rouman

Which team should I submit a request to in order to unlink the fork relationship? My older workspace is no longer active, and I need to make my current workspace the parent one.

[Eric Gruss]

Please give us the option of just severing the fork instead of moving it back to the parent as that would be a cleaner option in many of our cases.

[mispr]

We have hundreds of repositories, forked from a template repo that served its purpose back in the day. We wanted to archive this repo, but this is not possible in Bitbucket Cloud: https://jira.atlassian.com/browse/BCLOUD-18018.

We then decided to create a separate "archive" workspace, to move these repositories out of our active workspace, to clean up, and to avoid unnecessary overhead in 3rd party tools that scan / use our workspace.

Does this mean we need to move all of these archived repositories back to our active workspace?
Because that's just not feasable right now.

We should be able to sever the connection from these forked repositories and their parents in the other workspace.

[Adam Rouman]

Hi Everyone, 

Thanks for the feedback. We understand this is an adjustment to your development processes. Therefore, we wanted to let you know we are listening and will have more updates to share in January. This will include additional details about your options for managing existing cross workspace forks and the timeline for when cross workspace forks would be automatically migrated.

[Andreas Filler]

I would highly appreciate to be able to disconnect the fork on my own. Like someone else already wrote, there are a lot of reasons why a fork is legally and by purpose forked to another workspace and it would be terrible if it would fall back with all the changes done in the meanwhile to the original one. A lot of work would be given to people who should have/see it. It would be comparable to a data breach.

tl;dr: I don't welcome this change at all and think there are much more relevant things to improve in Bitbucket, but if you would give us admins the possibility to unlock the repos from their parents it's an "acceptable" change.

[Bryant Boatright]

@Adam Rouman Tacking on another request to let the owner of the fork sever the connection to the parent.

I understand the change is beneficial to Bitbucket/Atlassian, but am frustrated that the baseline resolution is moving the fork into the parent workspace w/o opt-in from the fork owner.

It seems as though the baseline resolution should be to sever the tie between fork and parent while presenting the option of allowing the fork owner to move the fork into the parent workspace.

[Jason Southwell]

Wait... so first you eliminate forks to personal workspaces due to reducing size limits..  so we create a new secondary corporate workspace for our devs to put their personal forks in.  Now you're removing our newly created forks?????

What the hell are we supposed to be doing? 

I don't want personal forks polluting our main corporate workspace.  That's not going to fly.  What can we do to continue to keep our personal forks separate from our corporate merged/approved source control state.

[pshryock]

Yikes.

[Witkowski Konrad]

Its sad joke.You write:

"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." 

But as free user I cant contact you because "Bitbucket Free comes with Community Support." So what can I do for now, I have 2 options: first option is to pay and cross fingers you will unlink repo, 2nd option is to migrate to another service. When if at all we will be able to resolve this problem by ourself? 

[Jody Tate]

Is there, or will there be, a workspace-level view or inventory of affected repos in addition to the per-repository notifications? Having visibility from the workspace lens would enable faster auditing for potential impacts.

[techguidesinc]

I also would highly appreciate to be able to disconnect forks on my own.

We are a small team of developers that allow our clients to fork our private repositories.  They are forked because:

• Client has control of the code in their fork independently of us.
  • they have the ability to lock us out and still use the code.
  • they can make code changes independent of us.
  • they can connect their hosting provider to their code.
  • they can decide if or when they want to pull or push updates.
• The cross‑workspace fork + PR model gives us the tools we need to easily review changes and pull or push updates between their repositories and ours.
• When we make updates to our packages, we can decide which clients receive those updates.

In other words, the repositories are forked because they are supposed to be independent from the original parent workspace. If forks are automatically moved to the original parent workspace, our clients will lose access to their code, and our workspace will be filled with code we don't want or possibly don't own. Permissions alone cannot be used to determine what should be moved to the original parent workspace, because usually we have permission to work on client code.

By giving us a tool to disconnect the forks and giving us enough time to do that before they are automatically moved to the original parent workspace, we should be able to make it through this change.

In case it is not obvious, this change has a very negative impact on how we do business.

[Martijn van Buul]

We recently obtained a Jira project and the accompanying bitbucket repository from a sister company; the migration wizard set this up as a cross-workspace fork.

The announced changes would mean that our repository (which has since diverged) would transfer back to the original owner, and would mean that most of our developers would no longer have access to our code. 

Since I was unable to remove the relationship myself, I had to raise a ticket with the bitbucket support team.  A method to disconnect forks would have avoided this support ticket - I am sure they have better things to do.

They were kind enough to help me quickly, but asked me "to please share [the feedback] on the post so that the PM can collect it". Maybe Atlassian should consider using Jira Service Desk internally ;)