Summary
NodeRuntime.createResidentRunner() / NodeRuntimeResidentRunner.exec() (documented at https://secureexec.dev/docs/features/resident-runner) fails on every single call, regardless of the code snippet's content. Confirmed reproducible on both the latest (0.3.3) and rc (0.3.4-rc.1) npm dist-tags.
Environment
secure-exec versions tested: 0.3.3 (latest) and 0.3.4-rc.1 (rc)- Node.js: v24.18.0
- OS: macOS, darwin-arm64 (
@secure-exec/sidecar-darwin-arm64)
Repro
import { NodeRuntime } from "secure-exec";
const runtime = await NodeRuntime.create();
const runner = await runtime.createResidentRunner();
const result = await runner.exec(`console.log("hello");`);
console.log(result);Expected
Per the docs: "A warm resident evaluation runs in roughly a millisecond" — the snippet should execute successfully (exitCode: 0, stdout containing hello).
Actual
Every call returns exitCode: 1 with the same class of error, e.g.:
{
stdout: '',
stderr: "Error: Cannot resolve module 'data:text/javascript;base64,Y29uc29sZS5sb2coImhlbGxvIik7#0' (imported from '/tmp/secure-exec-program-0.mjs'): not found. For a bare package, ensure it is installed in a node_modules directory on an ancestor of the importer (or bundle the entrypoint). If you mounted a host node_modules, point it at a directory that contains every symlink target (e.g. the workspace root): symlinks that escape the mount root are not followed.\n at /tmp/secure-exec-program-0.mjs:238:65",
exitCode: 1
}
This happens for:
- The same snippet repeated 5x in a row
- 5 distinct/unique snippets in a row
- A trivial
globalThis.counter++-style state test
i.e. it's not content-dependent — every single exec() call on a resident runner fails the same way.
Suspected root cause
The resident runner appears to work by running a small REPL-style loop inside the guest that evaluates each submitted snippet via a dynamic import() of a data:text/javascript;base64,... URL. The guest's module resolver doesn't seem to recognize the data: URL scheme as a special case — the error message ("ensure it is installed in a node_modules directory... ") reads like the resolver is falling through to its bare-specifier/node_modules lookup path instead of treating it as an inline module to evaluate directly. This would explain why the failure is 100% reproducible and independent of the snippet's content.
Given it reproduces identically on both 0.3.3 and 0.3.4-rc.1, this doesn't look like something recently fixed on the rc line.
Impact
This blocks the documented "trusted, repeated evaluation" use case (REPLs, eval loops, per-tenant persistent runtime reuse) that createResidentRunner() is specifically meant for — right now it's unusable for any real workload since 100% of calls fail.
Happy to provide more repro details/logs if useful.
Summary
NodeRuntime.createResidentRunner()/NodeRuntimeResidentRunner.exec()(documented at https://secureexec.dev/docs/features/resident-runner) fails on every single call, regardless of the code snippet's content. Confirmed reproducible on both thelatest(0.3.3) andrc(0.3.4-rc.1) npm dist-tags.Environment
secure-execversions tested:0.3.3(latest) and0.3.4-rc.1(rc)@secure-exec/sidecar-darwin-arm64)Repro
Expected
Per the docs: "A warm resident evaluation runs in roughly a millisecond" — the snippet should execute successfully (
exitCode: 0,stdoutcontaininghello).Actual
Every call returns
exitCode: 1with the same class of error, e.g.:This happens for:
globalThis.counter++-style state testi.e. it's not content-dependent — every single
exec()call on a resident runner fails the same way.Suspected root cause
The resident runner appears to work by running a small REPL-style loop inside the guest that evaluates each submitted snippet via a dynamic
import()of adata:text/javascript;base64,...URL. The guest's module resolver doesn't seem to recognize thedata:URL scheme as a special case — the error message ("ensure it is installed in a node_modules directory... ") reads like the resolver is falling through to its bare-specifier/node_modules lookup path instead of treating it as an inline module to evaluate directly. This would explain why the failure is 100% reproducible and independent of the snippet's content.Given it reproduces identically on both
0.3.3and0.3.4-rc.1, this doesn't look like something recently fixed on thercline.Impact
This blocks the documented "trusted, repeated evaluation" use case (REPLs, eval loops, per-tenant persistent runtime reuse) that
createResidentRunner()is specifically meant for — right now it's unusable for any real workload since 100% of calls fail.Happy to provide more repro details/logs if useful.