vscode-remote-release
vscode-remote-release copied to clipboard
Unable to connect to VS Code server: Error in request - ENOENT /run/user/1000/vscode-ipc-*.sock
I'm occasionally but regularly seeing this error when using Remote SSH and running the code command in the built-in terminal.
Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /run/user/1000/vscode-ipc-5cc265b0-6bec-4e0e-99c7-8fc48bccd7c4.sock
at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) {
errno: -2,
code: 'ENOENT',
syscall: 'connect',
address: '/run/user/1000/vscode-ipc-5cc265b0-6bec-4e0e-99c7-8fc48bccd7c4.sock'
}
Searching in Issues, #6362 seemed related, and this comment in particular gave me a hint for a temporary solution.
VSCODE_IPC_HOOK_CLI=$( lsof | grep $UID/vscode-ipc | awk '{print $(NF-1)}' | head -n 1 )
It searches for the first available VSCode IPC socket, gets its second to last column for the path to vscode-ipc-*.sock, and updates the relevant env variable. (In the original code snippet, they were getting the last column using awk '{print $NF}' but on my system that returns type=STREAM instead.)
After running the above line, the error no longer occurs.
I'm OK with this temporary fix, but I figured I'd make an issue report, in case someone can get to the bottom of it and solve it permanently.
- VSCode Version: 1.69.2
- Local OS Version: Darwin x64 18.2.0
- Remote OS Version: Ubuntu 22.04 LTS
- Remote Extension/Connection Type: SSH
Steps to Reproduce:
The error appears occasionally (maybe after host reboots or when Remote SSH reconnects?). It might be related to #6988, "Vscode server stops after running for a while without use".
- Open terminal with CTRL/CMD+J
- Run
code some-file.txt
I have the same issue of this, and it only happens when I accidently closed the connection to remote (for example, Ctrl+Q to close the remote window) and instantly reopen it. The error on my side can be solved upon eliot's approach, but it is indeed not convenient when I have multiple opened cli windows. I guess this error may be related with some recent updates on remote-cli since I did not see this error at least in the version which did not change code into code-server and mv code into dir remote-cli
VSCode Version: 1.69.1 Local OS Version: CentOS Linux release 8.5.2111 Remote OS Version: CentOS Linux release 8.4.2105 Remote Extension/Connection Type: SSH
Same problem. Trying to work out how to use your solution above - if I run $ lsof | grep $UID/vscode-ipc | wc -l I have 90 lines. Is that normal??
VsCode 1.69.2 Remote OS: Rocky Linux release 8.5 (Green Obsidian) Remote Extension/Connection Type: SSH
same issue
Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /run/user/1003/vscode-ipc-29b85497-9c46-43f3-b7bb-30557442106d.sock
at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) {
errno: -2,
code: 'ENOENT',
syscall: 'connect',
address: '/run/user/1003/vscode-ipc-29b85497-9c46-43f3-b7bb-30557442106d.sock'
I just got the same thing in Codespaces:
Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /tmp/vscode-ipc-aac63c64-d630-482f-a06b-b651ce82b0e3.sock
at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1161:16) {
errno: -2,
code: 'ENOENT',
syscall: 'connect',
address: '/tmp/vscode-ipc-aac63c64-d630-482f-a06b-b651ce82b0e3.sock'
}
There was an auto-update waiting. Restarting to get the update solved the problem. So I wonder if this has to do with the auto-updater.
This problem has a workaround https://github.com/microsoft/vscode-remote-release/issues/3575. Apparently after a VSCode update the cached server doesn't get invalidated properly.
Of course this workaround is not nice and should be handled automatically, sadly the other Issue was closed prematurely.
The temporary fix that's working for me is to refresh the constant VSCODE_IPC_HOOK_CLI with an open/available socket process named vscode-ipc-*.sock.
It means the error is caused by that environment variable having a "stale" value, pointing at an old socket process which no longer exists.
I searched for where the constant is being used, in all the repos under the microsoft organization (search result). Here's where the error is occurring.
https://github.com/microsoft/vscode/blob/f8ae10c8d05cf92f55c19b4937f0a5c5c0498778/src/vs/server/node/server.cli.ts#L374
The env variable is passed to the http module for the option socketPath. When it's an invalid value, http.request throws, "Error in request - ENOENT".
Interestingly, when I search for this env variable throughout GitHub (result), there are other people who ran into the same error with stale socket process causing an error in VSCode server CLI.
From the top result:
The VSCODE_IPC_HOOK_CLI environment variable points to a socket which is rather volatile, while the long path for the 'code' alias is more stable: vscode doesn't change the latter even across a "code -r ." reload. But the former is easily detached and so you need a fresh value if that happens. (source)
And the second:
Each time the VS Code window is reloaded a new IPC socket is created. If you leave a background processes running and then exit VS Code (or reconnect) it with have a stale
VSCODE_IPC_HOOK_CLIvariable/IPC socket and won't be able to open the browser on your host.To fix, update
VSCODE_IPC_HOOK_CLIin the process's environment to the latest socket. (source)
So we're all seeing the same issue.
The permanent solution seems to be: in vscode/src/vs/server/node/server.cli.ts, to check if VSCODE_IPC_HOOK_CLI is pointing to a living socket process; if it's not, refresh the value with the path to an available one. Basically applying the fix that we're doing internally and automatically.
@eliot-akira I'm not quite sure that's the only issue. when I refresh VSCODE_IPC_HOOK_CLI and use 'code --wait' as my git rebase editor, it tells me I need to run the command from a console that was started from within VSCode.
@SoftwareApe It sounds like you might be experiencing a related but different issue. For me, that one-liner in the issue description solved it completely (so far). But from your earlier comment, I see you're having to remove ~/.vscode-server (and probably reload the window or restart the editor).
@eliot-akira yes, that's right, delete the server and restart helped
@SoftwareApe It sounds like you might be experiencing a related but different issue. For me, that one-liner in the issue description solved it completely (so far). But from your earlier comment, I see you're having to remove
~/.vscode-server(and probably reload the window or restart the editor).
yes, but my ~/.vscode-server has produced more than 9G data, no idea if there are some useful cache (like produced by cpp extension, help me travel in my huge project) that I don't want to delete.

so I'm using the VSCODE_IPC_HOOK_CLI solution
I am also encountering this issue, but seemingly only after setting up an rsa key as the preferred ssh authentication method. Not sure if it's related but i thought I'd mention it.
Having this issue when using code -r . to open VS code's folder structure to where I am in my present working directory.
I had the same issue and the workaround from @eliot-akira did not work in my case.
For me this following slightly modified command solved the issue:
VSCODE_IPC_HOOK_CLI=$(lsof | grep $USER | grep vscode-ipc | awk '{print $(NF-1)}' | head -n 1)
I had the same issue and for me I cleared the cache files in folders vscode-server/ .vscode-server-insiders/:
rm -rf .vscode-server/
rm -rf .vscode-server-insiders/
and restarting the CLI solved the problem.
close vscode then in powershell: wsl --shutdown. Then reopen vscode..
This problem has a workaround #3575. Apparently after a VSCode update the cached server doesn't get invalidated properly.
Of course this workaround is not nice and should be handled automatically, sadly the other Issue was closed prematurely.
Here it suggests removing the ~/.vscode-server folder which is inconvenient because you also remove all extensions and stuff. In my case, by removing ~/.vscode-server/bin/blah/vscode-remote-lock.<my_user>.blah solved the issue and I got to keep everything including the installed extensions.
Is this happening in a terminal that was previously open, before reconnecting? I guess the value of the IPC environment var is stale, does this work in a new terminal when failing in the old terminal?
I haven't found a reliable way to reproduce the issue, but in my case I believe it's always with a new terminal opened after VSCode Server reconnects.
For reference, I opened a corresponding issue in microsoft/vscode#157275, close to the file where the error is occurring: src/vs/server/node/server.cli.ts. It's where the constant cliPipe is defined from the env variable, and the function sendToPipe passes it in a call to http.request, which throws if the socket is stale.
The solution seems to be, before the call to http.request, it needs to check and refresh the socket path to make sure it's pointing to a living process. I'm not sure about the technical details how best to implement it - perhaps it's more efficient to catch the ENOENT error, then refresh the socket path to retry as needed (instead of checking on every call to sendToPipe).
Thanks for opening that upstream issue. I thought I'd heard about this recently. Will close this in favor of the other issue. https://github.com/microsoft/vscode/issues/157275
I somehow ran into the same problem. Restarting VS Code app did not fix the issue for me.
what worked was, I ssh -ed into the remote machine via a terminal and htop -u $USER to see running processes. A few vscode-server processes were still running even after the app is closed. Using htop I killed all processes that had $HOME/.vscode-server/blah/blah pathname. Then reopening vscode and re-login into remote development session fixed the issue for me!
Same issue, restarting vscode etc doesn't work, but @eliot-akira 's workaround worked right away. Thanks for both raising this, and for making the workaround so easy to find @eliot-akira :)
use below commands and then it will ask id password again while doing any transaction on git.
rm -rf .vscode-server/ rm -rf .vscode-server-insiders/