TypeError: "InspectorProxyWorker" worker not found (miniflare/dist/src/index.js)

[tforster]

What versions & operating system are you using?

System: OS: Linux 6.6 Ubuntu 22.04.5 LTS 22.04.5 LTS (Jammy Jellyfish) CPU: (16) x64 13th Gen Intel(R) Core(TM) i7-13620H Memory: 9.12 GB / 15.50 GB Container: Yes Shell: 5.8.1 - /usr/bin/zsh Binaries: Node: 23.11.0 - ~/.nvm/versions/node/v23.11.0/bin/node npm: 10.9.2 - ~/.nvm/versions/node/v23.11.0/bin/npm pnpm: 10.12.2 - ~/.local/share/pnpm/pnpm npmPackages: @cloudflare/vitest-pool-workers: ^0.8.19 => 0.8.64 wrangler: ^4.30.0 => 4.30.0

Note: This setup is Windows 11 running Ubuntu in WSL2. VSCode is installed in Windows, and all dev tooling, including Node, Wrangler, etc, are in a WSL2 folder. This has been a solid environment for many years. I have also tested on a Core i5 Asus Chromebook in developer mode using Google's official Debian VM, also solid for several years, and it too exhibits the same new behaviour.

Please provide a link to a minimal reproduction

No link but the following steps will help

1. Run npx wrangler init new-debug-test
2. Hello World example
3. Worker only
4. JavaScript
5. No
6. No
7. Set a breakpoint in the src/index.js file

Describe the Bug

Before Wrangler 4.23, I was using VSCode debugging extensively without issue. From 4.23 onward, debugging no longer works in VSCode.

Downgrading to anything < 4.23 consistently works, and upgrading to anything => 4.23 consistently does not.

The debugger appears to attach if I use a launch config, but breakpoints are not hit. If I skip the launch config and run in a JavaScript Debug Terminal, then the debugger appears to connect, in that I have a session badge on the Run and Debug icon in the left sidebar, but breakpoints are grey circles, not red, and breakpoints are not hit.

If I configure my breakpoints panel to break on Caught Exceptions then it breaks on throw new TypeError(${JSON.stringify(workerName)} worker not found); on line 60606 of node_modules/miniflare/dist/src/index.js

Please provide any relevant error logs

Exception has occurred: TypeError: "InspectorProxyWorker" worker not found at #findAndAssertWorkerIndex (/home/tforster/TroyForster/abc/new-debug-test/node_modules/miniflare/dist/src/index.js:60606:15) at _Miniflare.unsafeGetDirectURL (/home/tforster/TroyForster/abc/new-debug-test/node_modules/miniflare/dist/src/index.js:60490:55) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async ProxyController.reconnectInspectorProxyWorker (/home/tforster/TroyForster/abc/new-debug-test/node_modules/wrangler/wrangler-dist/cli.js:178640:43) at async ProxyController.sendMessageToInspectorProxyWorker (/home/tforster/TroyForster/abc/new-debug-test/node_modules/wrangler/wrangler-dist/cli.js:178723:29)

[emily-shen]

I'm not able to reproduce this :/

this is my launch.json

{
  "configurations": [
    {
  "name": "Wrangler",
  "type": "node",
  "request": "attach",
  "port": 9229,
  "cwd": "/",
  "resolveSourceMapLocations": null,
  "attachExistingChildren": false,
  "autoAttachChildProcesses": false
    }
  ]
}

I'm using windows, ran npx [email protected] dev from WSL inside of vscode, and then started a debug session which then hits the breakpoint as expected. Is there anything different there from what you're doing?

[tforster]

@emily-shen I am using the same launch.json. I even copied yours over mine. It works perfectly with Wrangler 4.22. But as soon as I upgrade Wrangler to 4.23 and above (I just tried with the latest 4.31.0), it no longer works. My code still executes, but the debugger breakpoints are not hit. Interestingly, the Run and Debug toolbar indicates that the debugger is connected, and I even see the Debugger attached messages when I first start the app from the JavaScript Debug Terminal. If I stop and restart the debugger from Run and Debug while the app is running, it fails to connect.

I am still getting the TypeError: "InspectorProxyWorker" worker not found exception from Miniflare. And, I have created a completely new project with npm create cloudflare@latest

If it helps, the behaviour is the same with Node 23.11.0 as well as 22.18.0 (LTS). I am managing Node with nvm.

[tforster]

Additionally, I have uninstalled nvm, removed all node versions, and removed my .~/.config/.wrangler folder, installed Volta, installed a single fresh LTS version of Node, re-ran npx wrangler dev and still have the same issue. I added some debugging code around the line that throws the exception, and got

[Miniflare debug] worker not found { requested: 'InspectorProxyWorker', available: [ 'ProxyWorker' ] }

I hope this info helps.

[tforster]

Also, this behaviour is consistent on my Windows 11 + WSL2 machine as well as my Chromebook running Google's official Debian-based VM. I have an Ubuntu laptop that I will fire up shortly to test on too.

[tforster]

@emily-shen Do you need anything else from me at this time?

[seiichi1101]

Hi,

I’m experiencing the same issue on Pop!_OS 22.04.

OS: Pop!_OS 22.04 LTS
CPU: AMD® Ryzen 9 8945hs w/ radeon 780m graphics × 16
Memory: 96.0 GiB
Container: No
Shell: version 5.1.16(1)-release (x86_64-pc-linux-gnu) - /usr/bin/bash
Binaries:
Node: 20.17.0
npm: 10.8.2

[tforster]

@emily-shen What Linux distro are you running in WSL? I am running Ubuntu. I also get the same issue on another device running Debian Trixie, and I see @seiichi1101 is using a Debian-based distro too.

[vicb]

@penalosa do you have any idea of what could go wrong here? (I think you worked on some debug things recently and might have some idea).

[tforster]

Is there anything I can do to help move this bug along?

[tforster]

I have been on an AWS project for the last couple of months, but now switching to a Cloudflare project. I have rebuilt my Debian environment from a clean Bookworm, but I see the issue has not been resolved, and I continue to be stuck on 4.22.

Is there any ETA for a resolution? Is there any known workaround apart from pinning Wrangler to 4.22?

[petebacondarwin]

I'm afraid I can't get Wrangler to show the devtools window at all in WSL on my Windows machine, on any version of Wrangler!

I followed your description above and can run npx wrangler dev in my new project. It shows this

╭──────────────────────────────────────────────────────────────────────╮
│  [b] open a browser [d] open devtools [c] clear console [x] to exit  │
╰──────────────────────────────────────────────────────────────────────╯

And if I press B it will open a browser and hit the Worker. But if I press D it does nothing. Moreover if I hard code a debugger; statement into the Worker before the return statement then a request to the Worker just hangs, which I assume is because workerd is pausing on the breakpoint. But I can't find a way to connect to the debugger.

But I accept that I don't really know how to setup nor use WSL. So there is probably something else I am doing wrong here. I'll have to pair with a colleague in the office tomorrow to see if we can reproduce this.

I have always just run Wrangler directly in Windows and that works well for me. Is this not an option for you?

[tforster]

@petebacondarwin win The devtools option has never worked from WSL. I looked at the source code for it a couple of years ago, and it appeared to be a pretty simple fix, but by then, VSCode debugging was working, so I did not go any deeper.

[penalosa]

@tforster I'm afraid we've not been able to properly reproduce this. Would you be able to step us through the steps you're taking so that we can try and fix it? In particular, the specific order in which you're starting VSCode debug sessions, how you're opening terminals in VSCode etc...

If possible, a screen recording would be really helpful—if you don't want it to be public you can email it to me at [email protected].

[tforster]

@penalosa Here's a screen recording. This was taken on a Chromebook running a fresh install of Google's Debian Bookworm dev environment. But the process and behaviour are identical to my main workstation running Windows 11 with WSL2. I can do a screen record from there if you need it, but it will look the same.

Note that wrangler 4.2 and earlier work flawlessly, and the debugger attaches almost instantly. But after the introduction of 4.3, the debugger times out before it ever attaches.

https://github.com/user-attachments/assets/ae2d6650-1c4e-4dea-848e-e5146a65a5fa

[petebacondarwin]

OK so the problem you are seeing appears to be caused by this PR - https://github.com/cloudflare/workers-sdk/pull/9535.

In that PR you can see that we turn off lots of stuff (e.g. inspector proxy server etc) when we determine that we are running in the VS Code JS debug terminal. But notably when we determine this to be the case we also hide the [d] Dev Tools option from the menu.

I can see in your screen recording that this option is not being displayed which means that we are (incorrectly?) determining that it is being run in a VS Code JS debug terminal. And that is probably why things have stopped working.

Can you try running Wrangler from a terminal that is not hosted by VS Code? Does it display the [d] DevTools menu option? Do the breakpoints start working then?

[tforster]

@petebacondarwin Well, that worked. I am somewhat embarrassed that I never tried running Wrangler from my regular terminal.

This is the output from my terminal

/home/tforster/dev/TroyForster/wrangler-issue/holy-night-c988 npx wrangler dev

 ⛅️ wrangler 4.50.0 (update available 4.51.0)
─────────────────────────────────────────────
╭──────────────────────────────────────────────────────────────────────╮
│  [b] open a browser [d] open devtools [c] clear console [x] to exit  │
╰──────────────────────────────────────────────────────────────────────╯
⎔ Starting local server...
[wrangler:warn] The latest compatibility date supported by the installed Cloudflare Workers Runtime is "2025-11-18",
but you've requested "2025-11-25". Falling back to "2025-11-18"...
Features enabled by your requested compatibility date may not be available.
Upgrade to `[email protected]` to remove this warning.
[wrangler:info] Ready on http://localhost:8787
▲ [WARNING] Failed to open inspector.

  Inspector depends on having a Chromium-based browser installed, maybe you need to install one?


[wrangler:info] GET / 200 OK (12ms)
[wrangler:info] GET /favicon.ico 200 OK (3ms)
[wrangler:info] GET / 200 OK (8ms)
[wrangler:info] GET /favicon.ico 200 OK (3ms)
[wrangler:info] GET / 200 OK (5ms)
[wrangler:info] GET /favicon.ico 200 OK (2ms)

After I started Wrangler I went back to VSCode and clicked my debugger using the following configuration:

{
	"name": "Wrangler",
	"type": "node",
	"request": "attach",
	"port": 9229,
	"cwd": "/",
	"resolveSourceMapLocations": null,
	"attachExistingChildren": false,
	"autoAttachChildProcesses": false
}

Refreshed the page in my browser and my breakpoint hit.

I can confirm this works for both my Debian VM in ChromeOS and Ubuntu in WSL2.

[petebacondarwin]

Cool! So it seems we need to finesse the way we identify whether we are running in a "VS Code JS Debugger Terminal" rather than just a "VS Code Terminal".

[petebacondarwin]

Could you try checking what is in VSCODE_INSPECTOR_OPTIONS when running inside VS Code terminals?

$ node
> console.log(process.env.VSCODE_INSPECTOR_OPTIONS);

[petebacondarwin]

In a non-JS debugger terminal (on my machine) this env var is undefined. When I run node in a JS debugger terminal I get:

{"inspectorIpc":"/var/folders/4y/p2byx3fd4q123f9nbn39xv3h0000gn/T/node-cdp.32672-ea02cccd-0.sock","deferredMode":false,"waitForDebugger":"","execPath":"/Users/pbacondarwin/.nvm/versions/node/v22.21.1/bin/node","onlyEntrypoint":false,"autoAttachMode":"always","openerId":"f6ab848bc521515cf8d635db"}

[tforster]

The following is from my Debian VM on ChromeOS

Terminal	ENV	Node process.env
OS		undefined undefined
VSCode	:::{"inspectorIpc":"/tmp/node-cdp.9298-e72fdf6a-0.sock.deferred","deferredMode":true,"waitForDebugger":"","execPath":"/home/tforster/.config/nvm/versions/node/v25.2.1/bin/node","onlyEntrypoint":false,"autoAttachMode":"smart","aaPatterns":["/home/tforster/dev/TroyForster/wrangler-issue/holy-night-c988/**","!**/node_modules/**","**/$KNOWN_TOOLS$/**"]}	{"inspectorIpc":"/tmp/node-cdp.9298-e72fdf6a-0.sock.deferred","deferredMode":true,"waitForDebugger":"","execPath":"/home/tforster/.config/nvm/versions/node/v25.2.1/bin/node","onlyEntrypoint":false,"autoAttachMode":"smart","aaPatterns":["/home/tforster/dev/TroyForster/wrangler-issue/holy-night-c988/**","!**/node_modules/**","**/$KNOWN_TOOLS$/**"],"openerId":"1d6b66749a31de14037f410f"}
JSDebugger	:::{"inspectorIpc":"/tmp/node-cdp.27044-c0e5c558-9.sock","deferredMode":false,"waitForDebugger":"","execPath":"/home/tforster/.config/nvm/versions/node/v25.2.1/bin/node","onlyEntrypoint":false,"autoAttachMode":"always","fileCallback":"/tmp/node-debug-callback-c1b6756f2f584e47"}:::{"inspectorIpc":"/tmp/node-cdp.9298-e72fdf6a-0.sock.deferred","deferredMode":true,"waitForDebugger":"","execPath":"/home/tforster/.config/nvm/versions/node/v25.2.1/bin/node","onlyEntrypoint":false,"autoAttachMode":"smart","aaPatterns":["/home/tforster/dev/TroyForster/wrangler-issue/holy-night-c988/**","!**/node_modules/**","**/$KNOWN_TOOLS$/**"]}	{"inspectorIpc":"/tmp/node-cdp.9298-e72fdf6a-0.sock.deferred","deferredMode":true,"waitForDebugger":"","execPath":"/home/tforster/.config/nvm/versions/node/v25.2.1/bin/node","onlyEntrypoint":false,"autoAttachMode":"smart","aaPatterns":["/home/tforster/dev/TroyForster/wrangler-issue/holy-night-c988/**","!**/node_modules/**","**/$KNOWN_TOOLS$/**"],"openerId":"8051035f0fdea865163d6323"}

[tforster]

FWIW, I use NVM to manage node versions. My default shell is ZSH

[penalosa]

@tforster do you have Auto Attach set to "smart" in VSCode? https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_auto-attach

[tforster]

@penalosa I do.

[penalosa]

@tforster Aha! I think that might be it. We need to fix this, but could you try turning it off to see if that works?

[tforster]

With autoattach set to Disabled, I can run npx wrangler dev from a VSCode terminal, start and connect the VSCode debugger, and hit the breakpoint. If I try from the JSDebugger terminal, a connection appears to be made to the debugger automatically, but my breakpoint is not hit. If I add a second debugger session explicitly to my launch configuration, it appears to connect, but the breakpoint is still not hit.

What is the expectation for the latest version of Wrangler? Are VSCode terminals with a user-initiated debugger connection the standard? Or is the JSDebugger terminal expected to work in some way? FYI, for me, manually connecting my debugger after starting Wrangler is perfectly fine. This is the process I have used, going all the way back to pre-VSCode with Visual Studio (Not for Wrangler because it did not exist then, but for JavaScript debugging in general).

[petebacondarwin]

What is the expectation for the latest version of Wrangler?

As far as we have found (up till now) the VS Code JS Debug Terminal is working well with debugging into workerd, although it is a bit of a hack since we rely upon some internals of VS Code, which could change.

It seems from your experience that on Linux based systems this is not working so we need to investigate why.

[tforster]

@petebacondarwin Let me know how I can help. I am happy to test in my local environments. I can also dive into some code, although I have no idea where to start.

[petebacondarwin]

Thanks @tforster - not sure when we will have time to investigate before Xmas but if you wanted to have a dig around then the code that got changed in this PR would be a good place to start: https://github.com/cloudflare/workers-sdk/pull/9535