Code tool cannot start under Deno 2.9: @valtown/deno-http-worker is pinned to ^0.0.21

[stex]

Hey!

I tried to switch from using the connector through claude.ai in favour of a local version with claude code and ran into this problem on my machine. The below data is from claude, but I verified that the version bump actually fixes it.

I can create a PR for this if you'd like.

Thanks a lot!

---

What happens

With --code-execution-mode=local, every execute call fails with Deno exited before being ready. The message does not say what went wrong. Running the spawn by hand reproduces the real error:

NotCapable: Requires read access to "/tmp/<random>.sock", run again with the --allow-read flag
    at listen (ext:deno_net/01_net.js)
    at Object.serve (ext:deno_http/00_serve.ts)

The bootstrap opens its Unix socket via Deno.serve({ path: socketFile }). @valtown/deno-http-worker@0.0.21 passes --allow-write for that socket and an --allow-read covering only the module paths. Deno 2.9 needs read access on the socket file as well, so the subprocess dies before it can signal readiness.

Why it surfaces here

The fix already exists upstream. val-town/deno-http-worker added it on 2026-08-28 in „Add the unix socket to --allow-net for Deno 2.9.x compatibility" (#138), and current code puts the socket into both --allow-read and --allow-net=unix:.

It never reaches users of this package, because openregister-mcp@4.8.2 declares "@valtown/deno-http-worker": "^0.0.21". A caret range on a 0.0.x version allows patch bumps only, so npm keeps installing 0.0.21 while the current release is 3.0.0.

Reproduction

1. Deno 2.9.7, Node 22, openregister-mcp@4.8.2
2. Start with --code-execution-mode=local
3. Call execute with any snippet

Workaround

Installing the package with an override works, verified against live API calls:

{
  "dependencies": { "openregister-mcp": "^4.8.2" },
  "overrides": { "@valtown/deno-http-worker": "^3.0.0" }
}

Suggestion

Bump the dependency. Two smaller things would have saved a lot of digging here, if you want them:

• Surface the subprocess stderr in the error the tool returns. EarlyExitDenoHTTPWorkerError already carries it, but Deno exited before being ready is what reaches the caller.
• The server starts cleanly and lists both tools even when code execution cannot work at all, so a successful start is not a signal that anything runs.