Copilot Chat Tools Cannot Access Codespaces Filesystem (ENOPRO in Every New Code (Copilot)

[jonweberg]

Select Topic Area

Bug

Body

I’m experiencing a persistent issue where Copilot Chat’s tool layer cannot access the filesystem in any new GitHub Codespace, even though:

The Codespace is fully connected

The integrated terminal works

Commands like pwd, ls, pnpm install, etc. work exactly as expected

Older Codespaces (opened before ~Nov 10–12) do not have this issue

Issue Summary

Whenever Copilot Chat tries to execute any tool-driven file or terminal operation (even something as small as ls), it returns:

ENOPRO: No file system provider found for resource 'file:///workspaces/'

And:

The tool layer can’t access the filesystem

This occurs even though the workspace does exist at /workspaces/ and the integrated terminal can access it without problems.

Environment

GitHub Codespaces

Remote dev container

VS Code web + GitHub Copilot Chat

Occurs in every new Codespace

Does not occur in Codespaces that were opened prior to the issue

My terminal output shows a fully functional filesystem; only Copilot tools fail

What Appears to Be Wrong

Copilot tools appear to be attempting to access workspace files using:

file:///workspaces/

In a remote environment, the FS provider should correctly be:

vscode-remote://codespaces+/...

Tools appear to be bypassing the remote FS provider entirely → leading to ENOPRO.

This seems like a regression or an incorrect tools-layer routing inside Copilot Chat for Codespaces.

What I Have Already Tried

Reset VS Code user settings

Removed chat.* experimental keys

Turned off MCP / container / preview tools

Created a clean VS Code profile with only Copilot + Codespaces installed

Re-opened fresh Codespaces

Reinstalled extensions

Tried VS Code desktop instead of browser

→ The issue persists in every new Codespace, but never in old ones.

Expected Behavior

Copilot Chat tools should resolve workspace paths via the remote FS provider and be able to run commands through the integrated terminal, as they did previously.

Actual Behavior

Tools layer throws ENOPRO when accessing file:///workspaces/...

Terminal works fine

Code editing works fine

Copilot suggestions work

Only tool-executed filesystem access is broken

Request

Please escalate this to the Copilot Chat / Codespaces engineering team.

This appears to be a tools-layer filesystem provider regression affecting new Codespaces only.

I’m available to provide:

Logs

Codespace IDs

Live repro (takes <30 seconds)

Thank you!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[jonweberg]

I will pay money to someone who can help me fix this.

Bug

Body

I’m experiencing a persistent issue where Copilot Chat’s tool layer cannot access the filesystem in any new GitHub Codespace, even though:

The Codespace is fully connected

The integrated terminal works

Commands like pwd, ls, pnpm install, etc. work exactly as expected

Older Codespaces (opened before ~Nov 10–12) do not have this issue

Issue Summary

Whenever Copilot Chat tries to execute any tool-driven file or terminal operation (even something as small as ls), it returns:

ENOPRO: No file system provider found for resource 'file:///workspaces/'

And:

The tool layer can’t access the filesystem

This occurs even though the workspace does exist at /workspaces/ and the integrated terminal can access it without problems.

Environment

GitHub Codespaces

Remote dev container

VS Code web + GitHub Copilot Chat

Occurs in every new Codespace

Does not occur in Codespaces that were opened prior to the issue

My terminal output shows a fully functional filesystem; only Copilot tools fail

What Appears to Be Wrong

Copilot tools appear to be attempting to access workspace files using:

file:///workspaces/

In a remote environment, the FS provider should correctly be:

vscode-remote://codespaces+/...

Tools appear to be bypassing the remote FS provider entirely → leading to ENOPRO.

This seems like a regression or an incorrect tools-layer routing inside Copilot Chat for Codespaces.

What I Have Already Tried

Reset VS Code user settings

Removed chat.* experimental keys

Turned off MCP / container / preview tools

Created a clean VS Code profile with only Copilot + Codespaces installed

Re-opened fresh Codespaces

Reinstalled extensions

Tried VS Code desktop instead of browser

→ The issue persists in every new Codespace, but never in old ones.

Expected Behavior

Copilot Chat tools should resolve workspace paths via the remote FS provider and be able to run commands through the integrated terminal, as they did previously.

Actual Behavior

Tools layer throws ENOPRO when accessing file:///workspaces/...

Terminal works fine

Code editing works fine

Copilot suggestions work

Only tool-executed filesystem access is broken

Request

Please escalate this to the Copilot Chat / Codespaces engineering team.

This appears to be a tools-layer filesystem provider regression affecting new Codespaces only.

I’m available to provide:

Logs

Codespace IDs

Live repro (takes <30 seconds)

Thank you!

I will pay money to someone who can help me fix this.

[happySpartan]

Had the same behavior.

• I tried also turning off and on GitHub Copilot extensions
• Rebuilt the Codespace also completely, disabled a lot of extensions
• Tested different models, sign out/sign in in GitHub Copilot again

Nothing worked, but I deleted my Codespace completely and recreated a new one then it worked.
Not quite sure what did the trick, but at least it worked for me....

[chrisrosner]

I have tried deleting and recreating codespaces three times, and they all show this same behavior, does not fix for me.

[Gadgit83]

I'm having the same issue when in VSCode in Codespaces when Copilot tries to run a terminal command (this happens in multiple unrelated Codespaces, started about 2 days ago).

2025-11-15 22:10:57.243 [error] Error from tool run_in_terminal with args {"command":"npm run dev","explanation":"Running the development server to check if the fixes resolved the issues.","isBackground":true}: ENOPRO: No file system provider found for resource 'file:///workspaces/ProductDevReact': mEt@https://assets.github.dev/stable/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/out/vs/workbench/workbench.web.main.internal.js:8:153 j@https://assets.github.dev/stable/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/out/vs/workbench/workbench.web.main.internal.js:3870:100465

[afelainne]

Alguma solução? Estou tendo o mesmo problema desde ontem.

[chrisrosner]

It's still happening

[hydratweaks]

Yeah,the issues still persistting.....