Changelog

What’s changing

The tokens per minute (TPM) rate limit for Forge LLMs has been increased from 50,000 to 500,000.

This 10x increase allows you to build more complex agentic solutions and handle larger volumes of data within Forge's hosted app platform. The limit applies per installation of your app for each model.

What you need to do

No action is required to benefit from this increase; the new limit is already active for all Forge apps using the LLM API.

If your app previously encountered rate limiting errors (429 Too Many Requests) due to token usage, you may now be able to increase the frequency or size of your LLM requests. For more details on all Forge LLM constraints, including requests per minute and context window sizes, see the Forge LLM limits documentation.

What's changing

The Forge rovo:skill module has progressed from the Early Access Program (EAP) to Preview. This module lets you package reusable instructions, supporting reference files, and optional Rovo action dependencies that Forge Rovo agents can load for specialized tasks.

Rovo skills are now available to all Forge developers without an EAP sign-up and are suitable for early adopters in production environments. You can use skills to keep an agent’s main prompt focused while moving task-specific procedures, multi-step action orchestration, validation, and error-recovery guidance into reusable SKILL.md files.

During Preview:

• Apps that declare rovo:skill can be deployed to development, staging, and production environments.

• Skill-to-skill dependencies aren't supported.

• Executable skill sources, including scripts, aren't supported.

• Agents select skills based on their descriptions and the user’s request; explicit invocation by skill name isn't supported.

What you need to do

If you already use Rovo skills through the EAP, no manifest changes are required. Redeploy your app to the environment where you want to use it.

To add a skill to a Forge Rovo agent:

1. Create a skill directory containing a SKILL.md file that follows the Agent skills specification.

2. Declare the directory in a rovo:skill module and list any Forge actions it depends on.

3. Add the skill module key to the skills property of your rovo:agent module.

4. Deploy and test the app in your target environment.

What’s changing
You can now build your Rovo actions once and expose them as tools to both custom agents in Rovo Studio and third-party, MCP-enabled AI clients. This is made possible through the rovo:mcp module, which is now available in Preview.

With this capability, your Forge tools can reach users in external clients such as Claude Desktop, Codex, and Cursor. This allows you to bring Forge functionality into more AI-powered workflows without building separate integrations for every client. For example, a Rovo action that retrieves and summarizes Jira issues can now be made available in both Rovo Agents and external AI environments.

Admins remain in control of this connectivity:

• Opt-in access: External access is disabled by default and must be enabled separately for each app installation.

• Unified control: During Preview, enabling external access exposes all tools declared in the app’s rovo:mcp module.

• Secure execution: Users connect via OAuth, and every tool invocation respects their existing permissions on the Atlassian site.

What you need to do
To start connecting your tools to external AI clients:

1. Define your tools in the manifest.yml file using the rovo:mcp module.

2. Update your app to use the latest version of the Forge CLI to support the new module definitions.

3. Follow the Build your first Rovo MCP tool guide to set up the integration.

4. If you are building tools that interact with Jira data, refer to the tutorial for reading Jira issues with MCP.

We’re launching an addition to our new dashboards Forge module, dashboard:filters, that allows Forge widgets to integrate natively with Atlassian dashboard filters. This early access program (EAP) enables you to test the module and provide feedback before general availability.

What’s changing
The dashboard:filters module allows your Forge apps to:

• Create custom filters: Build your own set of dashboard filters with custom UI to provide tailored filtering experiences for users.

What you need to do

1. Sign up for the EAP: To participate and access the full documentation, please sign up for the EAP here.

2. Review the documentation: Once enrolled, refer to the module documentation for manifest syntax and implementation details.

3. Provide feedback: Use the feedback channels provided in the EAP welcome materials to share your findings and feature requests.

By signing up for this EAP, you acknowledge that use of the dashboard filters integration is governed by the Atlassian Developer Terms. This feature is considered Early Access Materials as set forth in Section 12 of the terms, and is subject to applicable conditions and disclaimers.

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-149-forge-user-impersonation-fui-addressing-connect-parity-gaps-edge-cases/102987

You can now use display conditions to hide sub-pages or sections in several Jira Forge modules. This allows you to show or hide UI elements based on specific criteria, such as user permissions or project types.

The following modules now support display conditions on their pages and sections child properties:

• jira:adminPage

• jira:globalPage

• jira:projectPage

• jira:projectSettingsPage

• jira:personalSettingsPage

Forge TypeScript bundler, previously available as an EAP, has been removed. Use manual packaging, now available in preview, instead, running your own tsc (or a different compiler).

Manual packaging for Forge functions and UI Kit modules has progressed from the Early Access Program (EAP) to Preview. Manual packaging lets you bypass the fixed version of Webpack bundled within the Forge CLI and upload your code directly from specified directories without modification.

What's changing

Manual packaging is now suitable for production environments, and you no longer need to sign up for the EAP to use it. With manual packaging, you can:

• Use a different compiler or TypeScript version.

• Use alternative bundlers (such as Vite or Esbuild) or no bundler at all.

• Include and call WebAssembly in your application.

• Require data files or depend on packages that do.

• Reduce application size by sharing dependencies across multiple functions.

What you need to do

• If you were already using manual packaging during the EAP, no changes are required.

• To get started, set bundler: manual@2026 and a path in the app.package section of your manifest for functions, or on individual UI Kit resources.

• For details and examples, see Packaging and the Packaging standard.

The rovo:agentConnector module is now Generally Available (GA). This module lets you connect an AI agent hosted outside of Forge to Rovo using the Agent2Agent (A2A) protocol, so your agent can be used alongside native Rovo agents. Only A2A 1.0 is supported.

🛠️ Scheduled maintenance window from September 25 @ 5PM PST to Monday, September 28 @ 10AM, AEST

Our support portal is moving to a new home. New ticket submissions and ticket access including comments via email will be unavailable during this window. Starting September 28, submit all requests at Atlassian Support and update your bookmarks. Learn what's changing.

What’s changing?

In preparation for the upcoming Developer Preview release of Forge Static Macros, access to the early access program (EAP) for this capability is now closed.

We want to thank everyone who participated in the EAP and provided valuable feedback. Your insights have been instrumental in shaping the next phase of Forge Static Macros.

What you need to do

If you are currently participating in the EAP, you can continue to use the feature.

If you missed the EAP, stay tuned to this changelog for the Developer Preview release announcement to start building with Forge Static Macros.

A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-148-local-forge-storage-prototype-for-kvs-and-sql/102858

We’re upgrading Jira dashboards to a more modern and flexible experience. As part of this transition, we’re deprecating the legacy Forge modules for dashboards in favor of these new dashboard modules.

What’s changing
The following Forge modules are now deprecated and will be removed on May 17, 2027:

• jira:dashboardGadget

• jira:dashboardBackgroundScript

These modules are replaced by the new dashboards:widget and dashboards:backgroundScript modules, which are now General Availability (GA). The new modules are designed for the upgraded Jira dashboard surface (also referred to as AVP dashboards).

What you need to do
To ensure your dashboard extensions continue to work on the new Jira dashboard experience, you must migrate your existing modules:

1. Update your app manifest to use the new dashboards:widget and dashboards:backgroundScript modules.

2. Complete your migration before the deprecation date of May 17, 2027 to avoid service disruption for your users.

What’s changing

The new Forge dashboard modules are now generally available (GA). These modules allow you to build extensions for the upgraded Jira dashboard experience, which offers a more modern and flexible interface for users:

• dashboards:widget: Used to create custom content blocks (widgets) on the new dashboard surface.

• dashboards:backgroundScript: Used to run background logic for your dashboard extensions.

The new Jira dashboard experience, which utilizes these modules, is rolling out to customers starting September 23rd, 2026.

What you need to do
You can now start building and deploying apps using these modules for the new Jira dashboard experience:

1. Review the dashboards:widget manifest reference for configuration details and schema.

2. If you have existing dashboard extensions using the legacy jira:dashboardGadget or jira:dashboardBackgroundScript modules, you should begin planning your migration to these new modules.

3. Note that the new dashboard experience coexists with classic Jira dashboards during the rollout period.

What's changing
We are updating how Forge permission checks are implemented in Jira for asApp requests. This internal change simplifies the evaluation process and removes the requirement for permissions to be synced to Jira at installation time.

This update improves the app installation process by reducing the overhead associated with permission synchronization.

What you need to do
No action is required from you. This is an internal implementation change that does not affect how you declare permissions or use asApp in your Forge apps.

The update is being rolled out progressively on a tenant-by-tenant basis.