Change:
"integrity": "sha512-bRRFxLfg5dtAyl5XyiVWz/ZBPahpOpPrNYnnHpOpUZvam4tKH35wdhP4Kj6PbM0+KdliOsPzbGWpkxcdpNB/sg==" }, "node_modules/@vscode/proxy-agent": { <del> "version": "0.23.0", "resolved": "https://registry.npmjs.org/@vscode/proxy-agent/-/proxy-agent-0.23.0.tgz", "integrity": "sha512-6lgxRrzURdWwBkk6TaB0+EYYjIWQXxry6GlVO0toBN8amIyVd3I7hLPKU9Xf+SOrLIrbdU0CLkmTOBHpPJLf/g==", </del> <ins> "version": "0.22.0", "resolved": "https://registry.npmjs.org/@vscode/proxy-agent/-/proxy-agent-0.22.0.tgz", "integrity": "sha512-TQrv456pbrjmD6G+iOoXE1Mflm+8Ic/Kny4QU7ioiYe2+0HisvqzJM/CUa3Am5SWrNjMbntTHISjgmSaSlorrA==", </ins> "dependencies": { "@tootallnate/once": "^3.0.0", "agent-base": "^7.0.1",

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: v1.93.1 OS Version: Windows 11 Steps to Reproduce: to a markdown file in VS Code "Send to Anki dec" will fail, like below ! load VS Code 1.92 to a markdown file "Send to Anki dec" works fine The code in question is here: Something in the latest release has prevented fetch from working within the extension and im not sure what it is, I couldn't find any similar issue Original issue raised from:
does it make any difference if your extension updates to the latest node-fetch (3.3.2)?
v3.3.2 fails but the built in fetch (I assume Electron fetch) does seem to work. So a workaround could be to move to that. I still don't know why the latest release has broken node-fetch though. I also don't know which VS Code version fetch was being included in so ill have to gate the changes to the last release
From the runtime side there was a bump in minor version but there is no related change that could cause this regression. This could be an issue with our proxy agent patching, /cc can you check.
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression.

Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
I am currently investigating a networking slowdown experienced by some users of an extension I help maintain, which started in 1.93. I have asked oe of them to run that bisect. Meanwhile a current hypothesis is pointing to because keepalive seems somehow involved.
Thanks I ran the bisect, here are the results: Changes are : So it does indeed look like the proxy-agent update has broken the extension Its worth pointing out I switched to the built in fetch which fixed it on our side but there may be other extensions using node-fetch which will be failing. (I also don't know why this only affects node-fetch but not the Electron fetch)
In my case we seem to have resolved the issue by creating a (currently still beta) build of our extension so it no longer sets on its http[s].Agent, which had long been done by us but which until 1.93 was apparently not forwarded to by the proxy agent.
One investigation suggests that with on the custom agent, connections are not actually reused: This would happen if the agent was not reused, but this one seems to be kept around and use for all connections. Not sure how the localhost case (which does not use a custom agent) fits in, that would use the global agent which is reused and therefore should reuse connections. I'll roll back the vscode-proxy-agent version for now.