GitHub Codespaces stuck at “Setting up your codespace” — multiple JavaScript assets return 404

[petrhollan22]

🏷️ Discussion Type

Bug

Body

Hi GitHub Community,

I’m experiencing an issue where multiple existing GitHub Codespaces are permanently stuck at “Setting up your codespace”. The browser-based VS Code editor never finishes loading.

This affects multiple Codespaces across different repositories, including private repositories.

Environment

• Platform: GitHub Codespaces (browser-based VS Code)
• Browser: Microsoft Edge 156 on Windows
• Date: November 7, 2026
• Affected environments: Multiple existing Codespaces

Technical findings

Browser Developer Tools (Network tab) shows multiple JavaScript assets failing with HTTP 404.

Example failing asset:

https://assets.github.dev/static/commons-bootstrap~pfHelper-index.js.c50a5df21e8e36ed835b.js

HTTP response:

• Status: 404 Not Found
• x-ms-error-code: WebContentNotFound
• x-cache: MISS
• server: Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
• Timestamp: November 7, 2026, 15:39 UTC

The Codespace startup logs indicate successful container initialization:

• Outcome: success
• devcontainer process exited with exit code 0
• Finished configuring codespace

This suggests the issue may occur during web editor initialization rather than container startup.

Troubleshooting already performed

1. Opened Codespaces directly from github.com/codespaces.
2. Tested Microsoft Edge InPrivate mode.
3. Switched to a mobile hotspot outside the corporate network.
4. Tested without the corporate network security connection.
5. Opened the failing JavaScript asset URL on an independent mobile device using cellular data — received the same HTTP 404.
6. Verified that DNS resolution and TCP connectivity on port 443 work.
7. Confirmed that multiple existing Codespaces are affected.

The issue persists across these tests.

Expected behavior

Existing Codespaces should load the browser-based VS Code editor successfully.

Actual behavior

The editor remains indefinitely at “Setting up your codespace”, while multiple required JavaScript assets return HTTP 404.

Questions

1. Is anyone else experiencing similar issues with Codespaces web editor initialization?
2. Could this be caused by missing JavaScript bundles, outdated client references, or a CDN/deployment issue?
3. Is there a safe workaround that preserves existing Codespaces and their uncommitted files?

I would prefer not to delete or rebuild the affected Codespaces because they may contain uncommitted work.

I can provide exact Codespace identifiers and additional diagnostic logs privately to GitHub Support if needed.

Thanks for any help!

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

[boncoinmail63-star]

Additional technical information — November 8, 2026

I am experiencing the same intermittent GitHub Codespaces startup issue. I have collected browser console logs from both failed and successful attempts, as well as a read-only diagnostic of the Codespace startup logs.

Environment (yes I know)

Desktop client

• Operating system: Windows 7, 64-bit
• Browser: Mozilla Firefox 115 ESR
• Access method: GitHub Codespaces through the browser (*.github.dev)

Mobile client

• Device: Samsung Galaxy S25+
• Operating system: Android
• Access method: GitHub Codespaces through a mobile browser

GitHub Codespace

• Region: West Europe (prod-rel-WestEurope)
• Machine: 2 vCPUs, 8 GB RAM, 32 GB disk
• Container environment: Linux, Bash, Docker
• VS Code Server commit: c4453f8ea430795f941c1b2ff6c9321135a74a02
• Codespaces web client version: 0.1.03538.974-72985115
• Codespace created on July 16, 2026
• Approximately 8.3 GiB of free disk space

The same Codespace worked normally before these recent issues.

1. JavaScript assets returning HTTP 404

When startup fails, Firefox reports 16 JavaScript files returning HTTP 404 from https://assets.github.dev/static/, including:

• commons-bootstrap~pfHelper-index.js.c50a5df21e8e36ed835b.js
• commons-bootstrap~pfHelper-sshSession.js.f114530228b51b28491f.js
• commons-bootstrap~pfHelper-authenticationService.js.85dd0c519e65c15f7d88.js
• commons-bootstrap~pfHelper-tunnelProvider.js.2cc8bbf6facd5dc0dd14.js
• bootstrap.63395acc36f7eb301b2c.js

Opening the last file directly returns HTTP 404 on both my desktop and mobile devices.

Clearing Firefox's cache and cookies has not permanently resolved the problem.

2. Intermittent startup failures

The Codespace frequently remains stuck on "Setting up your codespace", even when GitHub reports its state as Active or Available.

On two occasions, I managed to restore desktop access after reconnecting to the same Codespace from my Android phone and then performing a forced browser reload (Ctrl+F5) on my desktop.

Today, the mobile client initially reported a connection loss / fetch error. After reconnecting from mobile and refreshing the desktop browser, the Codespace worked again.

I cannot determine whether the mobile reconnection actually triggered recovery or whether this was coincidental.

3. Comparison with a successful startup

During a successful startup on November 8, the previously observed 16 HTTP 404 errors were absent from the browser console.

The SSH tunnel was successfully authenticated, the WebSocket connections returned HTTP 101 Switching Protocols, and the Codespace reached the Connected state.

However, several errors remained:

Cannot resolve asset URLs before connection to cloud environment is established.

Content-Security-Policy blocked extensionHostWorkerMain.js.

Extension host (LocalWebWorker) terminated unexpectedly. Code: 81

Timed out waiting for authentication provider 'github' to register.

LocalStorageKeychain Error: Failed to get cipher record.

The successful web client initialization reported approximately 33 seconds across its measured startup phases.

4. Codespace startup diagnostics

A read-only investigation of the Codespace's internal logs identified an unexplained interval of 6 minutes and 27 seconds between the estimated Linux machine boot time and the first recorded Codespaces configuration activity.

Once configuration started, the recorded operations were relatively fast:

• Devcontainer startup/configuration: approximately 5 seconds
• VS Code Server preparation: approximately 9–12 seconds
• No current memory exhaustion or disk-space exhaustion detected

The available logs do not identify what caused the initial unexplained delay.

5. Request for investigation

Could the GitHub Codespaces team please investigate:

1. Why the web client intermittently requests JavaScript assets that return HTTP 404 from assets.github.dev.
2. Whether this is related to a deployment, asset-version mismatch, CDN caching issue, or web-client initialization problem.
3. Why the Codespace can be reported as Active/Available while the browser remains stuck on the startup screen.
4. Whether the unexplained delay before container configuration can be traced through GitHub's infrastructure logs.

I can provide redacted browser console logs and Codespaces startup logs if necessary.

Important: This Codespace contains uncommitted and untracked development files, local Codex sessions, and other persistent data. Please do not rebuild, reset, or delete the Codespace without my explicit approval.

[Emeliocp]

I reproduced the same startup hang on November 8–9, 2026. My existing Codespace stalled on “Setting up your codespace” in Chrome and the ChatGPT in-app browser, and I saw the same behavior on a second laptop. Restarting the existing Codespace did not resolve it.

For a clean reproduction, I created a fresh 2-core Codespace from GitHub’s official Blank template at github.com/codespaces. The dashboard showed it as Active, but the web editor stayed on the setup screen even after a refresh. The test had no project-specific setup. My personal Free account had included compute and storage remaining, and GitHub Status showed Codespaces as operational when I checked.

I haven’t independently confirmed the JavaScript 404s in the original report. Is there a diagnostic that would help determine whether the Blank-template hang has the same cause?

[Vinaglieri]

+1