Skip to content


Subscribe to all “codespaces” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

We’re excited to announce an important upgrade to the Codespaces connection infrastructure. Our team has been working to enhance the security, reliability, and overall performance of both the main connection and port forwarding features.

What’s Changing

To support these enhancements, we require the addition of * to be allowlisted for your firewall rules. This is a crucial step to ensure a seamless and secure experience with Codespaces.

Release Plan

Today we are going to enable you to opt into this new connection system through the Feature Preview section on This feature flag will be an opt-in flag for two weeks to enable you to test these changes against your own firewalls.

In two weeks we will turn on these changes as a default. Users can opt out of using this new connection system for 30 days under the same feature flag. Customers who need more time will be able to request extra time through GitHub Support.

After 30 more days we will move everyone over to our new connection system.

Your Action Needed

Ensure that * is allowlisted under your firewall rules.

Enable the feature flag under to test these changes out yourself, as well as to ensure these domains are added to your firewall rules promptly to maintain uninterrupted access and optimal functionality of Codespaces.

If you’re having any issues, read our firewall troubleshooting guide.

We appreciate your cooperation and understanding as we continue to improve your experience with Codespaces. If you have any questions or need assistance, our support team is here to help.

Thank you for being a valued member of the Codespaces community.

See more

GitHub Codespaces recently promoted the current beta host image configuration to stable as part of our regular maintenance for our hosts. This change includes multiple minor version updates, as well as major version updates to the Docker engine and Docker Compose packages installed on the host. This will not impact most development container configurations.

For more details about the specific changes, see our documentation regarding host image configurations here.

If you have any issues, please contact support.

Additional Resources

See more

GitHub Codespaces will promote the current beta host image configuration to stable on 16 January as part of regular maintenance for hosts. This change includes major version updates to the Docker engine and Docker Compose packages installed on the host as well as several minor version updates. These changes should not impact development container configurations.

If your dev container depends on Docker compose, please test the beta image to ensure that your dev container does not require changes. For more details about the specific changes, see our documentation regarding host image configurations here. You can test the beta host configuration with your own codespaces by selecting the beta host image in your personal settings.

Additional Resources

See more

GitHub Codespaces recently released multiple updates to improve visibility into monthly spend:

  • Organization administrators whose organization's codespace usage is paid for by the enterprise can now see month-to-date spending in their organization, even though their organization is not directly paying for this usage.
  • All organization administrators with access to billing reports can now see projected codespaces spend in the month. This calculation is an estimate based on the past seven days of codespace usage.

org admin billing screen with projected usage

With these improvements, organization administrators can get a better sense of how large of a bill they can expect to pay at the end of the month, and remain aware of how much they are billing back to their enterprise.

Additional Resources

See more

A GitHub codespace is a development environment provided by a container that runs on a virtual machine (VM). The development environment that the developer works within is defined by the dev container configuration. The VM configuration defines the operating system which builds and runs the dev container. GitHub maintains this VM configuration, and regularly upgrades it to improve security, functionality, and performance.

While our regular security patching does not impact capabilities, occasionally we need to upgrade components that may have an impact on the way the container environment functions in certain cases. Therefore, we are introducing a way to opt into the beta image configuration, allowing you to test the changes in your specific environments and provide feedback before we ship the changes to the stable image.

host image preference screenshot

The upgraded host image is initially made available as a beta release, which enables you to ensure your existing dev container configurations are compatible with the next iteration of the VM configuration. Once enabled, all newly created or resumed codespaces will use the specified host configuration. This enables you to test your configurations without impacting other developers who use the same dev container. You may switch between the beta and stable host configurations at any time. Whenever you switch, all of your subsequently created or resumed codespaces will receive the configuration you specified. Changing this setting does not impact currently running codespaces.

Additional Resources

See more

In the upcoming days, Codespaces will be adding the Australia region to prebuild configurations under region availability. This will enable users to have prebuilds specifically in Australia.

How do I get access to Prebuilds in the Australia region?

If you would like to have Australia selected as a region, go to your prebuilds and select the Australia region.

What if I already have all regions selected for my Prebuilds?

If you have all regions currently selected you will have all regions except for Australia selected once this change is implemented. This will be change to ensure users do not get billed in a region they do not want.

If you would like to have all regions, including Australia, selected, please go to your prebuilds and select all regions again.

What if I am already using the Southeast Asia as a region?

Prebuild configurations with Southeast Asia already selected as a region with users in Australia may experience decreased codespace creation time as Australia will now be a separate region from Southeast Asia. To continue to get improved codespace creation time, add Australia as a region under region availability.

Please contact support if you have any issues.

See more

On December 21st, 2023 GitHub Codespaces plans to remove the deprecated Repository Access and Security setting.


Rather than configuring cross-repository access at the account level, we now recommend declaring cross-repository dependencies and permissions directly within your devcontainer.json. This approach enables each development container to declare its own minimum set of permissions to operate, rather than allowing unrestricted access to other repositories your account can access.

This change will impact users and organizations that have set the Repository Access and Security setting to either selected or all repositories, and have not configured any development container level permissions. You will receive an email if you or any organizations you own may be impacted by this change.

To ensure continuity of usage, you will need to declare cross-repository permissions within each devcontainer.json, enabling access to each repository that a development container needs to access. You can test that you have successfully transferred all permissions by toggling the Access and Security setting to Selected Repositories and removing all entries once you have completed the conversion.

Please reach out to GitHub Support if you have any issues or questions.

Additional References

See more

GitHub is no longer admitting new users or organizations to the limited beta for GPU-powered Codespaces due to limited capacity for this virtual machine type. Existing beta participants will be able to continue using these machine types, however no new users on the current waitlist will be granted access. For any updates on features we’re working on and what stage they’re in, please follow the GitHub public roadmap.

See more

What would you do with twice the memory on your computer? How about 30% better CPU performance?

We’ve leveled you up!

Over the past six weeks we’ve upgraded underlying infrastructure for Codespaces, migrating from Intel to AMD based CPUs, which boast improved specs.

As of today, 4-core and higher Codespaces now include twice the RAM, and 30% better CPU performance, at no additional cost to you. You now get snappier performance and more room for your processes to stretch out without having to lift a finger. We’ll be rolling out the same upgrade for the 2-core Codespaces in a matter of days.

Save money

If you’re using an 8-core machine because you need the RAM, now you can save cost by backing that down to a 4-core machine so you get twice the bang for the buck. Same goes for scaling down from 4 to 2 cores, and so on. Because free usage of GitHub Codespaces is calculated by cores per hour, using a smaller machine will also give you more free coding hours.

Now your GitHub Codespaces cloud dev environment builds, tests, and shares your running application faster than ever, at the same price.

Note: this release does not affect the machines used in the generation of Codespaces prebuilds.

Give ‘em a spin!

See more

GitHub Codespaces has introduced new access and ownership settings, providing organizations more granular control over which members and outside collaborators are able to create codespaces on organization-owned private and internal repositories.

Screenshot of an organization's Codespaces settings page. Sections titled “Codespaces access” and “Codespaces ownership” contain radio buttons for various options.

Owners of organizations on the Team or Enterprise plan can now select which of their organization's members or collaborators are allowed to use GitHub Codespaces on organization-owned private and internal repositories. In order to use GitHub Codespaces, an organization member or collaborator will need explicit access to GitHub Codespaces and either write or fork permissions on the repository.

Any members or collaborators not explicitly granted access will not be allowed to use GitHub Codespaces within the organization's private or internal repositories. Those members or collaborators may still use codespaces on public repositories owned by the organization, like any other GitHub user.

Screenshot of the Codespace ownership settings section, with radio buttons labeled “Organization ownership” and “User ownership.”

Additionally, organization administrators can select whether member or collaborator codespaces fall under organization or user ownership. Codespaces ownership dictates who pays for a codespace, which policies are applied, and where audit logs from codespace usage are sent. For organization owned codespaces, the organization pays for the codespace, organization policies apply, and the logs are sent to the organization. For an organization to own any codespaces, the organization administrator will need to set a spending limit in order to enable GitHub Codespaces within their organization. Enterprise Managed Users are not able to create user owned codespaces because their usage must be paid for by the enterprise.

Additional Resources

See more

Codespaces is updating the domain used for forwarded ports

Starting in August, Codespaces will be updating web client port forwarding to improve security, reliability, and performance for users. As part of this update, the URL for forwarded ports will change from https://* to https://*

To prepare for this change, replace any hardcoded references to in your code with the GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN environment variable by July 31 to avoid any disruptions. The environment variable value will be updated from to when the migration completes. Learn more about environments variables here.

See more

Organization administrators can now specify the maximum number of organization-billed codespaces that any member of the organization, or collaborator, can create.

By default, without this new policy, if organization members or collaborators are permitted to create codespaces that are billable to your organization, they can create multiple such codespaces. The number of codespaces someone can create is governed by a limit to the total number of codespaces that they can create across all repositories they can access. This limit is set by GitHub. With this new policy you can now control the maximum number of organization owned codespaces someone can create.

When this policy is applied to an organization, members or collaborators who meet or exceed this limit will be unable to create new codespaces that are billed to the organization. In order to create a new organization-billed codespace, they must first delete existing codespaces owned by the organization to get below the specified limit. The maximum codespaces policy does not impact user-billed codespaces, or codespaces created on repositories that are not owned by the organization. The policy must be applied across the entire organization, and cannot target specific repositories.

This policy, especially when combined with the existing retention period and idle timeout policies, provides organization administrators new ways to control cost within their organization, while encouraging best practices around cleaning up codespaces that are no longer in use.

To get started, review the documentation for how to apply a maximum codespaces per user policy within your organization.

Additional Resources

See more

GitHub Codespaces plans to begin rolling out improved access controls for organizations on June 27th, 2023. These changes will provide organizations additional control over which of their organization’s members or outside collaborators are allowed to use GitHub Codespaces on private and internal repositories. This change will not affect public repository usage.

Today, any user with read access to an org-owned private or internal repository can create a codespace from that repository. The organization may elect not to pay for this Codespace usage, but currently there is no way to block the usage entirely. Starting June 27th, GitHub Codespaces will begin introducing additional Access, Billing, and Ownership settings to more granularly control this behavior. With these new settings, organization admins can decide who within the organization is allowed to create codespaces from private and internal organization-owned repositories, and who owns those created Codespaces:

Some codespace usage may be impacted by this change. Organization owners will receive an email if anyone in their organization has a codespace that will be deleted because it was created from a private or internal repository by an org member or collaborator who will not have the appropriate permissions after this change.

Will I be impacted by this change?

This change will impact organizations that have configured their organization’s billing settings to either “Selected members” or “All members”. If your organization has specified one of those options, members or outside collaborators who are not specified in the list of selected users will lose access to GitHub Codespaces created from impacted internal or private repositories.

Administrators will receive a separate email if anyone in their organization has a codespace that matches these criteria.

What should I do if I am impacted?

Organization administrators should review the list of specific users who are currently allowed to bill codespaces usage to their organization to ensure all members who should have access, continue to have access. This can be done by adding them to the existing billing setting before your organization migrates to the new access setting.

Adding new users to this list will automatically transfer codespace ownership to the organization for any existing, personally owned codespaces created by these users on organization owned repositories. Once this happens, these codespaces will no longer be impacted by this change. Before doing this, ensure your spending limit is properly configured.

Users with impacted codespaces should either push any unsaved changes from these codespaces, or export their changes to a new branch. This will ensure that no code is lost as part of this change.

What will happen to existing codespaces impacted by this change?

Codespaces impacted by this change will become inaccessible when the updates are released, and will be permanently deleted 7 days after that.

Details about the change

Today, any organization member or outside collaborator with read access to a repository can create a codespace on that repository. While the organization may elect not to pay for this usage, the member or outside collaborator can still pay for their own usage.

This release will introduce two control mechanisms for access and ownership.

Access will control which users are allowed to create codespaces on private and internal repositories within your organization. There will be four options:

  • Disabled: Codespaces are not enabled within the organization’s private and internal repositories.
  • Specific members: The organization can select specific members who are allowed to create codespaces on the organization’s private and internal repositories.
  • All members: Any full member of the organization is allowed to create codespaces on the organization’s private and internal repositories.
  • All members and outside collaborators: Anyone associated with your organization (full member or outside collaborator) is allowed to create codespaces on the organization’s private and internal repositories.

Ownership and Billing controls who pays for codespace usage, who receives the audit log events from codespace usage, and whose policies are applied to the codespaces. There will be two options:

  • Organization owned: All codespaces created by organization members for organization-owned repositories will be owned by the organization, send events to the organization’s audit log, and apply the organization’s codespace policies.
  • User owned: All codespaces created by organization members on organization-owned repositories will be owned by the creating user, send events to the user’s security log, and apply the user’s codespace policies.

Please contact support if you have any issues.

Additional Resources

See more

In the coming week, GitHub will upgrade the host operating system for the virtual machines that build and run the dev containers in GitHub Codespaces from Ubuntu 18.04 to Ubuntu 22.04. Ubuntu 18.04 will reach its end of standard support on May 31, 2023, so we are upgrading in order to maintain the highest quality of support and security for all development environments. Most users will not be impacted by this update.

The host virtual machine is responsible for building and running the dev container configured in the devcontainer.json. When a developer connects to a codespace, they connect directly to the dev container, whose operating system is defined by the devcontainer.json configuration. This maintenance upgrade will not impact the development container configuration or prebuilds, and will not require any package updates within the development environment itself.

We recommend decoupling your dev container configuration from the host operating system. If your dev container depends on a specific host operating system version or Linux kernel version, this upgrade will impact you. For example, if you are installing specific kernel headers from the host into your dev container, you should change your configuration to install the generic linux headers, as this package will properly update independent of the host operating system kernel version.

If you see any issues that you believe are related to this change, please reach out to GitHub Support.

Helpful Links:

See more

Codespaces now supports two-way Settings Sync with VS Code for the Web

Visual Studio Code enables users to Sync Settings between VS Code environments. Codespaces exposes this capability as a way to personalize your experience. Prior to this release, Settings Sync for the VS Code web client was one-way by default, and two-way sync had to be enabled manually for each codespace.

With today's release, you can now choose whether to enable Settings Sync. Settings Sync is off by default. If you enable Settings Sync, the sync is two-way for repositories you trust, and one-way for untrusted repositories. Codespaces will also remember your choice.

The quickest way to enable Settings Sync is to start a codespace using the VS Code for the Web client, then choose 'Turn on Settings Sync…'

Turn on Settings Sync in VS Code web client

You will then be prompted for permission to enable Settings Sync for the repository. If you authorize, the Settings Sync setting on your GitHub profile will be enabled, and the repository will be added to a list of trusted repositories so that future codespaces on that repository will automatically have Settings Sync enabled in VS Code for the Web.
cVS Code Settings Sync is requesting additional permissions

You can manage your Settings Sync and GPG verification settings from your GitHub Codespaces Settings page at

On the Codespaces settings page you can manage which repositories you trust for GPG verification and Settings Sync.
Codespaces Settings for GPG verification and Settings Sync

Trusted repositories

Settings Sync and GPG verification now share a single set of trusted repositories. You can enable or disable GPG verification and Settings Sync independently. If you have Settings Sync enabled and you open a codespace from a repository that is not in your list of trusted repositories, the Settings Sync will be read only – your settings will be pulled from the Settings Sync server and applied to your codespace, but no settings changes will be written back. If you open a codespace for a repository you do trust, your settings will be synced both to and from the server.

If you have enabled GPG verification for all repositories, we advise you to restrict the repositories to a trusted list when you first enable Settings Sync.

VS Code Settings Sync is requesting additional permissions when all repositories are trusted

If you choose to enable Settings Sync for all repositories we will keep that setting for GPG verification as well, but we recommend restricting both Settings Sync and GPG verification to trusted repositories to improve your security posture.

See more

Codespaces has a number of new features to get you coding fast, from anywhere on the web, with a single click. Let's jump right in!

You can now add recommended secrets to a project when creating a Codespace!
Screenshot 2023-04-21 at 9 08 25 AM

Recommending secrets will ensure developers won't miss any API keys when creating a Codespace from your repo. You can specify any secrets you need to run your project in a Dev Container. If a developer already has a secret stored in their user secrets, Codespaces recommends they add the secret to their repository. Developers can worry less about setup and jump right into development!

Do you want to share your project for others to try out? You can generate a share link to share in a tweet, add to your website, or send to a friend.
Screenshot 2023-04-21 at 9 09 24 AM

Want developers to pick up on the last Codespace they had when they clicked your share link? You can set your share links to drop developers into the same Codespace every time by selecting "Quick start."

You can select a specific Dev Container for the share link to create a codespace from! Codespaces detects the repo and branch from your repository, limiting your setup.
Screenshot 2023-04-24 at 10 45 11 AM

We've even made it easier to embed the share link into a nice "Codespaces" badge with HTML and Markdown. Nifty!

If your users have never created a codespace from your share link, they are recommended to create a codespace. If users already have a codespace from your share link, they are be prompted to resume their codespace.

Would a Dev Container by any other name smell as sweet?

You can now name your Dev Containers! By defining the property name in your devcontainer.json, you can set the name that will appear under the Dev Container selection on the Codespaces creation page. Even if you don't define the name property in your devcontainer.json, Codespaces will still infer a more useful name from your Dev Container file path.
Screenshot 2023-04-21 at 9 13 48 AM

Jumping Into Development From A Repository With A Comma

Do you want to collaborate on a repository, PR, or Branch? You can jump right back into your Codespace with the ',' key. No need to go to, or go to your Code<> drop-down to jump into development. Just one button and you're back to developing!

Learn More

Check out the docs:

Want to leave feedback? Make a post on our discussions page

Thank you!

See more

The GitHub Codespaces plugin for the JetBrains Gateway now supports Rider as a remote IDE. .NET developers can now leverage the standardization and power of GitHub Codespaces with JetBrains Rider's singular code indexing, navigation, and debugging capabilities.

JetBrains Rider in Gateway

GitHub Codespaces support for Rider enables multiple solution file scenarios. If there is only one solution file in a given codespace, the GitHub Codespaces plugin will automatically select that solution file. If there are multiple, the plugin will prompt the user to select which solution file they intend to use to open their project. Repositories without solution files are still compatible with Rider, however some features will be limited when no solution file is selected.

Rider solution file picker

To get started with Rider, follow the documentation for installing GitHub Codespaces into the JetBrains Gateway. Once installed, users can connect to any of their existing codespaces with Rider as their selected IDE.

We are extremely excited to deliver our top requested feature since the beta announcement of JetBrains support in GitHub Codespaces.

Additional Resources:

See more

GitHub Codespaces with included free usage is now rolling out to all GitHub Free and Pro accounts. Over the coming days you'll see a new option under the green "Code" button (where you are used to getting the info you need to clone a repository) that enables you to spin up and manage cloud based development environments that free you from the pain and hassle of setting up and maintaining local configurations. Until now, only Teams and Enterprise managed GitHub Organization members had access to Codespaces.

With this update, GitHub will provide each Free plan account 120 core hours, or 60 hours of run time for a 2 core codespace, plus 15 GB of storage to use each month. Pro accounts get 180 core hours and 20 GB storage per month. You can see how much included usage is remaining for your account during the current billing period on your billing page. If you use up all of your included usage, it is easy to set up a spending limit and keep working. For more details see "About billing for GitHub Codespaces."

We hope that everyone will take Codespaces for a spin, and come join us in the community discussion space to tell us your story!

See more

This changelog only applies if you participated in the beta program for Codespaces for Individuals.

Today marks the start of the rollout of Codespaces for Free and Pro accounts, and thus the end of the beta for Individuals. Unfortunately, this also ends unlimited free use of Codespaces.

The good news is that this marks the beginning of much broader collaboration with more people who can now take advantage of included free compute and storage. All Free and Pro GitHub accounts receive a generous amount of free included usage each month.

Note that the default spending limit for GitHub Codespaces is $0. So even if you already have a payment method configured with GitHub, you will not automatically be billed unless you change your spending limit.

The rollout will take place over several days, so these changes will affect you in the coming days. For more details see “About billing for GitHub Codespaces.”

For those who participated, a heartfelt THANK YOU for all the feedback that has been instrumental to our getting to this milestone.
We hope that you’ll continue to enjoy Codespaces, and come join us in the community discussion space to tell us your story!

See more

GitHub now supports the use of GitHub Codespaces with JetBrains IDEs via the JetBrains Gateway. After downloading the JetBrains Gateway and installing the GitHub Codespaces plugin, users will be able to connect to their codespaces with the JetBrains IDE of their choice.


Once connected, users can leverage the full power of JetBrains' IDEs in the cloud: fast, accurate code completion; integrated run and debug configurations; and unparalleled code navigation tools. Rather than needing to install each IDE on a developer machine, using GitHub Codespaces with JetBrains IDEs enables the use of any JetBrains IDEs in the cloud.


The beta supports connectivity to a codespace, private port forwarding, and a fully featured code editing experience in the following IDEs:

  • IntelliJ IDEA
  • PyCharm
  • WebStorm
  • GoLand
  • RubyMine
  • PHPStorm

Additional IDE support, codespace management tools (e.g. creation, deletion, changing the machine type), and better support for Development Container creation will be added as the beta progresses.

In order to connect to a codespace via the JetBrains Gateway, users will need the following:

Check out the documentation to learn more and get started.
For feedback or questions, create an issue in this repository and we will get back to you.

See more