JavaScriptTask has no step budget or timeout — and this window typed the `step()` that would give it one

[sroussey]

What

packages/javascript/src/task/JavaScriptTask.ts:37 is still a bare

const myInterpreter = new Interpreter(`${inputVariablesString} ${code}`);
myInterpreter.run();

run() executes to completion with no instruction budget, no deadline and no AbortSignal check, so while (true) {} in a javascript_code port wedges the thread it runs on — the main thread in the browser build, a worker in node. Six consecutive review cycles (first recorded 2026-08-03; grade held at B− since).

Why now

Two in-repo remedies now exist, both built for neighbouring problems and neither applied here:

1. step() is typed in this repo as of 7fea774. packages/javascript/src/task/interpreter.d.ts:103 declares step(): boolean — "Executes one step. Returns false when there are no more instructions." The vendored interpreter always had it; until this commit it was an implicit any under noImplicitAny, which was the standing excuse. The whole fix is a bounded loop:

const deadline = performance.now() + budgetMs;
let steps = 0;
while (myInterpreter.step()) {
  if (++steps % 10_000 === 0) {
    if (signal?.aborted) throw new TaskAbortedError(...);
    if (performance.now() > deadline) throw new TaskInvalidInputError(...);
  }
}

~10 lines in a 175-line file, with no dependency on the host runtime.

2. packages/tasks/src/util/BoundedRegex.server.ts:37-64 already runs untrusted work under an enforced node:vm timeout and converts an overrun into a TaskInvalidInputError rather than a hang, with the measurements in its docstring. That is the server-side shape if a vm is preferred over the step loop.

The centralised-limits precedent for the constant is packages/util/src/limits.ts (DEFAULT_LIMITS / SECURITY_LIMITS), which already carries the file/regex budgets packages/tasks added.

Why it matters

JavaScriptTask is registered by registerCommonTasks() in every entrypoint, so it is resolvable by type name from graph JSON the host did not author — the same threat model that drove 2cebe68e9 to take the three filesystem tasks out of the ambient registry. A JavaScriptTask node is the one remaining ambient task that accepts attacker-authored code, and it has no stopping condition but the process.

Acceptance

• JavaScriptTask refuses a program that exceeds a configurable step budget or wall-clock deadline, with a typed error rather than a hang.
• The budget is honoured on both entrypoints (browser and node), which the step() loop gets for free and a vm does not.
• A co-located test that runs while(true){} and asserts the task fails within the budget. packages/javascript currently has no tsconfig.test.json and no co-located tests, so this is also the cheapest place to start one.

References

• packages/javascript/src/task/JavaScriptTask.ts:22-48
• packages/javascript/src/task/interpreter.d.ts:101-103 (added 7fea774)
• packages/tasks/src/util/BoundedRegex.server.ts:18-64

Found during the 2026-08-31 review of packages/; standing open since 2026-08-03.

[sroussey]

Still open at origin/main @ fb861bb. Seventh cycle.

$ sed -n '35,38p' packages/javascript/src/task/JavaScriptTask.ts
      const myInterpreter = new Interpreter(`${inputVariablesString} ${code}`);
      myInterpreter.run();

packages/javascript/src moved +53 / −9 this window, all of it in interpreter.d.ts — the same file that already declared the primitive:

$ git diff --stat 9a80450 origin/main -- packages/javascript/src
 packages/javascript/src/task/interpreter.d.ts | 62 +++++++++++++++---

So the type declarations for the interpreter have now been improved twice in a row without the ~10 lines in the 175-line task file that would use them. step(): boolean is still there, still unused.

One thing did change around it: .oxlintrc.json:44-46 now excludes the two vendored files (interpreter.js, acorn.js) from linting with a stated reason — "The ESLint config only ever matched .ts/.tsx, so these were never linted; oxlint reads .js too and reports 31 findings in code this repo does not own." Correct call, and it does not touch this.

---

Generated by Claude Code

[sroussey]

2026-09-14 — eighth cycle, and this time packages/javascript recorded a zero-byte source diff.

$ git diff --numstat fb861bb..HEAD -- packages/javascript/src
(nothing)

$ sed -n '34,40p' packages/javascript/src/task/JavaScriptTask.ts
      const myInterpreter = new Interpreter(`${inputVariablesString} ${code}`);
      myInterpreter.run();

:37 is still a bare run(). The +25/−1 this window shows under packages/javascript is the CHANGELOG and the version bump only — the two windows of interpreter.d.ts improvement that typed step(): boolean in the package's own declarations have now been followed by a window that touched nothing at all.

Unchanged cost: run() on an infinite loop freezes the host thread with no budget and no timeout, in a task whose whole purpose is executing caller-supplied code. The primitive that bounds it is declared in this package's own types; the change is a loop around step() with a step counter and a deadline.

Measured on origin/main @ 2d36880 (0.6.0).

---

Generated by Claude Code