Forge invocation token intermittently has empty context (environmentId/siteUrl)

Hi Atlassian Forge Team,

We’re hitting an intermittent authorization failure in our app Charts and Reports for JSM, which we recently migrated to Forge platform in production and have a production blocker as multiple customers are complaining on the feature not working due to Forge invocation token intermittently has empty context.

I have raised ECOHELP-138100 — posting here for visibility, and in case other vendors are seeing the same thing.

What our app does

Our remote (FaaS) endpoint authorizes each request by calling `GET /rest/api/3/mypermissions` with the per-user `appUserToken` (`X-Forge-Oauth-User`) to check our app’s global permission ARI.

The problem

For the same user on the same site, the identical `/mypermissions` call intermittently returns `havePermission:false` (HTTP 200) for a permission the user demonstrably holds. On other invocations the same call returns `true`. Nothing changes on our side between the two —same code, same ARI, same user, same grant.

We traced the difference to the Forge invocation token’s `context`:

  • Failing invocations arrive with an empty context — both `environmentId` and `siteUrl` are blank — and `/mypermissions` comes back all-`false` (including `ADMINISTER`).

  • Succeeding invocations have the context fully populated (`environmentId`, `siteUrl` present) and the same call returns `true`.

Same user 6107ee49…, same site <>.atlassian.net, same ARI. Both HTTP 200.

:white_check_mark: 2026-06-09 11:49:41 UTC atl-traceid 13c095346e5f48cb8e357fbab3e16e0d

 session context   siteUrl: https://<>.atlassian.net   environmentId: 4ebd38ec-d622-483a-84f8-518235c34206 /mypermissions    ari:…/view26-global-permission  HavePermission: true    (ADMINISTER: true)  → access granted

:cross_mark: 2026-06-09 16:32:33 UTC atl-traceid 7bbbf740ec574f1eafd72735a14d8ffc

session context   siteUrl: (empty)  environmentId: (empty)
/mypermissions    ari:…/view26-global-permission  HavePermission: false   (ADMINISTER: false) → access denied

Running the exact ARI manually in the browser as the same user returns `havePermission:true`, confirming the grant is valid — so this is not permission-config issue on the user’s side.

Questions

1. Is there a known issue where Forge invocation tokens are issued with an empty `context` (missing `environmentId`/`siteUrl`) for remote / `appUserToken`calls?

2. Can someone trace the failing vs succeeding `atl-traceid`s above and confirm why `/mypermissions` returns `false` for a user who holds the permission?

3. Any recommended guard on our side until this is resolved?

Tracking ticket: ECOHELP-138100 (full request/response logs attached there).

@ChandanaMeka @PhilipGrove @EkinBukulmez

Thanks!

Ajay

Hi @ajay ,

The team is investigating this issue on the support ticket you raised.

To my knowledge, there are no known limitations or bugs with regards to empty context on the Forge investigation token - we’ll need to investigate the trace IDs you provided to figure out what is going on.

As an immediate workaround, you could explore using offline user impersonation to periodically retrieve a valid user token and caching it remotely, instead of using the one provided on each invocation: https://developer.atlassian.com/platform/forge/remote/calling-product-apis/#offline-user-impersonation

Thanks @HeyJoe for looking into the ticket.. Just to mention that this issue occurs frequently in the jiraServiceManagement:portalUserMenuAction module which calls invokeRemote. So it could be something which is JSM specific

@HeyJoe

Update - I have received a confirmation in ECOHELP-138100 that its a Forge specific issue. I hope we have the issue resolved soon as we have a broken feature in production for our shared customers.