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.
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
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