Atlassian developer changelog

Forge is enabling user-token support for unlicensed users in Forge function and Forge Remote invocations.
Apps can make online and offline calls on behalf of eligible unlicensed users, including calls from Forge resolvers and Forge Remote. Online calls use the invoking user’s context, while offline calls can act on behalf of a specified user where supported.
Existing Forge app permissions, product permissions, and API-specific access controls continue to apply. This change does not enable anonymous-user access.

This includes support for eligible unlicensed users accessing apps through the Jira Service Management portal.

The Forge global:ui module has moved from the Early Access Program (EAP) to Preview. You can now build apps that look and feel like Atlassian core products, featuring configurable side navigation and a dedicated entry in the Atlassian app switcher.

What’s changing

• Increased sidebar customization: New components are available for the sidebar, including MenuSection, MenuSpacer, ReorderableMenuItems, SidebarFooter, and SearchableFlyoutMenuItem. You can also use UI Kit and custom icons.

• Relevant search results: The Rovo search bar now prioritizes results from Teamwork Graph objects associated with the global:ui app you are viewing.

• Custom search results pages: Pressing Enter in the search bar now navigates to your app’s /search?text=<input> route, allowing you to build a custom search results experience.

• Compatible with all installation models: The global:ui module is now compatible with site, cross-context, and unit-level installations.

What you need to do

1. Review the global:ui documentation to understand the module's capabilities.

2. Explore the component reference for details on the new sidebar components.

3. Learn more about ingesting Teamwork Graph objects to improve search relevance for your app.

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-154-ui-modifications-for-forge-custom-fields-in-jira-and-jsm/103577

We are sunsetting SSH access via bitbucket.org in favor of ssh.bitbucket.org. This is an important change to improve Bitbucket’s security posture and safeguard our customers from denial of service abuse. We have originally announced this change on May 12, 2026 in Changelog announcement. We will be running a series of brownouts to help teams identify and mitigate any remaining usage of the old hostname.

For the brownout schedule and additional details refer to community blogpost.

During each brownout window, we will:

• Temporarily block SSH traffic on bitbucket.org

• Show clear error messages

• Show in-product messaging to create awareness

The byline on Confluence Cloud pages, live docs, and blog posts will show a single row of apps by default. Users can click to expand the byline and see any additional rows of apps.

We’re making this change to improve the customer experience by reducing Cumulative Layout Shift (CLS) in Confluence pages. This prevents page content from moving as apps load, providing a more stable reading experience for users.

Site admins who want to show all byline apps by default can enable Show all byline apps by default under Confluence administration → General configuration.

No app changes are required. All byline apps remain available. Depending on your app’s position, the number of installed apps, and the available screen space, users may need to expand the byline to see your app.

What's changing
We're introducing a new sharing level for Forge and OAuth 2.0 (3LO) apps: organization-level sharing. With it, you can share your app with anyone in the same Atlassian organization as the app owner.

Key details:

• Restricted installation: Only members of the app owner's organization can install the app using the installation link.

• Existing installations: If you change a publicly shared Forge app to organization-level sharing, existing installations on sites outside your organization will keep working.

• Upgrade restrictions: For apps updated to organization-level sharing, future app upgrades will only be available to members of the app owner's organization. Installations outside the organization stay on the current version unless upgraded by the app developer.

What you need to do
To use this new sharing level:

1. Navigate to the Developer Console and select your app.

2. Select Distribution from the left menu.

3. Under Distribution controls, select Edit.

4. Choose the Sharing within organization option and save your changes.

For more information on app distribution, see the distribute your apps documentation.

The tool listJiraIssueComments as part of the read_jira toolset has been updated.

It is now a primary tool: it is returned directly in the MCP tools/list response and can be called by name, alongside getJiraIssue, searchJiraIssuesUsingJql, createJiraIssue, editJiraIssue, transitionJiraIssue and addOrEditJiraIssueComment. Previously it was a deferred tool, reachable only through discover followed by executeRead. It no longer appears in discover results; discover lists it under primaryTools instead, and calling it through executeRead continues to work.

Inputs, outputs, toolset and the read:jira:agent-interface scope are unchanged.

Starting February 1, 2027, we'll progressively roll out a change to the portfolioChildIssuesOf() JQL function so its results include work items in team-managed spaces. Today, the function only follows hierarchy in company-managed spaces, so searches can miss descendants that live in team-managed spaces.

• portfolioChildIssuesOf() will return descendants through valid team-managed space hierarchies, including supported relationships between company-managed and team-managed spaces, such as a team-managed epic under a company-managed initiative.

• Queries that use NOT IN portfolioChildIssuesOf() will exclude these additional work items.

• Results continue to respect hierarchy rules, user permissions and issue security.

• REST API request and response formats don't change.

If your app, saved filters or automation rules assume that team-managed work items are excluded from portfolioChildIssuesOf() results:

1. Find the queries that use portfolioChildIssuesOf().

2. Check whether team-managed work items in the results would affect your logic.

3. If they would, update your queries or result handling before February 1, 2027.

We'll publish another update when the rollout starts.

What's changing
We've updated the minimum compatible Node.js version for the Forge CLI. The CLI now requires Node.js 22.23.4, 24.22.1, 26.12.1, or newer.

Node.js 20 has reached end of life and is no longer supported. To continue using the Forge CLI to develop and deploy your apps, you must upgrade your local development environment to one of the supported versions listed above.

What you need to do

1. Check your current Node.js version by running node -v in your terminal.

2. If you are running a version older than the requirements, download and install a supported version from the Node.js website.

3. Update your Forge CLI to the latest version by running:npm install -g @forge/cli@latest

4. Verify the installation by running forge --version.

For more information on setting up your development environment, see the Getting started guide.

Following the previous deprecation announcement, we will begin scheduled brownouts of the Bitbucket Cloud Code Search API on 3 November 2026 at 00:00 UTC.

Brownouts are temporary periods when the API is unavailable, intended to help you identify integrations that still need to migrate. The brownout duration will progressively increase before the API becomes permanently unavailable on 15 November 2026 at 00:00 UTC.

Migrate your integrations to the workspace code search API before the brownouts begin.

As of October 16, 2026, the following legacy Loom MCP tools are no longer returned to users in the Loom V2 rollout cohort.

Use these replacement tools:

• listLoomVideos and listLoomVideosSharedWithMe → listLoomObjects

• getLoomVideo → getLoomObjectsContent

• getLoomVideoComments and getLoomMeetingActionItems → getLoomObjectsContent with the applicable content expansion

• createLoomVideoComment and createLoomVideoReaction → addLoomInteraction

• updateLoomVideoTitle → updateLoomObjectMetadata

• updateLoomVideoPermissions → updateLoomObjectVisibility=

• shareLoomVideo → shareLoomObject

• createLoomVideoUpload → createLoomObjectUpload

• publishLoomVideo → publishLoomObject

• listLoomFolders → listLoomObjectFolders

• createLoomFolder → createLoomObjectFolder

• moveLoomVideoToFolder → moveLoomObjectToFolder

Compatibility for getLoomVideo

getLoomVideo is unlisted rather than immediately disabled. New tool-list responses do not advertise it, but existing sessions that cached its schema can continue calling it during the compatibility period. New integrations should use getLoomObjectsContent.

Tools that remain available

getLoomVideoDownloadUrl and recoverLoomVideo are not replaced by this migration.

This is the removal half of the coordinated Loom MCP V2 migration announced in CHANGE-3503.

Atlassian Rovo MCP is migrating Loom recording workflows to a consolidated V2 Loom Object tool surface.

Loom objects currently include async videos and meeting recordings. The new tools use consistent object-based names so that Loom can support more content types without another tool migration.

For each rollout cohort, the V2 tools replace the corresponding V1 tools. The MCP server will advertise only the applicable V2 replacement operations.

The V2 tools support:

• Loom ARIs, share URLs, and embed URLs as recording identifiers.

• Async videos and meeting recordings through the same tool contracts.

• Consolidated comments and reactions.

• Batch retrieval with one result per requested recording.

• Explicit recording and content-component statuses.

• Transcript, agent brief, action item, comment, attached-link, and developer-log retrieval.

• Consistent folder operations for Loom objects.

• listLoomObjects replaces listLoomVideos and listLoomVideosSharedWithMe.

• getLoomObjectsContent replaces getLoomVideo for supported metadata, transcripts, agent briefs, action items, comments, attached links, and developer context logs.

• addLoomInteraction replaces createLoomVideoComment and createLoomVideoReaction.

• updateLoomObjectMetadata replaces updateLoomVideoTitle and also supports description updates.

• updateLoomObjectVisibility replaces updateLoomVideoPermissions.

• shareLoomObject replaces shareLoomVideo.

• createLoomObjectUpload replaces createLoomVideoUpload.

• publishLoomObject replaces publishLoomVideo.

• listLoomObjectFolders replaces listLoomFolders.

• createLoomObjectFolder replaces createLoomFolder.

• moveLoomObjectToFolder replaces moveLoomVideoToFolder.

The tools remain in the existing read_loom and write_loom permission groups. This migration does not add a new organization-admin permission.

The following operations are not replaced by this migration:

• getLoomVideoDownloadUrl

• recoverLoomVideo

Availability will move through rollout cohorts. Users outside the V2 cohort will continue to receive the V1 tool surface until their cohort moves to V2.

getLoomVideo is a high-frequency tool whose schema may be cached by MCP clients. During its deprecation period, the server will stop advertising it in tools/list and discover. However, an existing client with the cached tool can continue to call it by its exact name. This prevents active sessions from failing while new and refreshed sessions move to getLoomObjectsContent.

The other replaced V1 operations use the discover and execute flow. They will be removed from the enabled operation list for each V2 cohort.

The team will monitor calls to the unlisted getLoomVideo operation. A later cleanup change will remove the old operation and its supporting action after cached usage reaches an agreed safe level.

For details about these tools and other tools available in the Atlassian Rovo MCP Server, see the supported-tools documentation.

I18n.getText() calls are now translated when their method namespace is a function invocation immediately followed by .I18n.getText(...). This covers inlined module loads and ES-module interop getters emitted by webpack and rspack in both development and production builds.

Previously these phrases could fall back to the untranslated key at runtime, and some unminified bundles could be left syntactically invalid.

When using webpack or rspack, prefer an ES module import:

The following form is still not supported:

• CommonJS destructuring that produces a bare I18n.getText(...) call, because WRM requires a namespace before .I18n.getText(...):

See https://developer.atlassian.com/server/framework/atlassian-sdk/internationalising-your-plugin-javascript/#supported-method-namespaces for more information

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-152-increasing-maximum-memory-for-forge-functions/103441

As previously announced, the jira:fullPage and confluence:fullPage modules have been removed on 30 September 2026 in favor of the unified global:fullPage module.

What’s changing

• The product-specific jira:fullPage and confluence:fullPage modules are no longer supported in the Forge manifest.

• Requests routed to legacy URLs will automatically forward to the corresponding global:fullPage URL.

• Users accessing legacy paths will see a prompt to update their bookmarks.

• Automatic forwarding support will be maintained until December 18, 2026.

If you haven’t already migrated your apps, refer to global:fullPage documentation to get started: https://developer.atlassian.com/platform/forge/manifest-reference/modules/global-full-page/