How Scriptbox Works

How Scriptbox Works

Scriptbox runs TypeScript you write against your Jira Cloud site, entirely on Atlassian infrastructure. You write a script in the browser console, press Run, and it executes inside a WebAssembly JavaScript VM that lives in the app's own Forge function. It talks to Jira through the platform's REST client — no servers, no egress, nothing to host.

At its core, Scriptbox is built to answer three questions every Jira admin asks before trusting a scripting tool:

  • Where does my script actually run — and who else can see the data it touches?
  • What can a script reach, and what is it stopped from reaching?
  • When a script misbehaves, how do I find out what it did?
Scriptbox console with the Starter script in the editor and its JSON result below

Script console with a script and its result

## From the editor to Jira and back

A run takes the same path every time, whichever trigger started it:

  1. You write TypeScript in the console editor, with autocomplete for every reachable Jira endpoint.
  2. Types are stripped, not checked. The source is transpiled to plain JavaScript (by sucrase). A type error is still a runtime error — see Sandbox Globals.
  3. A fresh QuickJS VM starts for this run with its own heap and its own global object. Nothing carries over from the last run.
  4. The script calls jira.*. Each call leaves the VM as JSON, is checked against a path allowlist on the host, has any auth headers stripped, and is sent to your site with platform-supplied credentials.
  5. The result, logs and statistics come back to the Result and Logs tabs, and the run is recorded in the script's history.

What the sandbox removes

The script never runs in Node. Inside the VM there is no process, no require, no fetch, no sockets and no timers into the host. The only two functions that bridge out are captured into closures and deleted from globalThis before your code starts. Every value that crosses the boundary is JSON.

That design does three jobs at once:

  • Isolation → a script cannot stash data in a reused Forge container, because it cannot reach the container's globals.
  • Control → QuickJS gives a memory cap, a stack cap and an interrupt handler, so while (true) {} dies at the deadline rather than burning the whole invocation. See Limits per Run.
  • Review → the app's own code contains no eval and no new Function; your script is data handed to an interpreter.

One engine, many triggers

The same engine runs every script, no matter what starts it. The console is one trigger; the others are covered under Running Scripts Automatically:

  • Event listeners → a Jira event (issue created, commented, worklog added…) runs a saved script.
  • Scheduled jobs → a cron expression and a timezone run a saved script, near the stated time.
  • Scripted fields → a read-only Jira custom field whose value a script computes for a batch of issues.
  • Behaviours → a script changes the issue form while someone fills it in. This one runs the same QuickJS engine in the browser, not on the server.
  • Workflow rules → post functions, script validators, and Jira expression validators and conditions.
  • Jira Automation → a "Run a Scriptbox script" action step inside an automation rule.

Every trigger except the console runs without a person behind it, so those runs use the app's identity, not yours. Run As Me or As the App explains what that means for what a script can see and change.

Who can use it

Scriptbox is a tool for Jira site administrators. Every server-side function behind the console checks that the caller holds Jira's ADMINISTER permission before doing anything, and the Apps-menu entry is only shown to those users. See Permissions and Admin Access.