permissions: { network: "allow" } authorizes egress but guest fetch() hangs — no host network adapter on public API

[NathanFlurry]

Summary

Granting permissions: { network: "allow" } via the public NodeRuntime.create API authorizes guest network access, but there is no way through the public SDK to provide a host network adapter to actually service outbound requests. As a result, an outbound fetch() in guest code hangs indefinitely instead of either succeeding or failing fast.

The quickstart's Permissions Configuration section implies network: "allow" is sufficient to enable network, so this is misleading as written.

Environment

• secure-exec@0.3.0 / @secure-exec/core@0.3.0
• Node.js v24.13.0, Linux

Repro

import { NodeRuntime } from "secure-exec";

const rt = await NodeRuntime.create({ permissions: { network: "allow" } });
const r = await Promise.race([
  rt.run(`
    try { const res = await fetch("https://example.com"); __return({ status: res.status }); }
    catch (e) { __return({ err: String(e.message || e) }); }
  `),
  new Promise((res) => setTimeout(() => res({ value: { TIMEOUT_10s: true } }), 10000)),
]);
console.log("result:", r.value); // -> { TIMEOUT_10s: true }  (hangs until the race timer fires)
await rt.dispose();

Observed: the guest fetch never resolves — bounded to a 10s race, it times out at exactly 10s every time.

Control checks:

• A host-side fetch("https://example.com") returns 200 in the same environment, so host egress is not the problem.
• The default deny path works correctly and fails fast: without the permission, the guest fetch rejects promptly with fetch failed.

So the issue is specific to the network: "allow" + outbound-request path hanging rather than completing.

Root cause (from reading the type defs)

Granting the permission only authorizes network; performing it requires a host network adapter. The architecture clearly expects one — @secure-exec/core's test-runtime defines createNodeHostNetworkAdapter(), createDefaultNetworkAdapter(), a NetworkAdapter interface, and hasHostNetworkAdapter().

However:

• test-runtime is not re-exported from @secure-exec/core's index.d.ts, and the public secure-exec package only re-exports NodeRuntime + types.
• NodeRuntimeCreateOptions has no field to supply a network adapter (only permissions, env, cwd, commandsDir, files, mounts, nodeModules, tools, loopbackExemptPorts).

So through the public API there is no way to wire egress, and network: "allow" ends up granting permission with no transport behind it.

Suggested fix (either)

1. Expose a host network adapter on NodeRuntimeCreateOptions (e.g. network / networkAdapter), and document it in the quickstart, or
2. Make network: "allow" with no available adapter reject fast with a clear error (e.g. "network permitted but no host network adapter configured") instead of hanging.

Either way, the quickstart's Permissions section should clarify whether outbound HTTP is supported on the public SDK in 0.3.0 and, if so, the complete setup required.

Minor doc nit

The quickstart code uses .run<{...}>(...) (TS generics) and the package is "type": "module", but doesn't mention that a .js file in a CommonJS project won't load it — it needs .mjs or "type": "module". Worth a one-line note for JS users following along.