fix: resolve debug console file links to remote filesystem in devcontainers by yogeshwaran-c · Pull Request #307244 · microsoft/vscode

Yogeshwaran C (yogeshwaran-c) · 2026-04-01T20:56:40Z

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

When connected to a remote environment (e.g., devcontainer), clicking a file:///path/to/file link or an absolute path link in the Debug Console opens the file from the host filesystem instead of the remote filesystem. The terminal handles this correctly, but the debug console does not.

Closes #111143

What is the new behavior?

When environmentService.remoteAuthority is set (remote/devcontainer context), the debug console link detector now:

For file: URI web links (createWebLink): Constructs a vscode-remote URI using the remote authority and checks if the file exists on the remote filesystem first. If found, opens from remote. Falls back to local filesystem if not found.
For absolute path links (createPathLink): Same approach — tries the remote filesystem first via vscode-remote scheme, falls back to local on failure.

This matches how the terminal already resolves file links in remote environments, as suggested in the maintainer comment.

Additional context

Only one file changed: src/vs/workbench/contrib/debug/browser/linkDetector.ts
Uses the existing Schemas.vscodeRemote and IWorkbenchEnvironmentService.remoteAuthority which are already imported/injected
The URI.from({ scheme: Schemas.vscodeRemote, authority: remoteAuthority, path: uri.path }) pattern follows established codebase conventions (e.g., promptFilesLocator.ts)
Preserves full backward compatibility — when not connected to a remote, behavior is unchanged
No new dependencies or imports required

…ontainers When connected to a remote (e.g., devcontainer), file: URIs and absolute path links in the debug console now check the remote filesystem first before falling back to the local filesystem. Previously, clicking a file:///path/to/file link in the debug console always opened it from the host filesystem, even when the file was on the remote. This aligns the debug console behavior with how the terminal already handles file links in remote environments. Closes microsoft#111143

Copilot

Pull request overview

Fixes Debug Console link resolution in remote/devcontainer windows by preferring vscode-remote resources when remoteAuthority is present, aligning behavior more closely with Terminal link handling (issue #111143).

Changes:

Update file: web-link handling to attempt opening the corresponding vscode-remote URI first, with local fallback.
Update absolute path link handling to stat/resolve remote paths first, with local fallback.
Refactor selection computation to avoid duplication when opening editors.

Comments suppressed due to low confidence (1)

src/vs/workbench/contrib/debug/browser/linkDetector.ts:333

In the remote branch, if stat(remoteUri) succeeds but the result is a directory, the code returns without decorating the link and without attempting the local uri fallback. This can cause a valid local file path to stop being linkified when a remote directory happens to exist at the same path. Consider treating isDirectory the same as “not found” and falling back to the local stat(uri) path.

			this.fileService.stat(remoteUri).then(stat => {
				if (stat.isDirectory) {
					return;
				}
				this.decorateLink(link, remoteUri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: remoteUri, options: { ...options, preserveFocus } }));
			}).catch(() => {
				// Remote file not found, fall back to local filesystem
				this.fileService.stat(uri).then(stat => {
					if (stat.isDirectory) {
						return;
					}
					this.decorateLink(link, uri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: uri, options: { ...options, preserveFocus } }));

Copilot · 2026-04-01T22:33:50Z

+				const remoteAuthority = this.environmentService.remoteAuthority;
+				if (remoteAuthority) {
+					const remoteUri = URI.from({ scheme: Schemas.vscodeRemote, authority: remoteAuthority, path: uri.path });
+					const existsRemote = await this.fileService.exists(remoteUri);
+					if (existsRemote) {
+						await this.editorService.openEditor({
+							resource: remoteUri,
+							options: { pinned: true, selection },
+						});
+						return;
+					}
+				}


fileService.exists(remoteUri) can still reject if withProvider(remoteUri) throws (e.g. scheme provider not available or transient remote disconnect). Since this is awaited without a try/catch, the click handler will throw and skip the local fallback, even when the local file exists. Consider wrapping the remote check in try/catch and falling back to the local fileUri on any error.

This issue also appears on line 322 of the same file.

Copilot · 2026-04-01T22:33:51Z

+		// When connected to a remote, try the remote filesystem first
+		// since the debug adapter likely produces paths from the remote host
+		// https://github.com/microsoft/vscode/issues/111143
+		const remoteAuthority = this.environmentService.remoteAuthority;
+		if (remoteAuthority) {
+			const remoteUri = URI.from({ scheme: Schemas.vscodeRemote, authority: remoteAuthority, path: uri.path });
+			this.fileService.stat(remoteUri).then(stat => {
+				if (stat.isDirectory) {
+					return;
+				}
+				this.decorateLink(link, remoteUri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: remoteUri, options: { ...options, preserveFocus } }));
+			}).catch(() => {
+				// Remote file not found, fall back to local filesystem
+				this.fileService.stat(uri).then(stat => {
+					if (stat.isDirectory) {
+						return;
+					}
+					this.decorateLink(link, uri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: uri, options: { ...options, preserveFocus } }));
+				}).catch(() => {
+					// If the uri can not be resolved we should not spam the console with error, remain quiet #86587
+				});
+			});
+		} else {
+			this.fileService.stat(uri).then(stat => {
+				if (stat.isDirectory) {
+					return;
+				}
+				this.decorateLink(link, uri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: uri, options: { ...options, preserveFocus } }));
+			}).catch(() => {
+				// If the uri can not be resolved we should not spam the console with error, remain quiet #86587
+			});
+		}


createPathLink performs fileService.stat(remoteUri) during linkification (render time) for every detected path when in a remote window, potentially doubling filesystem round-trips due to the local fallback stat(uri). In output-heavy debug sessions this can add noticeable latency. Consider deferring remote/local existence checks until click time (similar to createWebLink), or caching results to avoid repeated remote stat calls.

Suggested change

// When connected to a remote, try the remote filesystem first

// since the debug adapter likely produces paths from the remote host

// https://github.com/microsoft/vscode/issues/111143

const remoteAuthority = this.environmentService.remoteAuthority;

if (remoteAuthority) {

const remoteUri = URI.from({ scheme: Schemas.vscodeRemote, authority: remoteAuthority, path: uri.path });

this.fileService.stat(remoteUri).then(stat => {

if (stat.isDirectory) {

return;

}

this.decorateLink(link, remoteUri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: remoteUri, options: { ...options, preserveFocus } }));

}).catch(() => {

// Remote file not found, fall back to local filesystem

this.fileService.stat(uri).then(stat => {

if (stat.isDirectory) {

return;

}

this.decorateLink(link, uri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: uri, options: { ...options, preserveFocus } }));

}).catch(() => {

// If the uri can not be resolved we should not spam the console with error, remain quiet #86587

});

});

} else {

this.fileService.stat(uri).then(stat => {

if (stat.isDirectory) {

return;

}

this.decorateLink(link, uri, fulltext, hoverBehavior, (preserveFocus: boolean) => this.editorService.openEditor({ resource: uri, options: { ...options, preserveFocus } }));

}).catch(() => {

// If the uri can not be resolved we should not spam the console with error, remain quiet #86587

});

}

// When connected to a remote, prefer the remote filesystem first

// since the debug adapter likely produces paths from the remote host

// https://github.com/microsoft/vscode/issues/111143

const remoteAuthority = this.environmentService.remoteAuthority;

const remoteUri = remoteAuthority ? URI.from({ scheme: Schemas.vscodeRemote, authority: remoteAuthority, path: uri.path }) : undefined;

this.decorateLink(

link,

remoteUri ?? uri,

fulltext,

hoverBehavior,

async (preserveFocus: boolean) => {

const editorOptions = { ...options, preserveFocus };

if (remoteUri) {

try {

const stat = await this.fileService.stat(remoteUri);

if (!stat.isDirectory) {

await this.editorService.openEditor({ resource: remoteUri, options: editorOptions });

return;

}

} catch {

// Remote file not found or not accessible, fall back to local filesystem

}

}

try {

const stat = await this.fileService.stat(uri);

if (!stat.isDirectory) {

await this.editorService.openEditor({ resource: uri, options: editorOptions });

}

} catch {

// If the uri cannot be resolved we should not spam the console with error, remain quiet #86587

}

}

);

Copilot · 2026-04-01T22:33:51Z

+				// When connected to a remote, try the remote filesystem first
+				// since the debug adapter likely produces paths from the remote host
+				// https://github.com/microsoft/vscode/issues/111143
+				const remoteAuthority = this.environmentService.remoteAuthority;
+				if (remoteAuthority) {
+					const remoteUri = URI.from({ scheme: Schemas.vscodeRemote, authority: remoteAuthority, path: uri.path });
+					const existsRemote = await this.fileService.exists(remoteUri);
+					if (existsRemote) {
+						await this.editorService.openEditor({
+							resource: remoteUri,
+							options: { pinned: true, selection },
+						});
+						return;
+					}
+				}


New remote-resolution behavior (preferring vscode-remote resources and falling back to local) isn’t covered by the existing Debug Link Detector tests. Adding unit tests that stub environmentService.remoteAuthority, fileService.exists/stat, and editorService.openEditor would help prevent regressions (remote hit, remote miss -> local fallback, and error cases).

roblourens · 2026-04-01T22:57:37Z

This looks generally good but please take a look at Copilot's code review comments

Yogeshwaran C (yogeshwaran-c) · 2026-04-04T06:17:53Z

Addressed Copilot's code review feedback in d17b12b:

try/catch around fileService.exists(remoteUri) in createWebLink — Previously, if the remote scheme provider was unavailable (e.g. transient disconnect), the exists() call could reject and skip the local filesystem fallback entirely. Now wrapped in try/catch so the click handler gracefully falls through to local resolution.
Deferred remote stat in createPathLink to click time — Previously, fileService.stat(remoteUri) ran at linkification (render) time for every detected path in a remote window, doubling filesystem round-trips. Now the remote-vs-local resolution is deferred into the click handler callback via decorateLink(..., async (preserveFocus) => { ... }), eliminating render-time I/O for the remote case. The non-remote (local-only) path remains unchanged with its existing render-time stat approach.
Unit tests — Adding dedicated unit tests for the new remote-resolution behavior is deferred for a follow-up. The runtime behavior is now safe against provider failures in both code paths.

- Wrap `fileService.exists(remoteUri)` in try/catch in `createWebLink` so that a transient remote disconnect or missing scheme provider falls through to the local filesystem instead of throwing in the click handler. - Defer remote `fileService.stat()` in `createPathLink` to click time instead of render time, avoiding doubled filesystem round-trips during linkification for every detected path in remote windows.

vs-code-engineering Bot assigned roblourens Apr 1, 2026

roblourens requested a review from Copilot April 1, 2026 22:27

Copilot started reviewing on behalf of roblourens April 1, 2026 22:29 View session

Copilot AI reviewed Apr 1, 2026

View reviewed changes

Yogeshwaran C (yogeshwaran-c) force-pushed the fix/debug-console-file-links-remote branch from d17b12b to f8551e7 Compare April 6, 2026 16:33

Navigation Menu

Uh oh!

fix: resolve debug console file links to remote filesystem in devcontainers - #307244

fix: resolve debug console file links to remote filesystem in devcontainers#307244
Yogeshwaran C (yogeshwaran-c) wants to merge 2 commits into
microsoft:mainfrom
yogeshwaran-c:fix/debug-console-file-links-remote

Yogeshwaran C (yogeshwaran-c) commented Apr 1, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 1, 2026

Uh oh!

Copilot AI Apr 1, 2026

Uh oh!

Copilot AI Apr 1, 2026

Uh oh!

roblourens commented Apr 1, 2026

Uh oh!

Yogeshwaran C (yogeshwaran-c) commented Apr 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Yogeshwaran C (yogeshwaran-c) commented Apr 1, 2026

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

Additional context

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

roblourens commented Apr 1, 2026

Uh oh!

Yogeshwaran C (yogeshwaran-c) commented Apr 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants