fix(terminal): catch ENOPRO in getCwdResource when file:// provider absent in VS Code web

[mutl3y]

Problem

Fixes #317329 (related — same deployment scenario, different subsystem)

When using VS Code Server (server-linux-x64-web) accessed via a browser, calling getCwdResource() on a terminal instance throws:

Error: No file system provider found for resource 'file:///workspace' (ENOPRO)

This surfaces as a failure on every Copilot agent terminal tool invocation (the agent host calls getCwdResource() to resolve the working directory before running a shell command). Any other caller that relies on this method is similarly broken.

Root cause

getCwdResource() in terminalInstance.ts has two branches:

if (this.remoteAuthority) {
    resource = await this._pathService.fileURI(cwd);  // remote-aware ✅
} else {
    resource = URI.file(cwd);                          // Electron/desktop only ❌
}

In a self-hosted server-linux-x64-web deployment without an explicit remoteAuthority header, this.remoteAuthority is falsy from the terminal's perspective. The else branch fires, producing a file:///workspace URI. The browser FileService has no file:// provider registered — only the remote provider — so _fileService.exists(resource) throws ENOPRO.

This else branch is desktop/Electron-only code: in a correct remote-web context remoteAuthority would be set and _pathService.fileURI() would be used instead.

Fix

Wrap the function body in try/catch so that provider errors (ENOPRO or otherwise) return undefined, allowing callers to fall back to the default CWD rather than propagating the error. The existing logic is preserved — only the error path is changed.

async getCwdResource(): Promise<URI | undefined> {
    const cwd = this.capabilities.get(TerminalCapability.CwdDetection)?.getCwd();
    let resource: URI;
    try {
        if (this.remoteAuthority) {
            resource = await this._pathService.fileURI(cwd);
        } else {
            resource = URI.file(cwd);
        }
        if (await this._fileService.exists(resource)) { return resource; }
    } catch {
        // FileService provider not available for this URI scheme (e.g. file:// in
        // VS Code web where only the remote provider is registered).
        return undefined;
    }
    return undefined;
}

Testing

Verified against a running server-linux-x64-web instance (v1.121.0, commit f6cfa2ea) in a containerised deployment:

• Before: Copilot agent terminal tool fails on every invocation with ENOPRO
• After: Terminal tool executes successfully; getCwdResource returns undefined and the tool falls back to the default CWD

Notes

• Only one file changed: src/vs/workbench/contrib/terminal/browser/terminalInstance.ts
• This is independent of PR Fix secret storage persistence in VS Code Server web #317333 (secret storage key minting) — different subsystem, different file
• A more complete fix would detect the web context and always route through _pathService.fileURI(); this PR takes the minimal safe approach of catching the error

[Copilot]

Pull request overview

This PR hardens the terminal instance working-directory URI resolution in VS Code web/server scenarios by preventing getCwdResource() from throwing when the FileService cannot handle the produced URI (notably when a file:// provider is absent), allowing callers (including agent terminal tools) to fall back gracefully.

Changes:

• Wrap TerminalInstance.getCwdResource() URI creation/existence validation in try/catch.
• Return undefined instead of propagating provider-related errors (e.g. ENOPRO) from fileService.exists.