Cursor IDEでWindowsへSSH接続すると「UriError」が連発する原因と対処法：パス解釈バグと文字化け地獄を回避する
Cursor IDEでリモート開発をしていると、WindowsマシンへSSH接続した瞬間からチャットが止まり、ターミナルを開くたびに[UriError]が連発する──そんな症状に遭遇すると開発どころではありません。しかも「差分のAccept/Rejectが出ない」「変更がいきなり適用される」「韓国語・日本語コメントで文字化け＋改行崩壊」まで起きると、コードベースの安全性そのものが揺らぎます。
この記事では、この現象が起きる仕組み（WindowsパスとURIの衝突）を整理し、今すぐ被害を減らすための実践的な回避策と、ロケール非UTF-8環境（CP949/CP932/GBKなど）での事故を抑える設定方針をまとめます。
- Cursor IDEでWindowsへSSH接続すると「UriError」が連発する原因と対処法：パス解釈バグと文字化け地獄を回避する
まず症状を整理：何が起きているのか
報告されている代表的な症状は次の通りです。
-
WindowsリモートへSSH接続中、チャットやターミナル表示に合わせて
[UriError]が繰り返し出る -
ターミナルパネルを表示している間、エージェントが応答しない／接続エラーのような状態になる
-
エージェントが編集しても差分UI（Accept / Reject）が出ず、レビュー不能
-
ターミナルを隠すと一時的に収まるが、開くと再発する
-
複数バージョンで再現し、ダウングレードでも解消しない
つまり「ターミナルが開いているときに、エージェントがコンテキスト収集やパス解決を行う処理が破綻している」タイプの不具合に見えます。
エラー文の意味：WindowsパスがURIとして誤解釈される
エラーはこうです。
[UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character
これはURIの文法チェックに失敗したときの典型的な例で、「scheme://authority/pathの形を想定しているのに、pathが/で始まっていない」などで落ちます。
ここで厄介なのがWindowsパスです。
-
C:\Users\...のように コロン と バックスラッシュ を含む -
一部の処理系では
C:が「スキーム名」っぽく見え、URIとして扱われやすい -
バックスラッシュ
\がURIのパス区切り/と衝突しやすい
その結果、エージェント側がターミナルのカレントディレクトリや相対パスを扱う際に、WindowsパスをURIに変換／解析しようとして失敗し、ターミナル表示中に同じ処理が何度も走ってエラーが連発する、という構図が疑われます。
二次被害が深刻：PowerShellフォールバックで文字化け＋改行崩壊
報告では回避策として、エージェントがネイティブなファイル操作ではなくPowerShellコマンド（Get-Content、Set-Content等）に寄った動作になることがあります。ここでロケールがUTF-8でないWindows（例：韓国語CP949、日本語CP932、中国語GBKなど）だと、次の事故が連鎖します。
-
文字化け（mojibake）：PowerShell出力がシステムコードページで出てくる一方、エージェント側がUTF-8前提で読む
-
壊れたUnicodeがソースに混入：
가나다が\uAC00\uB098\uB2E4や???に化けて、そのままコードに書き戻される -
改行が消える／潰れる：エンコーディング不一致で
\r\nや\nが崩れ、複数行が1行に連結され構文エラーになる -
差分UIが出ないまま即時適用：Accept/Rejectが表示されず、レビュー不能のまま変更が入る
特に「コメントに日本語・韓国語を書いただけで、次の編集でファイルが壊れる」は致命的です。ソースコードの意味が変わるだけでなく、CIが落ちる、デプロイが止まる、原因が追いにくい、と被害が拡大します。
いま即効で被害を減らす運用ワークアラウンド
根本修正が来るまでの「破壊を防ぐ」目的の現実的な対策です。ポイントは、(A) UriErrorを踏みにくくする と (B) 文字化け改行崩壊を起こさない の二段構えです。
1) ターミナルパネルを閉じてからエージェントに作業させる
報告では「ターミナルを隠すと一時的に消える」ため、まずはこれが最も即効性があります。
-
エージェントに編集依頼 → ターミナルを閉じる／非表示
-
変更が出たら差分UIが出るか確認（出ない場合は次の対策へ）
-
作業中はターミナルを開きっぱなしにしない
根本解決ではありませんが、連発エラーで作業不能になる状態を回避しやすいです。
2) 重要ファイルは「エージェントによる直接編集」を避け、パッチ適用型に寄せる
差分UIが出ない環境では「自動適用」が最大のリスクです。次のように運用を変えます。
-
エージェントには「変更内容の提案（差分テキスト）」まで出させる
-
実際の適用は人間がローカルで行う（git apply / 手動反映）
-
変更が大きい場合はファイル分割して小さく反映
レビュー不能のまま改行崩壊されるより、手間でも安全側に倒す方が損失が小さくなります。
3) 非UTF-8ロケールは「UTF-8前提の入出力」に寄せる（可能な範囲で）
文字化け問題はエンコーディングのズレが原因なので、理想はWindows側をUTF-8寄りに統一することです。環境により可否はありますが、方針はこうです。
-
PowerShell側の出力・入出力をUTF-8に寄せる
-
ソースファイルはUTF-8（できればBOMなし）で統一する
-
改行コードも混在させない（LFかCRLFに統一）
ただし組織PCや既存資産の制約で変更できないケースが多いので、その場合は次の「コメント運用」で被害を抑えます。
4) 事故が起きやすいファイルでは「非ASCIIコメントを一時的に避ける」
つらい対策ですが、改行崩壊が起きる環境では効果があります。
-
重要ファイルのコメントは英語に寄せる
-
日本語／韓国語の説明は別ドキュメント（README等）へ退避
-
どうしても必要な場合は、編集が入るたびに差分を厳密に確認する
「読めるコード」より「壊れないコード」を優先する局面です。
根本原因に近い視点：何を直せば再発しないか
開発側の修正ポイントとしては、概ね次のいずれか（または複合）が疑われます。
-
WindowsパスをURIに渡す前に正規化していない（
C:\...をそのまま解析している） -
URIとして扱うべき文字列と、ファイルパスとして扱うべき文字列の判定が甘い
-
ターミナルのカレントディレクトリ取得や相対パス解決が、ターミナル表示状態に依存してループする
-
フォールバック時のファイル入出力がUTF-8固定でなく、OSコードページを踏んでしまう
ユーザー側ができるのは回避策までですが、「ターミナル表示と連動して再現」「WindowsパスがURI扱い」「非UTF-8ロケールで二次被害」という再現条件を整理しておくと、修正が入ったかどうかの検証もしやすくなります。
まとめ：優先順位は「作業継続」より「破壊防止」
この不具合は単なる表示エラーではなく、差分UIの不在や文字化け・改行崩壊によって「静かにコードが壊れる」タイプのリスクを伴います。現時点での現実的な防衛線は以下です。
-
ターミナルを閉じてエージェントを動かし、UriErrorのトリガーを避ける
-
差分UIが出ないなら、提案→人間が適用の流れに切り替える
-
非UTF-8ロケールでは、UTF-8寄せ・改行統一・非ASCIIコメント回避で被害を抑える
まずは「壊さない」運用に切り替え、再現条件を手元で固定化しつつ、修正が入ったタイミングで段階的に通常運用へ戻すのが安全です。
