GitHub Codespaces Not Connecting: What to Check

For GitHub Codespaces not connecting, first confirm that the codespace belongs to you and can start, then compare the browser and desktop connection to that same environment. A reachable repository page does not prove that its development session works, and a connection error does not justify rebuilding the container.

Key Takeaways:

• Separate codespace state, account access, client transport, and work inside the cloud container.
• Keep the environment and account fixed while comparing browser and desktop behavior.
• Use current official connection-domain information rather than a guessed allowlist.
• A local route change does not move the codespace or reroute its dependency downloads.

Step 1: What does GitHub Codespaces not connecting mean here?

Save local changes and identify the existing codespace by its owner, repository, and environment name. Record whether it is stopped, starting, running, or unavailable, along with the exact message and time. Do not infer that it was deleted because a bookmarked editor URL fails.

Return to the Codespaces list under the intended account. GitHub's connection guidance distinguishes stopped environments and owner access from browser transport problems.［1］ If the environment is missing, check your account and ownership first. A repository collaborator does not automatically own somebody else's personal codespace.

Use the device and application troubleshooting framework if several unrelated local applications are failing. For GitHub web, API, or Git operations outside the development session, use the developer operation access checklist. Keep those observations separate from Codespaces results.

This diagram is an execution map, not an observed account state. The browser or desktop client runs locally; commands entered in the codespace terminal run in the cloud environment. A successful connection on one side does not measure traffic leaving the other.

Step 2: Is the codespace stopped or unable to start?

A 503 message can appear when you interact with a stopped codespace. GitHub documents using the available Start action and reloading the client, so do not label every 503 as a firewall block.［1］ If a start action is offered, use it once for the intended environment and observe whether the state progresses.

Record an explicit start failure separately from a running environment that the client cannot reach. A message about usage allowance, organizational policy, or repository access needs its own owner. Do not keep switching networks while an account or resource decision remains unresolved.

If creation or startup fails, preserve the relevant creation evidence before any restart or rebuild. Creation logs and session logs cover different stages.［2］ Rebuilding may rerun setup and change the environment; deletion can destroy files that were never committed or copied elsewhere. Neither is a sensible first experiment for a connection-only symptom.

Do not assume that a stopped environment lost its workspace, or that a restart preserves every running process. Before changing lifecycle state, save what the interface permits and follow your team's persistence policy. This article investigates an existing authorized session; it does not claim that every failed environment is recoverable.

Step 3: How do browser and desktop clients differ?

Attempt the same codespace from its list entry in the intended browser. If that fails, try another supported browser without changing the account or environment. GitHub recommends this browser comparison and separately documents desktop-extension connection issues.［1］ Record whether failure happens before the editor, during loading, or after an interactive session begins.

For VS Code desktop, confirm that the Codespaces extension uses the intended GitHub account and note the editor and extension versions. Check its own connection output. A working browser session with a failing desktop session narrows the investigation toward client configuration; it does not identify one definite proxy or certificate cause.

Do not erase all browser cookies as an opening move. When evidence points to authentication, use the normal sign-out and sign-in flow for the relevant account, knowing that session changes can affect other open work. Preserve the original error first. Never copy cookies or tokens from one client into another.

This English-language image is an official interface illustration, not a screenshot of your account or a reproduced outage. It helps locate the client choice for the same codespace; the available menu and labels depend on your interface. Do not select another environment merely because its name resembles the failing one.［3］

Observation	What you can conclude	What remains unverified
Environment does not start	Lifecycle or access step failed	Client transport to a running session
Browser works, desktop fails	One client reached the same environment	Desktop account, extension, and local path
Both clients fail while environment runs	Failure is reproducible across clients	Service incident, local policy, and authentication
Editor opens but terminal freezes	Initial session was established	Continuing transport and cloud processes
Terminal works but a download fails	Interactive operation passed	Cloud outbound request and its permissions

If the client opens JupyterLab but cannot communicate with a kernel, follow the remote Jupyter channel checks. The environment's presence does not prove that the chosen image has the needed Jupyter components. Treat application availability and a working kernel as additional checkpoints.

Step 4: What evidence belongs to Codespaces connection troubleshooting?

Choose Codespaces connection logs that match the failure. GitHub documents creation logs, codespace logs, desktop extension logs, and browser console logs.［2］ A creation log is useful for provisioning; a browser console observation is useful for that browser's failed request. Neither supplies a complete diagnosis of every client.

In an accessible VS Code session, use the Command Palette and the documented Codespaces: Export Logs action to obtain session logs.［2］ Keep the archive private. Before sharing an excerpt, remove account identifiers, repository names where necessary, workspace paths, signed URLs, tokens, and personal data.

Where a firewall rejection is recorded, provide the network administrator with the current official Codespaces domain information. GitHub's documented read-only command retrieves the required domain group from its metadata API:［1］

gh api meta --jq .domains.codespaces

Run it only in your approved GitHub CLI context. This command obtains information; it does not grant access, update a firewall, or prove that a session works. Do not disable endpoint protection or add broad wildcard exceptions yourself. Let the responsible owner decide whether and how the required connections are permitted.

Certificate warnings require a trust investigation. Use the certificate and clock troubleshooting guide for the local client, keeping TLS checks active. SSO or organization restrictions are authorization boundaries; a different public exit must not be used to evade them.

Step 5: Can you compare an approved local network route?

Proceed only if the codespace is authorized, able to run, and the failure concerns transport from your own supported computer. Ask the organizational owner before using a consumer VPN on a managed device. A mandatory enterprise proxy remains part of the connection unless its owner approves a change.

To compare access to the same cloud editor with AethoVPN, use Pro or Premium with the official Windows client or Debian/Ubuntu x64 .deb; a Mac needs configuration from the official guide with the same tiers. Select an available suitable nearby or home-country location in the App, connect, and enable global mode locally. Reopen the same codespace through the client that failed, then check editor loading and a harmless terminal interaction separately.

Keep browser, account, codespace, and workspace fixed. Start a fresh client connection so that an already open session does not supply a misleading success. A browser-versus-desktop difference should still be recorded using the application route comparison, not flattened into “GitHub works now.”

The local tunnel does not move the cloud environment, increase its allowance, or change its repository and SSO authorization. For a first permitted connection comparison, create an account to begin the 3-day Pro trial; the once-per-user trial starts when you register.

Use the local VPN verification steps before assessing the session. Finish the comparison inside Codespaces: an editor that opens but loses its terminal immediately has not passed the interactive task. Record failures as failures and stop changing locations when the same evidence repeats.

Step 6: Does cloud work continue after the editor connects?

Once connected, open an existing nonsensitive file and use a harmless terminal command such as pwd to confirm an interactive response. Do not run a deployment, force-push, or dependency installation just to test connectivity. The terminal is executing in the cloud, so a subsequent package download uses that environment's own path.

If interaction remains responsive while a cloud command times out, investigate the cloud-side request and its permissions. Do not claim a laptop route change repaired cloud egress. A resource-constrained process or failed container setup likewise needs the environment owner rather than repeated local client reinstalls.

For intermittent loss, record whether it follows inactivity, client sleep, a specific action, or a repeating elapsed interval. Match the times to the appropriate private logs and service information. Correlation is useful evidence, but a single reconnection is not a measured uptime or performance improvement.

Use the workplace VPN policy boundaries when deciding who can approve a different route. If the authorized checks do not resolve the symptom, send support the environment identifier privately, versions, failed client, lifecycle state, and sanitized timestamps. Preserve work before following any suggested rebuild.

Summary

• Verify the intended account, ownership, and running environment first.
• Compare browser and desktop clients without changing the codespace.
• Choose logs that correspond to the failed lifecycle or connection stage.
• Keep certificates, SSO, and managed network policy intact.
• Validate interactive cloud work separately from cloud downloads.

FAQ

Does a 503 always mean the network blocks Codespaces?

A stopped codespace can produce a 503 response. Check its lifecycle state and offered Start action before attributing the failure to a network restriction.［1］

Can I open another user's codespace if I share the repository?

Repository collaboration and ownership of a personal codespace are distinct. Confirm the intended account and environment rather than treating collaboration as session access.［1］

Should I rebuild before checking the client?

Rebuilding changes more than the connection and can rerun setup. Preserve files and logs, then distinguish a lifecycle failure from client transport before rebuilding.

Why does the browser work while desktop VS Code fails?

The clients have different account, extension, and configuration contexts. Compare their evidence for the same codespace rather than assuming identical paths.

Does a local VPN change the codespace region?

Changing the laptop's exit does not relocate the cloud environment. Treat its region and cloud-side requests as separate from the client connection.

Where should I look for a creation error?

Use the relevant creation log for startup or provisioning failures. Session and browser logs cover different stages and cannot substitute for that evidence.［2］

Can I share the exported logs publicly?

Review and redact them first because they can contain private account, repository, path, and connection information. Prefer your organization's approved support channel.

Disclaimer: Diagnose only environments you are authorized to use and respect local laws, organizational access controls, and resource limits. No availability or performance result is claimed.

Sources:

1. GitHub Docs — Troubleshooting your connection to GitHub Codespaces — https://docs.github.com/en/codespaces/troubleshooting/troubleshooting-your-connection-to-github-codespaces
2. GitHub Docs — GitHub Codespaces logs — https://docs.github.com/en/codespaces/troubleshooting/github-codespaces-logs
3. GitHub Docs — Opening an existing codespace — https://docs.github.com/en/codespaces/developing-in-a-codespace/opening-an-existing-codespace

Sources checked 7 October 2026.

---

Related Articles:

• Inspect the remote Notebook kernel channel
• Separate GitHub developer operations
• Check workplace network authorization
• Verify the local connection before testing Codespaces