Atlassian developer changelog

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/

The Atlassian Rovo MCP Server is adding twelve Jira Service Management tools through MCP V2. These tools support searching and triaging requests, reviewing and approving Request Resolver plans, creating customer requests, transitioning requests, deciding pending approvals, and reading or setting Workforce Management agent availability.

The four existing Operations tools getJsmOpsAlerts, getJsmOpsScheduleInfo, getJsmOpsTeamInfo, and updateJsmOpsAlertare also moving from MCP V1 to MCP V2. They retain their existing names and are not counted as new tools.

JSM tools in MCP V2 support OAuth 2.1 and API token authentication. Read tools belong to read_jsm and require read:jsm:agent-interface; write tools belong to write_jsm and require write:jsm:agent-interface. getJsmRequestResolverPlans, searchJsmRequests, and approveJsmRequestResolverPlans also require read_jira and read:jira:agent-interface. updateJsmOpsAlert additionally requires read:jsm:agent-interface.

Tool availability depends on granted scopes, the permission groups enabled by your organization admin, and your app access. See Supported tools for details.

What's changing
From January 1, 2027, Atlassian cloud will add new IP address ranges as we expand our cloud infrastructure.

The new ranges are in addition to our existing ones.

The new ranges are:

• New range: 131.162.88.0/21

  • Requests to Atlassian (browsers and your clients calling Atlassian APIs): 131.162.88.0/23

  • Requests from Atlassian (webhooks, Connect lifecycle calls, and other requests from Atlassian to your app): 131.162.90.0/23

What you need to do
If your app, remote backend, or integration allowlists Atlassian IP addresses, you must add these ranges before January 1, 2027, to avoid service interruptions.

These ranges are already included in our official IP range list (viewer tool). If you automate your allowlist updates from this file, no further action is required. For more details, see our documentation on IP addresses and domains for Atlassian cloud apps.

EARLY ACCESS: Forge Global Apps
We are ready to kick off the Forge Global Apps Early Access Program (EAP). Forge Global Apps are installed in the platform and can optionally link to one or more Atlassian apps.

What's changing

• Installation into unit instead of an Atlassian app workspace

• Apps can work across sites in a unit

• No required Atlassian app link

What you need to do
Sign up for the EAP: submit a request https://ecosystem.atlassian.net/servicedesk/customer/portal/1040/create/18611 and we will get in touch with instructions soon

The Teamwork Graph Consumption API is now moving into Preview, providing relationship-first querying across Atlassian Cloud objects and connected third-party tools.

What's changing

The Teamwork Graph API lets you query connected context across Jira work items, Confluence content, Loom videos and meetings, external development artifacts, Goals, and Teams using a unified GraphQL endpoint.