[Remote-SSH Bug]: spawn rg ENOENT on global search when .code-workspace folder uses vscode-remote:// URI

Related issue

Reopening #8105 (closed, but the problem persists through v1.113).

Summary

When a .code-workspace file defines its folders using the uri field with a vscode-remote:// scheme (as VS Code itself generates), global search fails with a misleading ENOENT error pointing to the ripgrep binary. The binary is not the problem — VS Code is passing the full vscode-remote:// URI string as the working directory to the ripgrep child process instead of resolving it to the actual filesystem path on the server.

Steps to reproduce

1. Connect to a remote host via Remote SSH
2. Open a .code-workspace file whose folders entry uses uri rather than path, e.g.:

{
  "folders": [
    { "uri": "vscode-remote://ssh-remote+my-server/home/user/myproject" }
  ],
  "remoteAuthority": "ssh-remote+my-server"
}

3. Trigger a global search (Ctrl+Shift+F)

Expected behaviour

Search works normally.

Actual behaviour

spawn /home/user/.vscode-server/cli/servers/Stable-<hash>/server/node_modules/@vscode/ripgrep/bin/rg ENOENT

Diagnostic findings

The error misleadingly points to the rg binary, but extensive debugging confirmed:

• The binary exists at the reported path (ls -la confirms it)
• It is executable and statically linked (ldd reports "statically linked")
• It runs correctly when invoked directly: rg --version returns ripgrep 15.0.0
• VS Code's own bundled Node.js can spawn it successfully via child_process.spawn() in isolation

The actual cause is that when a workspace folder is defined with a vscode-remote:// URI, VS Code passes that URI string verbatim as the cwd for the ripgrep process. Since vscode-remote://ssh-remote+my-server/home/user/myproject is not a valid filesystem path, the kernel cannot resolve the working directory, and Node.js reports this as ENOENT on the command — rather than on the invalid cwd — which makes the error very confusing to diagnose.

Environment

• VS Code versions tested: 1.109, 1.111, 1.112, 1.113 — all affected
• Remote OS: Debian 12 (Bookworm), glibc 2.36, x86_64
• Connection type: Remote SSH

Workaround

Open the folder directly (File → Open Folder) instead of via the .code-workspace file.

Start by reproducing global search over a .code-workspace folder whose folders entry uses a vscode-remote:// URI, then trace how the Remote SSH workspace folder becomes the ripgrep process cwd. The issue provides no source file or test path, so inspect the search and child_process spawn flow. Done means global search works for URI-based workspace folders without the misleading ENOENT.