A path resolution error occurs when using an SSH remote environment

[Xiao_xiao (Sean Guo)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I use SSH to connect to a remote Windows environment, the agent frequently fails to resolve file paths correctly, and I cannot see the diffs of the modified files.

Steps to Reproduce

1. Switch to Agent mode and have the agent modify any file.
2. I see the following error during the thinking process.

[UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character

3. After the agent finishes modifying the file, I can’t see the diff in the editor, and there are no Keep or Undo buttons.

Expected Behavior

During the think process, there is no path resolution, and the modified file diffs can be displayed normally.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 2.4.31 (system setup)
VSCode Version: 1.105.1
Commit: 3578107fdf149b00059ddad37048220e41681000
Date: 2026-02-08T07:42:24.999Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26100

For AI issues: which model did you use?

Auto / Compose / GPT5.2

For AI issues: add Request ID with privacy disabled

RequestID: b67a79d5-8752-44c5-a09e-95c425018dfd

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[Xiao_xiao (Sean Guo)]

I rolled back to version 2.2.44, and the issue no longer occurs. However, I would like to use the latest version and Composer 1.5 normally.

[deanrie]

Hey, thanks for the report. This is a known regression in URI path parsing when using an SSH connection to a Windows host. The agent doesn’t handle Windows paths correctly in this setup, which causes a UriError and breaks comparisons and the Keep and Undo buttons.

The same issue is described here: [URGENT] Agent stops working after the first message, and the only reliable workaround right now is rolling back to version 2.2.44, which you already found.

I’ve sent this back to the team again since it’s still happening in 2.4.31. I don’t have an ETA yet, but your report and the Request ID help us prioritize it.

I’ll post an update here as soon as I have news.

[Prateek_Roy]

I have the same problem. The only workaround I found is to rollback to 2.2.44. Please fix this problem for Windows SSH users as it completely breaks our workflow. Thanks!