Repository navigation
Code Mode on Node: a drop-in Executor for CLIs and MCP servers #2689
a-saeedia
started this conversation in
Show and tell
Replies: 1 comment
|
Published on npm: Heads up on the name: npm rejected |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
The runtime docs say the
Executoris replaceable, and the package ships two:DynamicWorkerExecutor(Workers) andIframeSandboxExecutor(browser). Nothing ships for Node, which is where most MCP hosts actually run — and importing the package there is still a problem (#2142).I built the missing third one as a standalone package: a-saeedia/codemode-node (MIT).
How it works. One disposable child process per execution. Code runs in a fresh
vmcontext with norequire,import,processor filesystem; providers are injected as namespaces that proxy tool calls back to the host over IPC, so tool implementations and credentials never leave the parent. The timeout is a hardSIGKILL—vmtimeouts only cover synchronous execution, sowhile (true) await sleep(...)needs a process to kill.Measured, same task both ways on Windows 11 / Node 22, 3 runs median:
codecallCaveats, stated plainly: this is capability isolation, not a security boundary —
node:vmis not a jail, and the host tools really do things (shell, fs, http). It's unofficial and pinned to@cloudflare/codemode@0.5.5, because a minor bump on a Workers-first package can add acloudflare:workersimport that Node can't load. If you're on Workers,DynamicWorkerExecutoris strictly better — use it.Install today from the tarball (npm publish is pending):
--statsprints what your current MCP config costs in schema tokens versus what a singlecodetool costs. Happy to take feedback on the executor shape if anyone wants a different transport.All reactions