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

Codespaces now has improvements that will streamline your experience when working with multi-repository and monorepo projects.

To enable teams to develop applications that span across multiple repositories (e.g. common in microservice architectures), we have added the ability for users to configure which permissions their codespace should have on creation. This means that users will no longer have to set up a personal access token inside of their codespace to clone or create pull requests for multiple repositories.

Additionally, if you're a part of a larger organization and have many teams working in a single repository (e.g. monorepo), Codespaces now supports multiple devcontainer.json files inside of your .devcontainer directory, as long as they follow the pattern of .devcontainer/${DIR}/devcontainer.json.

Lastly, to provide more flexibility during codespace creation, there's a new advanced create flow for Codespaces that allows you to select various options, such as branch, geographic region, machine type, and a specific dev container file while creating your codespace. If you want to skip the advanced creation flow, you can always go for the one-click create by selecting Create codespace on <branch name> to create a codespace with the default configuration.

With these updates, repositories can be setup with multiple devcontainers, each with permission sets, setup scripts, and a codespace configuration specific for certain sub-teams or developer roles (e.g. front-end, back-end). Then, developers can select the ideal devcontainer, machine type, and geographic region for their task during the codespace creation with the advanced flow, as needed.

Here are some helpful links to get you started!

See more

Repository administrators can now configure how often/when prebuild configurations for a given branch should be updated. Prebuilds enable developers to startup Codespaces in seconds – regardless of repository size or complexity – by building your development environment beforehand. Previously, prebuild configurations were updated on every push made to a prebuild-enabled branch. During public beta, we heard from many repo admins requiring more control on how often their configurations should be updated based on their team’s processes as well costs associated with running Actions workflows to keep configurations up to date.

With this feature, admins can now make more nuanced trade-offs between environment “freshness” and Actions usage. For example, an admin working in a large organization may decide to update their prebuild configuration every hour rather than on every push to get the most economy and efficiency out of their Actions usage. While creating or updating prebuilds for a given repo and branch, repository admins can choose from three triggers to initiate a refresh:

  • Every push (default): With this setting, prebuild configurations are updated on every push made to the given branch. This ensures that new Codespaces always contain the latest configuration, including any recently added or updated dependencies.
  • On configuration change: With this setting, prebuild configurations are updated only when configuration files (ex. devcontainer) change. This ensures that developers always have access to a Codespace based on the latest configuration without having to run Actions workflows on every push made to the repo.
  • Scheduled: With this setting, you can have your prebuild configurations update on a custom schedule only, regardless of any pushes made to the branch or updates made to associated configuration files. This can further reduce consumption of Actions minutes and give admins even more control on how often configurations should be updated.


For more information, see Configuring prebuilds for your repository

See more

Currently, forwarded ports within codespaces can be set to private in which case they can be accessed only by the owner of the codespace, be shared with members of the organization or be set to public at which point anyone the URL is shared with can view the port. We heard from many organization admins that they want to disable public ports for organization-owned codespaces with the goal of ensuring that company assets can only be shared and accessed by members of the organization for security purposes.

With this feature, we have added the ability for organization admins to add port visibility constraints that enable them to control which visibility settings are available within organization-owned codespaces. For instance, admins will be able to disable the 'public' visibility port setting for desired repositories within their organization and enable developers to continue sharing ports only with members of their organization. This would be done to help preventing codespaces users from accidentally exposing company owned assets to unauthorized individuals.
port visibility policy constraint image

We will continue adding additional policy constraints based on feedback, some of which include setting a maximum idle timeout, setting maximum retention periods, setting allowed container images, and more. We'd love your feedback on additional policies that will help your scenarios.

For more information, see Restricting the visibility of forwarded ports

See more

Today, we’re announcing that the ability to prebuild codespaces is entering public beta. Prebuilding a codespace enables fast environment creation times, regardless of the size or complexity of your repositories. A prebuilt codespace will serve as a ‘ready-to-go’ template where your source code, editor extensions, project dependencies, commands, and configurations have already been downloaded, installed, and applied so that you don’t have to wait for these tasks to finish each time you create a new codespace.

As a part of this release we’ve made improvements to the set-up process for prebuilds, as well as added support for GitHub-managed Actions workflows that will automatically prebuild a codespace for any configured repository’s branch and region(s). Additionally, since prebuild configurations are built on GitHub Actions virtual machines, repository admins will have access to a rich set of logs to help with efficient debugging in case failures occur.

Prebuilt codespaces are available in beta for all GitHub Enterprise Cloud and Team organizations. Repository admins can head over to their repository’s settings page and create prebuild configurations under the Codespaces tab. Once set up, you can take advantage of fast codespace creation by selecting machine types with the ‘prebuild ready’ tag.

Check out the prebuilds documentation to help you get started!

See more

We've gotten a lot of feedback from users that it's hard to differentiate multiple codespaces in the same repo, especially if they're on the same branch. To make it a little easier to tell codespaces apart, we've started automatically creating "friendly" (and fun) names for your codespaces.


If you don't like our names, we're also working on the ability for users to re-name their codespaces.

For more information on Codespaces, see "GitHub Codespaces overview".

See more

Currently, Codespaces users in organizations in Team and Enterprise Cloud plans can use any machine type, from 2-core to 16-core (or even 32-core). We've heard from many organization administrators that they want the ability to restrict which machine sizes repositories in their organization should have access to as a means of cost control, and have implemented a new Codespaces policy feature to allow admins this level of control.

Organization admins can now visit their organization's settings page and create Codespaces policies to restrict which machine types repositories in their organization can use. For instance, an admin can restrict certain repositories to only access 2-core and 4-core machines, while granting other, more compute intensive repositories, access to 16-core machines.

In the future, the Codespaces policy feature will be expanded to include additional constraints, including setting a maximum idle timeout, restricting which port forwarding settings are allowed, and more. We'd love your feedback on other constraints you're interested in.

For more information, see "Restricting access to machine types".

See more

Codespaces have been constrained to specific users or all members of an organization, which, while great for day-to-day software development, didn't allow everyone in an organization to participate. That's why we're so happy to announce that as of today, you can invite outside collaborators to access Codespaces.

Outside collaborators expand Codespaces to use cases like interviewing, training, and teaching, where you can easily add outside collaborators to specific repositories within your organization (or in certain cases, giving each collaborator their own repository). Start by granting "All members and outside collaborators" access to Codespaces, then inviting collaborators to repositories you want them to use Codespaces in.

For more information, see "Enabling Codespaces for your organization."

See more

By default Codespaces time out after 30 minutes of inactivity. We’ve heard from many users that they have a desire to extend this up to an entire workday. You can now set a default idle timeout for your codespaces from five minutes to four hours, as well as override the idle timeout for an individual codespace using the gh CLI.

For more information, see “Setting your timeout period for Codespaces”.

See more

Dotfiles are a common way to specify custom, user-specific behavior for applications (like Vim or Emacs) and shells on your codespaces. If enabled, dotfiles stored in a user's public dotfiles repository would be used for this configuration. With this change, any user owned repo, including private repos, can be used to install dotfiles into your codespaces.

For more information, see "Dotfiles".

See more

GitHub Codespaces allows teams and organizations to spin-up developer environments directly from a browser or through Visual Studio Code, without the hassle of setting up a brand new environment tailored to a specific repository.

We've been hard at work since our general availability announcement in August making Codespaces the best way for you to develop software, which is why we're so happy to announce several new features at GitHub Universe 2021.

We know that many developers use the gh CLI to speed up or fully automate daily tasks, and we've received dozens of requests to add Codespaces support to the CLI. As of today, the gh codespace (or gh cs for those saving keystrokes) command now allows developers to manage their codespaces from the GitHub CLI. In addition to codespace creation, listing, and starting/stopping, users can forward ports, set port visibility, SSH into their codespaces, and copy files to/from their codespaces.

# Create a new codespace via the CLI
gh codespace create --repo monalisa/octocat --branch main

We're especially excited about ssh access, as it allows developers who prefer to use editors like vim and emacs to more easily develop in Codespaces. Just gh cs ssh into your codespace and launch your editor of choice; we'll set up the environment and grab all your dotfiles so you're ready to develop in seconds.

# SSH into the codespace created above
gh codespace ssh -c monalisa-monalisa-octocat-1337h4x0r

Complimenting the CLI, we are also launching an API in beta. The API provides control plane operations around a user's codespaces including creating, starting/stopping, listing available machine types, and setting user secrets. These APIs will allow developers to build Codespaces integrations into their favorite editors and tools, as well as allow for additional automation around Codespaces.

# Stop a running codespace via the API
curl \
  -H "Authorization: token <Personal Access Token>" \

We also know that security and privacy are critical, and we've gotten a lot of feedback on providing additional visibility options for forwarded ports beyond public and private. Today we're launching a third option: org visible ports, which are accessible to any user in the organization the codespace has been created in. This is great for securely collaborating with your teammates on new and exciting features in your codespaces.

# Make port 80 visible to all users in an org
gh codespace ports visibility 80:org -c monalisa-monalisa-octocat-1337h4x0r

Continuing with security improvements, we have also heard from developers having difficulty launching codespaces from devcontainers stored in private container registries. To make this easier, we are offering streamlined access to containers stored in the GitHub Container Registry; you no longer have to provide a Personal Access Token (PAT).

Speaking of devcontainers, we know that there's a wide gap between using a predefined devcontainer and building a custom devcontainer. To help make that transition a little easier, we're launching the ability to extend devcontainers with features, which include shells, package managers, programming languages, and other common tools. For example, adding Terraform to a supported base image is as easy as adding the following to your devcontainer.json.

"features": {
  "terraform": "latest"

If you have any feedback about these features, or Codespaces in general, we'd love to hear from you!

Learn more about all our newly released features:

See more

Today, Codespaces is rolling out progressively for organizations on Team and Enterprise Cloud plans. Organization owners can enable Codespaces in organization settings.

Codespaces can be used for free through September 10th, 2021 (PST) for enabled organizations in Team and Enterprise Cloud plans, after which billing begins.

For users in individual plans, we’re extending the existing Codespaces beta. For those in the beta, access will remain and we’ll share updates on what’s coming in the near future.

Read more on our Codespaces page and in docs.

See more

We recently launched new and improved content for Codespaces. We heard from our beta testers that they wanted more task-focused documentation, more information on the benefits of Codespaces, and more specific examples on how to use it. We've restructured the content to make it easier for you to discover and added the following sections:

See more