Regarding an Issue with Workspace Path Resolution and Storage Mount Inconsistencies When Starting GitHub Codespaces

[yoshiaki-ambient]

Select Topic Area

Bug

Body

Consultation Items (Regarding Mitigation and Handling)

Based on the observations and assumptions described above, we would appreciate your guidance on the following points:

• When this issue occurs, are there any checks or troubleshooting steps that users can perform on their side?
  (For example, ways to determine whether the correct workspace and storage are properly mounted.)
• If a Codespace starts with an incorrect workspace or mount target, is there a recommended procedure to restore it to the correct state?
• If a Codespace starts up with storage downgraded to the minimum configuration, should that Codespace continue to be used, or is recreating the Codespace the recommended approach?
• If there are any recommended operational practices or best practices to avoid encountering this issue, please let us know.

This issue does not appear to be something that can be clearly reproduced or avoided through user actions alone, and it has a significant operational impact.
Therefore, we would greatly appreciate an official perspective and any recommended mitigation or handling procedures from GitHub Codespaces.

An inquiry that was sent to me within our company.

Specifically, when starting an existing Codespace, it does start up, but all of the work content has been lost, and the storage capacity has changed to the minimum configuration below the specified specs (so minimal that no extensions can be installed at all).

In addition, when performing a Rebuild, an error saying “workspace does not exist” occurs, and if you Rebuild again it does start up (during this time, it is still shown on the Codespaces list page and the Codespace ID does not change), but it starts up with the issue unresolved.

Normally, a Codespace is created with 32 GB of storage allocated and work proceeds in that state, but once it enters the above condition, the maximum capacity suddenly becomes something like 8 GB, and it starts with the used space already at around 7.9 GB. At this point, all work content has already been lost (so data salvage is not possible).

I suspect this is a bug in Codespaces (for example, storage information tied to the specific Codespace instance is managed somewhere, but without notice it gets changed to non-existent storage information; when the Codespace starts it tries to reference that storage, but since it doesn’t exist, it allocates a very small storage area and starts anyway).

Storage capacity was checked using df -h, for reference.

My assumption

I believe this issue is highly likely to be caused by an inconsistency in the workspace resolution process and the storage mounting process in GitHub Codespaces.

We have been intermittently observing similar behavior for approximately one month prior to this incident. However, at the time, we did not treat it as a critical issue for the following reasons:

• In some cases, the issue resolved itself after leaving it for a certain period of time.
• There was no clear reproduction procedure, and it was judged to be a temporary malfunction.

However, on 2026-02-18 and 2026-02-19, reports of encountering the same issue were raised simultaneously across multiple environments and by multiple team members. Based on this, we concluded that this is not an isolated or incidental problem, but rather a defect that is likely occurring widely and persistently.

View on the “Workspace does not exist” Error

Regarding the “workspace does not exist” error, similar to issues reported in existing GitHub Issues, it is possible that this is caused by VS Code opening a directory path that differs from the intended workspace path.

Under normal circumstances, a Codespaces-specific workspace directory such as ./workspace/** should be opened. However, due to some influence, if ./** (the root directory or another incorrect path) is opened instead, the following behavior may occur:

• The workspace is recognized as non-existent
• The Git repository cannot be found, making it appear as though all work content has been lost

In fact, in this state, there are cases where the issue can be temporarily resolved by manually reopening the correct workspace directory within VS Code.
Additionally, the fact that the issue sometimes resolves itself after some time is consistent with behavior caused by retries or delays in mount or initialization processes.

Relationship with the Storage Capacity Downgrading Issue

We also believe that the phenomenon where storage—normally allocated at 32 GB—suddenly drops to a minimum configuration of around 8 GB and starts up in an almost full state (e.g., 7.9 GB / 8 GB as shown by df -h) is strongly related to a failure in mounting the persistent storage that should normally be attached.

More specifically, the following sequence may be occurring:

• The original persistent storage fails to mount for some reason
• In order to avoid failing the Codespace startup entirely
• The system falls back to allocating a minimal temporary storage volume and proceeds with startup

In this scenario, because the mount target itself differs from the expected one, the following symptoms are likely to occur simultaneously:

• Git work content appears to be missing
• Extensions cannot be installed
• All work content appears to have been lost

This aligns well with the observed behavior in the affected environments.

[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. ⭐