Some functionality in Forge remains in Early Access Program (EAP) while we're still making changes that may break your apps. Learn more about the current functionality in EAP.

25 August 2026

Deprecation Notice App macros will move to a single category as element browser categories are modernized

In 6 months on Feb 25, 2027, app macros will only appear in one category in the modal element browser, and the categories ([string]) property will be fully replaced by a new category (string) property for Forge app macros.

Furthermore, we’re updating both the slash menu element browser and modal element browser to improve discoverability of our shared offerings, expected to begin rollout on Oct 6, 2026.

These changes impact all apps using macros and require action. Read More details below for more information on what’s changing, action required, and timelines.

More details

Which apps are affected?

All apps using Macros. Learn more about app macros at the following links.

What’s changing?

DEPRECATION NOTICE In 6 months on Feb 25, 2027, app macros will only appear in one category in the modal element browser, and the `categories ([string])` property will be fully replaced by a new `category (string)` property for Forge app macros

Today, app macros can set an optional categories ([string]) property that defines which categories (potentially multiple) the app macro should appear in within the modal element browser (not the slash menu element browser).

In 6 months on Feb 25, 2027, all app macros will only be able to appear in one category in the modal element browser instead of multiple categories like they can today, to improve end users' browsing experience.

For Forge app macros

Since we are moving toward one category per app macro to improve the browsing experience, we have introduced a new category (string) property, where developers can define one valid category string to determine where their app macro shows up in both the modal element browser and slash menu element browser. Valid category inputs for this field will be:

structure (Native examples: Action item, Table, Status)
media (Native examples: Image, video, or file, Link, Emoji)
embed (Native examples: like Google Drive, Figma, Dropbox)
text-formatting (Native examples: Bullet list, Heading 1, Quote)
data-and-charts (Native examples: Database, Jira work items, Child items)

To learn more about these new categories, read the second part of this announcement.

On Feb 25, 2027, the categories ([string]) property will no longer be recognized by Forge app macros. It will effectively be fully replaced by this new category (string) field, making it so Forge app macros only appear in one category. Make sure to update the category (string) property by then to explicitly set which category you’d like your app macro to live in. Otherwise, if there is no valid entry in the category (string) property by then, your app macro will appear in an “Other elements” category as well as the default “All” category.

For Connect app macros

On Feb 25, 2027, Connect app macros will only appear in the first category listed in their categories ([string]) property with the below mapping. Connect app macros will not gain access to the new category (string) property.

formatting, confluence content, navigation, admin → structure
reporting, development → data-and-charts
media, visuals, communication → media
external-content → embed
No valid categories provided → Other elements (as well as the default "All" category)

Before the above deprecation on Feb 25, 2027, we will also be updating the categories & appearance of the slash menu element browser and modal element browser to improve discoverability of our shared offerings, expected to begin rollout on Oct 6, 2026. We will be:

Updating the set of categories we have to better capture our shared offerings.
Updating the slash menu element browser to actually show the categories.
Updating the modal element browser to show the new categories.
Cosmetically modernizing the slash menu and modal element browser.

Example of new categories in slash menu element browser

Example of new categories in modal element browser

Before this release, the valid set of categories app macros could use were:

Formatting - formatting
Confluence content - confluence-content
Navigation - navigation
Admin - admin
Reporting - reporting
Development - development
External content - external-content
Media - media
Visuals and images - visuals
Communication - communication

After this release, the new valid set of categories app macros can use will be the following. Any of the above categories not listed below will be considered legacy categories.

Structure - structure (Native examples: Action item, Table, Status)
Media - media (Native examples: Image, video, or file, Link, Emoji)
Embed - embed (Native examples: like Google Drive, Figma, Dropbox)
Text formatting - text-formatting (Native examples: Bullet list, Heading 1, Quote)
Data and charts - data-and-charts (Native examples: Database, Jira work items, Child items)

Any app macros with legacy categories still listed in their categories property on Oct 6, 2026 will have their categories automatically mapped to new categories in product with the below mapping.

formatting, confluence content, navigation, admin → structure
reporting, development → data-and-charts
media, visuals, communication → media
external-content → embed
No valid categories provided → Other elements (as well as the default "All" category)

If, however, you would like your app macro to appear in different categories than it would automatically be mapped to, update the new aforementioned category (string) property with any one of the new categories (available only for Forge app macros) by Oct 6, 2026.

As mentioned in the first part of this announcement, app macros will continue to be able to appear in multiple categories in the modal element browser for 6 months until Feb 25, 2027 , when app macros will begin to appear in only one category.

In the slash menu element browser, however, with very limited screen real estate, app macros will only appear in one category upon release on Oct 6, 2026. Furthermore, we plan to show up to 30 items per category in the slash menu element browser. If there are more items, we’ll show a “View more” CTA that leads to the modal element browser where all items appear. However, to ensure app macro discoverability, we will always show up to 10 app macros (if they exist) in a category in addition to the 30 item maximum. In the future, we will explore more dynamic behavior here.

For Forge app macros, this category will be determined by the category (string) property if available, or the first category listed in categories ([string]) as a fallback until Feb 25, 2027, when categories ([string]) will no longer work.
For Connect app macros, this category will be determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.

Action required from developers of app macros

For Forge app macros

To ensure your app macro appears in an accurate category as we roll out these changes, we strongly recommend updating the new category (string) property (available for use by developers now) with one of the new valid categories below by Oct 6, 2026, when we begin to rollout the modernized element browser experience.

If not by Oct 6, 2026, be sure to update the new category (string) property by Feb 25, 2027 to ensure your app is assigned a category when categories [(string)] is no longer recognized. Otherwise, it will be shown in “Other elements” as well as the default “All” category.

Valid categories:

Structure - structure (Native examples: Action item, Table, Status)
Media - media (Native examples: Image, video, or file, Link, Emoji)
Embed - embed (Native examples: like Google Drive, Figma, Dropbox)
Text formatting - text-formatting (Native examples: Bullet list, Heading 1, Quote)
Data and charts - data-and-charts (Native examples: Database, Jira work items, Child items)

To help developers plan, here is a simplified timeline of the upcoming changes.

Between now and Oct 6, 2026:

In the slash element browser: All app macros will continue to appear as they do today.
In the modal element browser: All app macros will continue to appear in the macro element browser in any valid legacy categories listed in categories ([string]). The new category (string) property will not be used in product until then.

On and after Oct 6, 2026, and before Feb 25, 2027:

Forge app macros will:
- In the slash element browser: Appear only in one category determined by the category (string) property – or, the first category listed in categories ([string]) as a fallback if no valid category (string) is set.
- In the modal element browser: Appear either in one category determined by the category (string) property – OR in one or multiple categories listed in categories ([string]) as a fallback (with above mapping between legacy and new categories) if no valid category (string) is set.
Connect app macros will:
- In the slash element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
- In the modal element browser: Appear in one or multiple categories listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.

On and after Feb 25, 2027:

Forge app macros will:
- In the slash element browser: Appear only in one category determined by the category (string) property. categories ([string])will no longer work or be recognized.
- In the modal element browser: Appear only in one category determined by the category (string) property. categories ([string])will no longer work or be recognized.
Connect app macros will:
- In the slash element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.
- In the modal element browser: Appear only in one category determined by the first category listed in categories ([string]) as Connect app macros will not gain access to the new category (string) property.

For Connect app macros

We highly recommend moving to Forge and following the above steps for Forge apps. Otherwise, no work is required for Connect apps, as Connect app macros will not gain access to the new category (string) property nor be able to update their categories ([string]) property.

Thank you

Lastly, thank you for giving valuable feedback on RFC-140: Updating categories in the editor’s element browser about this topic.

Added Rovo Agent Connector — EAP to Preview

The Rovo Agent Connector is now officially in Preview. You can now deploy apps using this module to production and staging environments, enabling Marketplace listing.

What's changing

A2A v1.0 is now required — v0.3 is no longer supported. Apps still on v0.3 will be rejected at deployment. See the migration guide for full details.
System user mentionability — adding rovo:agentConnector to your app makes the system user non-mentionable; the agent connector user takes its place. The CLI (v13.3+) warns and prompts for approval at deploy time.

What you need to do

Add version: "1.0" to protocols.agent2Agent in your manifest.
Update your JSON-RPC implementation to the A2A v1.0 protocol — see the migration guide.
Update to Forge CLI v13.3+ (npm install -g @forge/cli@latest).

For full integration details, see https://developer.atlassian.com/platform/forge/remote-agents-in-jira/ and the https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-agent-connector/.

21 August 2026

Announcement Provision demo development sites from the CLI

You can now use the Forge CLI to provision a demo development site and install your app directly to it. A demo development site is a One Atlassian environment containing realistic seeded data and enterprise editions of Jira, Confluence, Jira Service Management, and Rovo.

What’s changing

You can provision or retrieve your active demo development site by running:

forge site provision

If you already have an active demo site, the CLI returns it instead of provisioning another one. Otherwise, the CLI requests a new site and displays its provisioning status.

You can also deploy and install your app directly to your demo site:

forge deploy
forge install --demo-site

The short form of --demo-site is -d:

forge install -d

If you don’t have an active demo site when running forge install --demo-site, the CLI offers to provision one before continuing with the standard installation flow.

Key details include:

Site allocation: Each developer can have one active demo development site. You can use the same site to develop and test multiple Forge apps.

Site lifecycle: Demo sites are active for 90 days by default.

Background provisioning: You can press Ctrl+C while waiting without cancelling the provisioning request. Run forge site provision again later to check its status.

Installation options: You can’t combine --demo-site with --site. Existing forge install and forge install --site <site> workflows continue to support traditional Atlassian development sites.

What you need to do

Update to the latest version of the Forge CLI:

npm install -g @forge/cli@latest

No action is required if you want to continue using an existing Atlassian development site.

To use a Forge demo development site, either provision one first with forge site provision or run forge install --demo-site after deploying your app.

For more information, see:

19 August 2026

Announcement Native proxy support for Forge CLI

What's changing
With Forge CLI 13.4.0 you can now configure the Forge CLI to use a network proxy natively through CLI settings or environment variables. This removes the need for manual workarounds, such as modifying the CLI source code or using the global-agent package.

To save a proxy configuration for all Forge CLI commands, run:

forge settings set proxy ${yourProxyServer}

Alternatively, you can configure the proxy for your current terminal session by setting the FORGE_PROXY environment variable:

export FORGE_PROXY=${yourProxyServer}

More details

Update to the latest version of the Forge CLI by running npm install -g @forge/cli.
Configure your proxy using the forge settings command or the FORGE_PROXY environment variable as shown above.

For more information on using Forge in restricted network environments, see Using the Forge CLI on a corporate network.

18 August 2026

Announcement [2-week notice] Connect EOS customer messaging to go live to production instances for apps that have declared a 'YES' migration intent

As per our previous announcement, we will be progressing admin-facing migration messaging for apps that have declared a migration intent of ‘yes’ on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.

Apps affected in this rollout

Apps that have declared connectToForgeMigration with a migration intent of "yes"

The following app categories have already been rolled out to receive admin-facing messaging as per our previous changelog:

Apps that have declared connectToForgeMigration with a migration intent of "no"
Apps that have declared connectToForgeMigration with a migration intent of "unsure"
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (i.e., Connect apps)

What you need to do

Adopt the connectToForgeMigration module in your Forge manifest for each major version of your app (https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-forge-migration-module/).
Declare your migration intent as this determines which cohort your app falls into and when messaging appears.
Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.
Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants for apps that have declared ‘yes’ to the migration intent. Install your app on a canary instance, navigate to the Connected Apps page, and confirm your migration URL renders as expected before the production rollout reaches your cohort.

More details

Exemptions

Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.

For the full customer-facing experience (including more information on what admins will see), please visit the documentation here. This page will also be shortly updated to capture our rollout approach.

Early Access Point-to-point logs export (EAP) improvements

Following the initial Point-to-Point Logs Export EAP announcement, the feature now includes the following improvements:

What's changing

Environment filtering: You can now filter which environments (production, staging, or development) send logs to your third-party logging tool. This helps you manage costs by, for example, exporting only production logs while using the Forge Developer Console for other environments.

Per-app export URLs: You can now configure unique export URLs for different sets of apps within your developer space. This gives teams with multiple apps the flexibility to route logs to separate destinations.

Google Cloud Logging support: You can now export Forge app logs directly to Google Cloud Logging, in addition to existing support for Datadog, Sumo Logic, Amazon CloudWatch, and Splunk.

What you need to do

If you haven't already, sign up for the EAP.

Review the setup guide to understand how to configure your observability vendor and share the required details in the EAP form.

17 August 2026

Added Forge CLI: Inspect application bundles with the new --inspect option

What's changing

The Forge CLI build and deploy commands now include a new --inspect option. This option copies the Forge application bundle, as packaged for Atlassian infrastructure, into your local .forge/inspect directory.

You can use this to:

Investigate the final structure of your application before it is deployed.

Troubleshoot bundling issues or unexpected behavior in the deployed app.

This new option replaces the undocumented FORGE_INSPECT_ARCHIVE environment variable, which is now deprecated and will no longer function.

What you need to do

To inspect your application bundle, run either of the following commands:

forge build --inspect

forge deploy --inspect

After the command completes, you can find the packaged application files in the .forge/inspect directory within your project.

More details

See the https://developer.atlassian.com/platform/forge/cli-reference/build/ and https://developer.atlassian.com/platform/forge/cli-reference/deploy/ documentation for more information.

Fixed Linter behaviour fixed for manifest environment variables

Forge CLI 13.3.0 introduced a server-side manifest check as part of the new approval workflow. However, environment variables in the manifest.yml file were not being interpolated before being sent to the validation endpoint. This caused the linter to return false-positive MANIFEST_INVALID_RULE errors for valid manifests.

This issue is fixed in Forge CLI 13.4.0. The CLI now correctly interpolates environment variables before performing the pre-deployment manifest check.

More details

Update your Forge CLI to version 13.4.0 or later by running:
1npm install -g @forge/cli@latest
For more information on using variables in your manifest, see the manifest variables reference.
To learn more about why these manifest checks and approvals are required, see the documentation on major version upgrades.

14 August 2026

Added UI modifications support for Jira Service Management agent view now in Preview

You can now use UI modifications in the Jira Service Management (JSM) agent view. This is an extension of the existing jira:uiModifications module and covers the views your agents use inside a service project.

What's changing

UI modifications now support three specific agent views:

Global issue create (GIC) - viewType: GICAgentView

Issue view - viewType: IssueViewAgentView

Issue transition - viewType: IssueTransitionAgentView

The agent view supports the same fields and methods as equivalent Jira views but is tailored for service projects.

Key differences include:

Extension context: Exposes the requestTypeId of the work item.

Supported fields: The set of supported fields differs from the JSM request create portal view.

REST API: The UI modifications REST API (GET, POST, and PUT) now accepts these three agent view types. When configuring agent view contexts, portalId must not be set, and requestTypeId is optional (omitting it means the context is not scoped to a specific request type). One of projectId, issueTypeId, or viewType can act as a wildcard, with a maximum of one wildcard per context.

You can use view.getContext() to detect the current view type:

import { view } from '@forge/bridge';
import { uiModificationsApi } from '@forge/jira-bridge';

uiModificationsApi.onInit(async ({ api }) => {
  const context = await view.getContext();

  switch (context.extension.viewType) {
    case 'GICAgentView':
      // Runs when an agent creates a work item in a service project.
      break;
    case 'IssueViewAgentView':
      // Runs when an agent opens a work item in a service project.
      break;
    case 'IssueTransitionAgentView':
      // Runs when an agent transitions a work item in a service project.
      break;
    default:
      break;
  }
}, () => []);

What you need to do

No action is needed if you don't want to support the agent view. If you do want to add agent view support, simply define the context for the Agent View view types using the REST APIs – your Forge app will then be invoked automatically in the agent-specific views.

For more information, see:

• JSM UI modifications module documentation (to be attached)
• uiModifications API bridge (to be attached)

Added rovo:mcp module now available in Preview

The rovo:mcp module has progressed from the Early Access Program (EAP) to Preview. This module enables Forge apps to expose https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-action/ as tools that you can add to custom agents in Rovo Studio.

What's changing

Apps using the rovo:mcp module can now appear under Connected Apps in Rovo Studio. This allows makes configured actions available as tools for custom agents, enabling them to interact with external data and services.

What you need to do

If you were already using the module during the EAP, no changes are required.
To get started, add the rovo:mcp module to your Forge app manifest and configure the actions you want to expose.
Review the updated documentation for implementation details:
- https://developer.atlassian.com/platform/forge/build-a-hello-world-rovo-mcp/
- https://developer.atlassian.com/platform/forge/read-jira-issues-with-a-rovo-mcp-tool/

Early Access Installations page improvements (EAP)

The installations page in the developer console has been redesigned to scale with large app install bases and to give you more control over how you view your data.

Key improvements include:

Performance at scale — the page loads quickly even with large install bases.
Configurable columns — hide, resize and reorder columns, and pin your most important column to suit your workflow. Your preferences are saved locally.
Improved search and page navigation — find specific installations faster with a more responsive search and cleaner pagination.

This feature is currently in Early Access. To participate, sign up for the EAP.

13 August 2026

Announcement Forge bridge invoke can now return metadata

The Forge bridge invoke method now supports an optional metadata argument. This allows you to receive additional information about an invocation, such as rate limiting details, alongside the response.

What's changing
When you pass a metadata argument into the invoke function, it returns an object containing both a body field (the invocation response) and a metadata field. Any supported field set to true in the metadata argument will be returned within this metadata field.

Currently, rateLimitProperties is the only supported field in the metadata. This allows you to monitor rate limiting information for your invocations to better manage app performance and reliability.

Example usage:

invoke('getText', { example: 'my-variable' }, { rateLimitProperties: true })
  .then(({ body, metadata }) => {
    // Log metadata for debugging purposes
    console.log(JSON.stringify(metadata));
}

What you need to do
If you want to access invocation metadata, update your invoke calls to include the third metadata argument and handle the new response structure ({ body, metadata }).

Existing calls to invoke without the metadata argument remain unchanged and will continue to return the response body directly.

For more details, see the Forge bridge invoke documentation.

Added Environment-specific configuration for Forge container services is now availalable

What's changing
You can now use a single manifest.yml file across different deployments while adapting your Forge Container services configuration based, for example, on the environment type (development, staging, or production). This allows you to optimize for cost or performance by overriding settings like memory or CPU for specific environments.

What you need to do
To start using environment-specific configurations, update your manifest.yml using the new overrides syntax. For detailed implementation steps and examples, refer to the Forge Containers manifest overrides reference.

Early Access Static Content Macros for Confluence on Forge

Static Content Macros for Confluence on Forge are now available in Forge’s Early Access Program (EAP).

Render your Confluence macros as static content instead of iframes, reducing app invocations. To enable static rendering, sign up for the EAP and add the static property to your macro module in manifest.yml, specifying either a function or endpoint (for Forge Remote).

What you need to do

Sign up for the EAP: To sign up for this EAP, submit a request via the Forge EAP form here.
Read detailed guidelines for the EAP here.
Read documentation for the feature here.

10 August 2026

Added Developer Console now displays build tags used for deployments and environments

The Forge Developer Console now provides visibility into build tags for your deployments. This update allows you to:

Identify if a specific tagged build was used for a deployment.

See if the most recent deployment to an environment used a tagged build.

To view the build tag for a specific deployment:

Navigate to the Deployments tab in the Developer Console.

Select the menu button and click more info under the actions column for the desired deployment.

To view the most recent tagged build for an environment:

Navigate to the Environments tab in the Developer Console.

Click on the date shown under the Last deployment column.