Codespaces Web: intermittent ENOPRO “No file system provider found for resource file:///workspaces/…” breaks programmatic terminal execution #186015
Replies: 3 comments 1 reply
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed repro — this looks like a Codespaces web / VS Code FS provider desync, not a repo-specific issue. A few things worth trying / confirming (if you haven’t already): Disable all extensions (including Copilot) temporarily and test whether the ENOPRO still appears via programmatic runs. This helps confirm whether the command is being executed before the workspace FS provider fully re-registers after reload. Check Developer Tools → Console in the browser for errors related to vscode-file or workspace fs right after Developer: Reload Window. I’ve seen cases where the web FS provider fails to reattach cleanly. As a workaround, avoid Reload Window and instead Stop Codespace → Start Codespace when the issue appears. Not ideal, but it tends to reinitialize the FS provider reliably. If possible, compare behavior with VS Code Desktop + Codespaces — if it does not reproduce there, that strongly points to a web-only regression. Given the intermittent nature and the ENOPRO error, this feels like a race condition in the web Codespaces FS provider lifecycle affecting extension-driven terminal execution. Subscribing — I’m seeing similar flakiness in browser Codespaces with automation tools. |
Beta Was this translation helpful? Give feedback.
-
|
I did attempted to remove extension and seems like they are getting added somehow. So inserted script after rebuild to supress them and got it to point i dont see extensions installed. I do not get enopro errors on terminal but copilot do get in just 3rd attempt onwards. I see below error on 'Extension Host Remote' which is strange. 2026-01-31 15:36:04.168 [info] ExtensionService#_doActivateExtension GitHub.copilot-chat, startup: false, activationEvent: 'onChatParticipant:github.copilot.editsAgent' 2026-01-31 15:36:28.647 [info] ExtensionService#_doActivateExtension vscode.npm, startup: false, activationEvent: 'onTerminalQuickFixRequest:ms-vscode.npm-command' |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
Bug
Body
Product: GitHub Codespaces (VS Code in browser)
Plan: Pro+
Summary: In Codespaces opened in the browser, programmatic command execution (e.g., “run in terminal” invoked by tools like Copilot / extensions) intermittently fails with ENOPRO: No file system provider found for resource 'file:///workspaces/'. The integrated terminal typed commands continue to work. Issue returns after reloads and sometimes after 1–N successful commands.
Exact error:
ENOPRO: No file system provider found for resource 'file:///workspaces/WAOOAW'
Repo: dlai-sd/WAOOAW
Steps to reproduce:
Expected: Programmatic terminal runs should consistently work.
Actual: ENOPRO indicates file system provider missing for a normal workspace URI.
Troubleshooting already attempted:
Impact: Breaks Copilot/automation workflows; prevents reliable command execution in browser Codespaces.
tried chrome, firefox, firfox private etc
Beta Was this translation helpful? Give feedback.
All reactions