Permissions and Admin Access

Scriptbox is a tool for Jira site administrators. This page lists who can reach which part of it, and every scope the app holds, with the reason it is there. Scopes are the ceiling: no script, run as anyone, can exceed them.

Who can use Scriptbox

The admin gate. Every server-side function behind the console — scripts, runs, listeners, jobs, fields, behaviours, workflow-rule configuration, variables, migration and the Rovo assistant's actions — first checks that the caller holds Jira's global ADMINISTER permission. This is checked for the calling user on every call; page visibility is not a permission model.
The Apps menu entry is shown only to users with ADMINISTER, so it does not advertise a page that would only greet a non-admin with an error. This is Jira's Administer Jira permission, not Atlassian's organisation-admin role.
No separate roles. Every Jira site admin can write, run, save, delete and schedule scripts, manage variables, and run scripts as the app.

Two entry points run without the admin check, and you should know them:

Entry point	Who can reach it	What to know
Run a Scriptbox script automation action	Anyone who can author an automation rule that offers the step	Runs any saved script as the app, found by name. See the caution on Jira Automation Action.
Behaviour run log	Any user who opens a form with a behaviour	The behaviour frame reports each run from the user's browser. Treat behaviour execution-log entries as client-reported.

Scopes the app holds

Scope	Why it is there
`read:jira-work`	Read issues, projects, comments, worklogs and search results — what most scripts do
`write:jira-work`	Create and edit issues, comments, worklogs and transitions from scripts
`read:jira-user`	Look up users — assignees, reporters, account details
`manage:jira-project`	Project administration from scripts — versions, components, project settings. Scriptbox's own code does not use it
`manage:jira-configuration`	Workflows, screens, custom fields and UI modifications. Scriptbox itself uses it to create scripted fields, list where its workflow rules are used, and publish behaviours; scripts can use it too
`read:board-scope:jira-software`, `read:board-scope.admin:jira-software`, `read:sprint:jira-software`, `read:epic:jira-software`, `read:issue:jira-software`, `read:issue-details:jira`, `read:jql:jira`, `read:project:jira`	Read-only access to the Jira Software (Agile) API — boards, board configuration, sprints, epics and their issues
`storage:app`	Scripts, versions, run history, execution logs, configuration and per-script storage

manage:jira-configuration and manage:jira-project are broad. Together with app-identity runs, they put a script running as the app close to a site administrator in what it can change. That is what makes a general-purpose script runner useful — and why who can save scripts, and which ones stay saved, matters.

Deliberately not requested

No egress. No external fetch permissions — the app and its scripts cannot call anything outside your site.
No Agile write scopes. Board, sprint and epic writes are refused.
No Jira Service Management scopes. jira.serviceDesk calls are currently refused by Jira.
No devops scopes (builds, deployments, feature flags, dev info).

Other manifest permissions

The app's Custom UI pages are served with unsafe-eval for scripts — needed so the behaviours frame can start its WebAssembly interpreter, and applied by Forge to all of the app's pages — and unsafe-inline for styles, which the code editor uses. See Security Model.