Changelog

A new --debugHost (or -d) option has been added to the Forge CLI tunnel debugger. This allows you to start the debugger at any valid IPv4 or IPv6 address, providing more flexibility for your local development environment.

What's changing

• You can now specify a custom host for the tunnel debugger using the --debugHost or -d flag.

• If no host is specified, the debugger will default to localhost (127.0.0.1).

What you need to do

• Update your Forge CLI to the latest version to access this feature.

• To start the debugger at a specific address, use the following command:
  forge tunnel --debugHost <address>

• For more information on debugging Forge apps, refer to the Tunneling documentation.

The Forge CLI now includes a new forge module command group (in Preview) for adding modules to an existing app — and for discovering and inspecting the modules you can add — directly from the command line.

What's changing

Previously, adding a module to an existing app meant editing your manifest.yml and creating the source files yourself. The new forge module command group gives you three subcommands to do this from the command line:

• forge module add — add a module to your app. The command guides you through choosing a module and UI framework (UI Kit or custom UI), then generates the source files, updates your manifest.yml, and installs any required dependencies. Use --dry-run to preview the changes first.

• forge module list — browse the available module templates, filterable by product, UI framework, or module key.

• forge module show <moduleType> — view the details and documentation for a specific module.

Why this matters

• Faster setup: scaffold a new module in seconds instead of wiring up the manifest, files, and dependencies by hand.

• Safer changes: forge module add runs key-collision and file-conflict checks before writing anything, and --dry-run lets you preview first.

• Efficient resource usage: modules are bundled using multi-entry resource bundles.

Key details

• forge module add extends an app you already have. To scaffold a brand-new app from a template, use forge create instead.

• The manifest and resources that forge module add generates are built on multi-entry resource bundles, a Preview feature.

• Custom UI modules are scaffolded with a Vite-based build setup.

• These commands are in Preview and may modify your app files (manifest.yml, source files, and package.json). We recommend committing your work beforehand.

• Only a subset of Forge modules is available today, and we're adding more over time.

Support for Claude Sonnet 4.6 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here

What's changing
The legacy storage module has been removed from the @forge/api package. This follows the deprecation notice issued in Dec 1, 2025.

Starting today, any apps still using import { storage } from '@forge/api' will fail to build or run, as this export is no longer available.

What you need to do
If your app still uses the legacy storage module, you must migrate to the @forge/kvs package immediately to avoid service disruption.

• Install the @forge/kvs package: npm install @forge/kvs

• Update your imports from import { storage } from '@forge/api' to import { storage } from '@forge/kvs'

• Deploy the updated version of your app.

For detailed instructions, refer to the KVS migration guide. You can also use the Forge CLI linting tool to identify any remaining references to the deprecated module.

Forge packages now ship TypeScript 5-compatible type declarations and declare an optional peer dependency on typescript >= 5.0.0.

What's changing

• TypeScript 4 compatibility is not guaranteed in future releases.

• An optional peer dependency on typescript >= 5.0.0 has been added to each package.

What you need to do

If you use TypeScript, and want to use the latest Forge package versions, upgrade to TypeScript 5:

1. In your project, run: npm install typescript@^5.0.0 --save-dev

2. Update your Forge package dependencies to the latest major version.

3. Review your tsconfig.json for any TypeScript 5-specific settings you may want to enable.

4. Re-build and test your app.

Forge Object Store and front-end `useObjectStore` hook is now available in Preview. Forge Object Store EAP is now closed.

The Preview release provides improvements to pre-signed links and adds CDN support. The service will be available to all developers as a billable capability, starting on Jul 1, 2026.

Please review the available documentation, ‘useObjectStore’ documentation and pricing information to get started with Forge Object Store, including assessing all of the current limitations of the service.

Following the deprecation announcement last year, access to the old workflow editor will be removed for all customers starting July 13, 2026.

What you need to do

• Review your apps: If you own workflow-related apps, ensure your rules provide a high quality experience in the new editor.

• Implement rule descriptions: We recommend providing dynamic configuration descriptions for Forge and Connect workflow rules. This helps admins understand your app's rules at a glance within the new editor.

• Test and report issues: If you encounter any behavior issues in the new workflow editor, please raise a support ticket.

For more details refer to the community announcement.

The Developer Space Insights dashboard gives you an aggregated view of log volume, errors, alerts, performance, and cost data across your Forge apps — helping you quickly identify which apps need attention.

Access it by selecting Insights from the navigation menu in your Developer Space. The dashboard includes seven charts (showing top 3 apps where applicable), and clicking any app in a chart takes you directly to its relevant monitoring view:

• Log volume by level – Total log lines broken down by log level (INFO, WARN, ERROR, DEBUG).

• Apps by error log volume – Apps ranked by error log count.

• Open alerts by app – Apps with currently open alerts.

• Apps by invocation errors – Apps ranked by invocation errors.

• Apps by latency – Apps ranked by response latency.

• Apps by invocation count – Apps ranked by invocation count.

• Top apps by resource usage – Apps ranked by Forge usage based cost.

All Developer Space roles (Admin, Developer, and Viewer) can access the Insights dashboard. For more information, see Developer Space Insights dashboard.

• New skill: forge-cost-optimizer – Analyzes your Forge app's resource usage and recommends optimizations to reduce invocation costs.

• New skill: forge-security-review – Performs automated security checks against common vulnerabilities and Atlassian best practices before deployment.

• New skill: forge-connector – Helps scaffold and configure connections between Forge apps and external services.

• Updated: forge-app-review – Now provides a lightweight release-readiness review covering permissions, manifest hygiene, and common deployment blockers.

• Codex support – Added Codex as an installation option for the plugin and individual skills.

• If you're using the Forge AI Plugin, update to the latest version to access the new cost optimizer and security review features.

• To install via Codex, follow the new Codex installation steps in the relevant skill or plugin docs.

We’ve released a preview of new modal sizing capabilities, giving you more control over how your app's modals appear and behave.

• Custom pixel sizes: You can now pass specific width and height values in pixels to define the exact dimensions of your modal.

• Runtime resizing: You can enable dynamic resizing by adding viewportSize: resizable to modal extension points in your manifest, or by passing resizable to the size prop in UI Kit and @forge/bridge modal.

What you need to do
As this feature is currently in preview, we encourage you to test these new configurations in your development environments:

1. For extension points: Update your manifest.yml to include the viewportSize: resizable attribute or viewportSize: { width, height } for relevant modules.

2. For UI Kit or Bridge: Update your modal calls to use supported css string values for width and height, or set the size prop to resizable.

For detailed implementation details, refer to the updated documentation:

• https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/modal/#modal

• https://developer.atlassian.com/platform/forge/ui-kit/components/modal/

• https://developer.atlassian.com/platform/forge/manifest-reference/modules/

We've introduced a structured process for partners and Atlassian to jointly investigate security incidents affecting your app or the customer data it handles.

What's changing

• Log sharing for Forge apps: Atlassian can now share incident-scoped platform logs and app telemetry with you during an investigation. This provides the data you need to diagnose and resolve issues faster.

• A single reporting path: You can now report security incidents through the new developer support portal form. This form serves as the shared record for both you and Atlassian.

What you need to do

• Review the program overview page to understand eligibility and support levels.

• Ensure your security contact information is up to date in the partner account to ensure you are ready before an incident occurs.

Forge SQL now inspects every query submitted by your app before it reaches the database. Queries that contain restricted functions, statements, or syntax are rejected with a new SQL_POLICY_VIOLATION error code before execution.

We’ve implemented this new policy to enforce the following:

• Stricter compliance with standard ANSI SQL syntax.

• Pre-emptive protection against SQL-based resource exhaustion and exploits.

• Stable, predictable performance across all Forge apps using SQL storage.

New error code: SQL_POLICY_VIOLATION

If your app submits a query that uses a restricted function or pattern, the @forge/sql package will return an error with a code, message, and suggestion field to help you resolve the violation.

Restricted functions and statements

The following are now monitored and may trigger rejection:

• Functions: SLEEP(), BENCHMARK(), COMPRESS(), UNCOMPRESS(), AES_ENCRYPT(), AES_DECRYPT(), SHA2()

• Statements: ALTER USER, LOCK TABLES, USE <table>

• Patterns: Unsupported optimizer hints, SET GLOBAL/SET INSTANCE, most SHOW statements, SQL-level PREPARE/EXECUTE/DEALLOCATE PREPARE, and multi-statement queries.

A subset of SET, SHOW, USE and optimizer hints remain permitted. See the SQL query policy documentation for the full allowlist.

What you need to do

• Review your queries: If your app uses any restricted functions or syntax patterns, those queries will now be rejected at runtime.

• Update error handling: Check for errorCodes.SQL_POLICY_VIOLATION alongside existing error codes to handle rejections gracefully.

If your app requires a restricted function for a valid use case, request an exemption through the Developer Support portal with your app.id, the query, and the use case.

We’re enhancing the jira:uiModifications module to support interactions with different user types in Jira.

Apps with UI Modifications that need to work for anonymous users must explicitly declare this in the app manifest using the unlicensedAccess attribute.

This change will take effect on Jun 29, 2026. We recommend that you deploy an update to your app before this date to avoid any interruption to your app’s functionality for anonymous users.

Add the anonymous value to the unlicensedAccess attribute for each jira:uiModificationsmodule that needs to execute for anonymous users in Jira.

For more information, see the guide on Access to Forge apps for unlicensed users.

From Monday Jun 29, 2026 onwards, UI Modifications modules will not be executed for anonymous users unless the module explicitly declares it.

You can now configure product event triggers and scheduled triggers to skip invocations for installations where your app is not actively licensed.

What's changing

By adding the appIsLicensed filter to your trigger modules in manifest.yml, the Forge platform will block trigger invocations for installations where the app's license is already inactive. This helps reduce unnecessary compute usage for unlicensed installations.

This change is specifically designed to address apps with existing inactive licenses (e.g., legacy entitlements that have lapsed). It is separate from the broader platform app suspension behaviour being explored in https://community.developer.atlassian.com/t/rfc-137-forge-app-suspension-behaviour/101092, which covers future suspension lifecycle handling.

This is an opt-in feature. Existing triggers are unaffected unless you explicitly add the filter to your manifest.

What you need to do

To enable this filtering, update your manifest.yml by adding the appIsLicensed: true filter to your trigger modules:

• Open your manifest.yml file

• Locate your trigger or scheduledTrigger modules

• Add the filter property with appIsLicensed: true

For more information, see the https://developer.atlassian.com/platform/forge/manifest-reference/modules/trigger/#filter-reference and https://developer.atlassian.com/platform/forge/manifest-reference/modules/scheduled-trigger/#filter-reference.

What’s changing
You can now enable guest access for the following Jira Forge modules:

• jira:customField

• jira:customFieldType

• jira:issuePanel

This update allows your apps to run for unlicensed users (guests) who have been invited to a single Jira space. By default, Forge apps only run for licensed Jira and Jira Service Management users.

What you need to do
To allow your app to serve unlicensed and guest users, add the unlicensedAccess property to the relevant modules in your manifest.yml file.

For detailed implementation steps, refer to the guide for unlicensed users.