I get “Failed to install Cursor server: The “path” argument must be of type string. Received undefined” sometimes when connecting to an SSH remote and connecting into a Docker container. It may just be connecting to SSH is enough to trigger it…
I feel like I may have seen this a while ago but it started happening a lot a few weeks ago. I’ve had to use VSCode
Steps to Reproduce
Launch a docker container on a remote.
Cursor → Connect to SSH remote and connect to that remote^
In that SSH-connected window, attach to container => “Failed to install Cursor server: The “path” argument must be of type string. Received undefined”
Or, when it’s working, > Developer: Reload Window can produce the same error.
A workaround that sometimes helps is to make sure the SSH remote host, not the container, has a .gitconfig and that $HOME is set correctly:
echo $HOME
ls -la ~/.gitconfig
# If the file doesn't exist:
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
To be honest, for some users this workaround doesn’t help because the root issue is in the extension itself. The team is aware, but there’s no ETA for a fix yet. I passed along another signal, your report helps with prioritization.
2026-03-23 08:22:15.125 [error] Failed to read .gitconfig: TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
2026-03-23 08:22:15.127 [error] Error resolving dev container authority The "path" argument must be of type string. Received undefined
Running Cursor on a Windows 11 Host. Connecting via SSH to a Ubuntu 24.04 Host which runs the devcontainer (Yocto image).
A fix would be appreciated. Visual Studio Code runs without any problems.
Interestingly enough, I got it running at one point, but I’m not sure what I did exactly. I guess something like removing .cursor and .cursor-server as well as removing all docker images etc. But then after closing Cursor and re-opening, the error came up again.
I see a few more users have joined with the same issue. The bug is logged and the team is aware. Your reports help us prioritize, especially when they include specific details like @StefanW’s.
@UnluckyForSome, repeatedly clicking Reinstall Server as a temporary workaround, yeah, unfortunately that’s still the only thing that reliably works for some users. Another option is to delete .cursor-server on the remote host and try again:
rm -rf ~/.cursor-server
There’s no ETA for a fix yet, but we’re tracking it. I’ll update this thread when we have news.
Would a work around be to either automatically or after a prompt, remove .cursor-server? Or at very least to add this suggestion to that error message?
It is curious that VSCode doesn’t have this problem at all. And that only recently did cursor start presenting this behavior. Also, for me it happens less now than it did a few weeks ago. It used to fail >80% of tries. Now it fails <30% I’d guess. Weird.
Hey @BenFrantzDale good idea on both the automatic cleanup of .cursor-server and improving the error text. Right now the error message really doesn’t give any useful hints.
The fact that the frequency dropped from about 80% to about 30% is an interesting signal. Something might have improved indirectly in recent versions, even if the root bug is still there.
I’ll update the thread as soon as there’s progress.
Version: 3.0.13 (user setup)
VSCode Version: 1.105.1
Commit: 48a15759f53cd5fc9b5c20936ad7d79847d914b0
Date: 2026-04-07T03:05:17.114Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631Connecting the dev container via SSH from Windows
Additional Information
Devcontainer Extension: 1.0.32
The following errors appear in the Developer Tools console:
Failed to install Cursor server: The "path" argument must be of type string. Received undefined
ERR [LocalProcess1][resolveAuthority(dev-container,1)][3868ms] returned an error {code: 'NoResolverFound', message: 'No remote extension installed to resolve ssh-remote.'}
repeatedly running “Reload Window” via Ctrl+P may eventually allow the connection to succeed, but this is not reliable and requires multiple attempts.
