Skip to main content

The Sandbox

Every AutessaScript execution runs in a fresh context inside a hardened, sandboxed JavaScript engine. The sandbox gives you the full modern ECMAScript language — and deliberately nothing else. This page describes exactly what the sandbox allows, what fails, and how output is captured.

Execution model: synchronous only​

A script is evaluated once, top to bottom, on a single thread. When the last statement finishes, the platform reads whatever you passed to response.setResponse(...) and the execution is over. There is no event loop, no timers, and no background work:

  • setTimeout, setInterval, fetch, XMLHttpRequest are not defined. Calling any of them throws a ReferenceError — they are browser/Node APIs and no host provides them here.
  • require, process, fs, path, window, document are not defined either. There is no module system; everything you need is already bound as a global.
  • Top-level await is a syntax error. The engine reports await is only valid in async functions, and the script fails before running at all.
  • Promise exists as ECMAScript syntax, but nothing can resolve one asynchronously. With no timers and no async I/O, a .then(...) callback has nothing to wait on — promise-style code either never settles or adds confusion for no benefit. Write straight-line code.

The helpers are the flip side of this design: api.get(...), llm.invoke(...), and tools.invokeById(...) are blocking Java calls. They pause the script until the HTTP response, LLM completion, or tool result comes back, then return it as a plain string. No callbacks, no await — just assignment:

// This blocks until the request completes, then continues.
const raw = api.get(JSON.stringify({ endpoint: "https://api.example.com/status" }));
const result = JSON.parse(raw);
console.log("status code:", result.statusCode);
response.setResponse(result.body);

What the sandbox blocks​

The sandbox context is created with every escape hatch disabled:

  • No Java interop. Host class lookup is off, so Java.type(...) and any reflection into the JVM fail. Only methods explicitly exported on the helper objects are callable.
  • No filesystem. File I/O is disabled at the engine level.
  • No process or thread creation. Scripts cannot spawn processes or threads.
  • No native code. Native access is disabled.
  • No environment variables. The engine cannot read the host's environment. The platform passes context to your script exclusively through the variables binding (including platform values like AUTESSA_COMPANY_ID).
  • No network — except through api.*. The API helper is the only way to make HTTP requests, and every URL is validated before the request is sent: requests to private networks, internal infrastructure, and non-HTTP(S) schemes are rejected with a validation error.

ECMAScript surface​

The language itself is fully modern: let/const, arrow functions, template literals, destructuring, spread, classes, Map/Set, JSON, RegExp, Math, Date, and the standard string/array methods all work as you'd expect. What's missing is the host environment (browser or Node APIs), not the language.

const rows = JSON.parse(variables.get("payload"))
  .filter(r => r.active)
  .map(({ id, name }) => `${id}: ${name.toUpperCase()}`);

response.setResponse(rows.join("\n"));

Determinism​

Prefer deterministic scripts: same inputs, same output. Date.now(), Math.random(), and mathUtils.random() are available but make results irreproducible, which matters most in computed columns — a column recomputed on the next row update should not silently change value when its inputs didn't. Nondeterminism is fine when it's the point (jitter, sampling, request IDs); just keep it out of logic that other columns or tools depend on.

Console output and execution logs​

Everything you write via console.log/info/warn/error/debug is captured into the execution's log list with a timestamp and level, e.g. [2026-07-01 14:02:11.482] [INFO] parsed 12 rows. Logs are returned alongside the result as the execution's debugging info, and they are your primary debugging tool — see Limits and errors for the workflow.

Two extra capture channels exist for completeness: anything written directly to the engine's stdout/stderr streams is appended to the logs as [OUTPUT] ... or [ERROR] ... entries. Stick to console.*; it's timestamped and leveled.

If your script throws, the platform's wrapper logs the error's stack trace via console.error before failing the execution — so the logs always contain the failure point, even for uncaught exceptions.