Unable to resolve workspace folder in ExtHost sessions (ENOPRO: No file system provider found for resource 'unknown:/')

[TylerLeonhardt]

Problem

When hovering over a newly created folder, the following error appears:

/ • Unable to resolve workspace folder (ENOPRO: No file system provider found for resource 'unknown:/')

Additionally, the file system isn't visible at all.

Context

• This appears to happen only in ExtHost sessions. Agent Host sessions load the filesystem properly.

Steps to Reproduce

1. Open or create a folder in an ExtHost session within VS Code
2. Hover over the newly created folder

Observed behavior

• Error message as above
• File system is not accessible

Expected behavior

• Workspace folder should resolve normally
• File system should be accessible

Does this issue occur when all extensions are disabled?: (unknown)

• VS Code Version: (unknown)
• OS Version: (unknown)

This issue was reported based on user feedback discussing unexpected behavior when working with ExtHost sessions.

View original Slack conversation

[guybkh]

@sandy081 , I think I may be hitting the same issue as @TylerLeonhardt after updating to VS Code 1.122.0 (build 6a49527, Windows 11).

In my case the error occurs in two specific scenarios:

1. Relative folder paths in a .code-workspace file - paths like ../../../../../Dev/Code/scripts now resolve to unknown:/ instead of the real disk path.

2. A .code-workspace file with "folders": [] - the Copilot-managed agent-sessions.code-workspace uses an empty folders array, which causes VS Code to assign unknown:/ as the CWD for terminal creation and git operations. This cascades into Copilot agent failures (No conversation found with session ID, Query closed before response received).

Both scenarios produce the same ENOPRO: No file system provider found for resource 'unknown:/' error. Converting relative paths to absolute paths does not resolve the issue when an empty folders: [] workspace is also open.

Additional pattern: When opening a repo and running an agent query, the first execution succeeds but the second fails with the same unknown:/ error. This suggests the session is created successfully but cannot be resumed because it was stored against the unknown:/ workspace context.

This is a regression, it worked before v1.122.0.