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 *.visualstudio.com 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 github.com. 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 *.visualstudio.com is allowlisted under your firewall rules.

Enable the feature flag under github.com 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.

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

• GitHub Codespaces host configuration documentation
• Documentation about host images with GitHub Codespaces
• How to opt into early access to beta host image configurations

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

• GitHub Codespaces host configuration documentation
• Documentation about host images with GitHub Codespaces
• How to opt into early access to beta host image configurations

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.

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

• About billing for GitHub Codespaces
• Viewing projected usage for an organization
• Viewing GitHub Codespaces usage for an organization

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.

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

• Selecting your preferred image configuration
• Codespaces host image contents documentation

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.

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

• Repository Access and Security setting for personal accounts
• Repository Access and Security setting for organizations
• Managing repository access with the devcontainer.json file

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.

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! https://github.com/codespaces

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.

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.

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

• Enabling or disabling GitHub Codespaces for your organization
• Managing GitHub Codespaces costs within your organization
• GitHub Codespaces audit log
• Choosing who owns and pays for codespaces in your organization
• Enforcing policies for GitHub Codespaces in your enterprise

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://*.preview.app.github.dev to https://*.app.github.dev.

To prepare for this change, replace any hardcoded references to preview.app.github.dev 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 preview.app.github.dev to app.github.dev when the migration completes. Learn more about environments variables here.

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

• Applying a codespaces per user limit within your organization
• Restricting the retention period for codespaces within your organization
• Configuring the idle timeout period for codespaces within your organization
• Managing GitHub Codespaces costs in your organization

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

• Current codespaces billing documentation
• How to create or update your spending limit
• Exporting changes from a codespace to a branch

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:

• Ubuntu 22.04 information
• Ubuntu 18.04 end of standard support notice

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…'

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.

You can manage your Settings Sync and GPG verification settings from your GitHub Codespaces Settings page at
https://github.com/settings/codespaces.

On the Codespaces settings page you can manage which repositories you trust 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.

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.