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.
Attach to a running container using Dev Containers: Attach to Running Container
/workspace opens normally
When trying to open /workspace/A as a folder
The following issues occur:
Infinite Opening Remote... loading
Or the following error:
Failed to install Cursor server:
The "path" argument must be of type string. Received undefined
What I’ve tried
Installed Node.js inside the container
Removed ~/.cursor-server and reinstalled
Verified $HOME and .gitconfig on the SSH host
Restarted Cursor / Reloaded Window
Changed attach → open folder order
None of these resolved the issue
Observations
/workspace opens without any issues
The problem only occurs when re-opening a subfolder (/workspace/A)
The same setup works fine in VS Code
Additional context
Based on responses from the Cursor team, this issue is acknowledged but there is currently no ETA for a fix
Questions
Can you confirm if this is a known bug?
Is there a stable way to directly open /workspace/A as the workspace?
Is there any official workaround for this issue when changing folders after attaching to a Dev Container?
If anyone has encountered and resolved this issue, I would greatly appreciate it if you could share your solution.
Comment
At the moment, this issue significantly disrupts the development workflow.
If this remains unresolved, it raises serious concerns about whether Cursor is usable in this setup.
The problem is that it keep crashing if you trying to use “path” reference inside your workspace, and it’s a huge deal.
I may run multiple workspaces with different paths in order to isolate agents workloads to produce and test outcomes and if my job crashed in the middle - it has two issues.
I need to start work over.
The number of tokens company acquired with my work was thrown into trash ( hundreds of dollars).
I’m seeing what looks like the same bug with Cursor Dev Containers over Remote SSH.
Environment:
Cursor client: Windows
Remote host: Ubuntu 24.04.4 LTS via Remote SSH
Remote host kernel: Linux 6.8.0-110-generic
Docker Engine: 29.4.1
Dev Containers extension: anysphere.remote-containers-1.0.32
Topology: Windows Cursor client → Remote SSH Linux host → Dev Container
What works:
Starting the devcontainer manually with the devcontainers CLI works.
Attaching to the already running container from Cursor works.
Example:
npx --yes @devcontainers/cli up --workspace-folder /home/khughes/shq2 --remove-existing-container
Then Cursor → Dev Containers: Attach to Running Container succeeds.
What fails:
Dev Containers: Rebuild and Reopen in Container
Dev Containers: Open Folder in Container…
Opening directly into the devcontainer from the Remote SSH workspace
The devcontainer initialize step completes successfully, Docker works, and the container is healthy. Cursor then fails while installing the remote server in the container.
Relevant log:
2026-04-30 00:02:01.371 [info] Resolving dev container authority ‘dev-container+…’ container ‘{“settingType”:“container”,“containerId”:“849bcc1822fa”}’
2026-04-30 00:02:01.371 [info] Using exec server from resolve options. execServerRemoteAuthority: ssh-remote+…
2026-04-30 00:02:01.467 [info] [docker info]: Command completed with exit code 0
2026-04-30 00:02:01.493 [info] [docker inspect]: Command completed with exit code 0
2026-04-30 00:02:01.539 [info] Installing remote server in container…
2026-04-30 00:02:01.539 [error] Error resolving dev container authority The “path” argument must be of type string. Received undefined
This appears to be in the Windows client → Remote SSH host → devcontainer handoff, after the container has already been created/started. It does not appear to be a Docker or devcontainer.json lifecycle failure.
2026-04-30 12:13:25.203 [error] [Window] Extension 'anysphere.remote-ssh' appears in product.json but enables LESS API proposals than the extension wants.
It shows that the extensions has no parity with the VSCode extensions.
Assume that the usage of the following settings is also not supported by Cursor anysphere.remote-ssh extension.
The following issues occur: