When ssh remote connect to window, uri error occurs

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When connecting to a remote Windows machine via SSH, the AI Agent repeatedly throws the following error during chat or whenever the integrated terminal panel is open:

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

This appears to be a Windows path parsing bug, where the agent incorrectly treats Windows-style paths (e.g., C:\Users\...) as URIs when collecting terminal context or resolving relative file paths.

Observed symptoms:

  • The agent fails to respond or shows a connection/URI error while the terminal panel is visible
  • File diffs are not displayed after agent edits — the Accept / Reject buttons never appear, so there is no way to review or deny agent changes before they are applied
  • The error disappears temporarily when the terminal panel is hidden, but returns as soon as it is opened again
  • This bug persists across multiple versions — confirmed on the latest release (v2.5), downgraded to v2.4, and further downgraded to v2.2; the issue reproduces on all tested versions

Workaround and its secondary problems (Korean locale / non-ASCII users)

As a forced workaround, the agent falls back to PowerShell commands (Set-Content, Get-Content, Select-Object, etc.) instead of using native file tools. While this partially bypasses the URI error, it introduces critical secondary issues for Korean Windows users (and any locale where the default Windows encoding is not UTF-8, e.g., Japanese CP932, Chinese GBK):

  • PowerShell output contains garbled Unicode characters (mojibake) due to an encoding mismatch between the system codepage (CP949 / EUC-KR on Korean Windows) and the UTF-8 expected by the agent
  • Because the agent receives garbled output, it embeds broken or escaped Unicode sequences directly into source code (e.g., \uAC00\uB098\uB2E4 or ??? instead of 가나다)
  • Newlines are stripped from file content when read back through PowerShell — Korean characters in comments cause the encoding mismatch to consume or collapse line break characters (\n / \r\n), resulting in syntax errors as multiple lines are merged into one
  • As a direct consequence, Korean comments cannot be used at all in any source file managed by the agent — writing a single Korean comment causes the entire file to become syntactically invalid after the next agent edit
  • This results in:
    • No accept/reject UI — changes made via PowerShell commands are applied immediately with no diff view, leaving the user with no ability to review or undo agent edits before they land in the codebase
    • Syntax errors introduced silently — garbled encoding collapses newlines, breaking code structure without any warning
    • Severely reduced code readability — Korean string literals, comments, and identifiers in source files become unreadable noise
    • Increased token consumption — escaped Unicode sequences are far longer than their original characters, wasting context window budget on every request
    • Unreliable agent behavior — the agent cannot correctly verify or reason about its own output when strings are garbled

This combination of bugs forces Korean developers to write an English-only codebase as a workaround, and even then the lack of an Accept/Reject UI makes it unsafe to use the agent on any production code.

Steps to Reproduce

  1. Set up a Korean locale Windows 10 machine as an SSH remote host (system codepage: CP949)
  2. Connect to it from a Windows 11 local machine via Cursor’s Remote SSH extension
  3. Open any project containing Korean characters in file contents, comments, or paths
  4. Open the integrated terminal panel and switch to Agent mode
  5. Ask the agent to read or edit any file
  6. Observe:
    • [UriError] in Developer Tools (Help → Toggle Developer Tools → Console)
    • Agent falls back to Set-Content / Get-Content / Select-Object PowerShell commands
    • No diff/Accept/Reject UI is shown — changes are applied silently
    • Korean characters in agent output and written code are garbled or escaped
    • Files containing Korean comments have their newlines collapsed, producing syntax errors

Expected Behavior

  • The agent should use native file tools without throwing URI errors on Windows paths
  • File diffs should always be shown with Accept / Reject buttons before any changes are applied to the codebase
  • PowerShell fallback (if used) should handle non-UTF-8 system encodings gracefully, preserving Korean and other non-ASCII characters and newlines correctly
  • Korean comments and string literals should be writable in any source file without causing encoding-related syntax errors

Screenshots / Screen Recordings

스크린샷 2026-02-26 160205.png
스크린샷 2026-02-26 160205.png244×163 4.43 KB

Operating System

Windows 10/11

Version Information

Version: 2.2.44 (system setup), but Latest release → downgraded to 0.46.x → further downgraded to 0.44.x (v2.2); issue reproduces on all versions
VSCode Version: 1.105.1
Commit: 20adc1003928b0f1b99305dbaf845656ff81f5d0
Date: 2025-12-24T21:41:47.598Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.22631

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey, thanks for the detailed report, especially the breakdown of the Korean encoding cascade. That’s really helpful.

The main URI error is a known regression when connecting over SSH to a Windows host. The agent mishandles Windows style paths (C:\...) while collecting terminal context, which breaks file tools, diffs, and the Accept/Reject UI.

Same root cause as these threads:

Temporary workaround (partial): switch the bottom panel from Terminal to Output before using the agent. This prevents terminal context collection, which is what triggers the URI error. It doesn’t always help for Windows to Windows SSH, but it’s worth a try.

Version rollback: going back to version 2.2.44 helped other users in this situation, though that’s not ideal long term.

The team is aware of the URI path parsing issue. The PowerShell encoding issues you described with CP949 and a Korean locale

A couple things that would help:

  1. Can you share the Request ID? (chat menu in the top right, then Copy Request ID)
  2. What version of the Anysphere Remote SSH extension are you on? (Ctrl+Shift+X, search for Remote-SSH, then check the version number)

Let me know if the Output panel workaround changes anything for you.

5

Thank you for the suggestions!

I had already found the related threads and rolled back to v2.2.44 before your response, but the issue still reproduces on this version as well — so the rollback did not help in my case.

The Output panel workaround does reduce the frequency of the [UriError], but the agent still occasionally falls back to PowerShell (Set-Content, Get-Content, Select-Object), at which point the CP949 encoding issues and missing Accept/Reject UI persist.

  • Request ID: 91406ab1-4c8d-4533-b996-fe39b8982cf7

  • Remote SSH extension version: 1.0.44

6

Got it, thanks for the Request ID and the extension version.

Since the rollback didn’t help and the Output panel workaround only partly works, there isn’t a reliable client-side fix right now, unfortunately. We’re tracking both the URI path parsing on Windows remotes and the PowerShell encoding chain you described. The Korean CP949 detail is especially helpful. That’s a gap we hadn’t fully captured before.

One thing you can try for the encoding part is to set UTF-8 as the default encoding in your PowerShell profile on the remote machine:

# Add only this to $PROFILE:
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

This won’t fix the main URI error, but it may reduce the mojibake when the agent falls back to PowerShell commands. No guarantees though. The encoding mismatch can happen at multiple layers.

I’ve flagged your report and the Request ID with the team. I can’t share a timeline, but the detailed repro steps and the encoding breakdown you shared help with prioritization.

I’ll update this thread if there’s progress. Let me know if the PowerShell encoding change makes any difference.