Join Codespaces Engineers @fermion and @jkeech AMA today 12:00PST

Topic is now open and will remain so until the AMA is over at which time it will revert to read-only mode! We’ll start at 12:00pm PST :space_invader:

Welcome to our first community AMA, we are excited to be joined by members of our Codespaces engineering team, they are now standing by live to answer your questions about Codespaces. To submit a question, click “Reply”
All participants will be awarded the new AMA badge and are eligible for a random swag drop (form link posted at the end)

Hi @fermion, would you mind introducing yourself and sharing a bit of what your role is on the Codespaces team?

:wave: of course — I’m an engineer on the GitHub Codespaces team. I’ve helped build out parts of the UI as well as some of the backend interaction between GitHub and users’ codespaces :heart:


Hi @jkeech !
Could you introduce yourself to our awesome community also?

Hey everyone! I’m an engineering lead on the Codespaces team, focusing mostly on the backend services and the agent that creates/resumes/suspends Codespaces and manages the container lifetime. I’ve been working on developer tools for the past few years and am super passionate about helping developers be more productive.

Looking forward to chatting with you all today!



I was wondering how are Codespace instances isolated from each other? Does each one get its own Azure VM, or is it something else?

1 Like

Hey @ginkoid! Each Codespace runs on an isolated VM, and we treat the VM as the security boundary. When a Codespace suspends due to inactivity, the VM gets thrown away, and when you come back later, the Codespace is restarted on a fresh VM/docker host. The docker containers/layers are stored in persistent storage so that we can quickly remount them on a new VM and restart the existing container.


:wave: I was wondering how a user’s Codespace instance is associated with their underlying GitHub account. For example, is it something similar to OAuth?

1 Like

Hey @chen-robert! When the codespace is created or resumed the VM will receive an authentication token for your user that’s scoped to the repository you created your codespace for. Does that answer your question?


Hi GitHub Team!

What’s the security model of GitHub Code Spaces?

In OSS, we regularly have people provide POCs (usually GitHub repositories) of problems they are having with their code. Downloading and testing these POCs has inherent risk as you are now executing untrusted code. I was hoping my team and I would be able to to leverage GitHub Code Spaces (generated from these POC repositories and not our own) as a safe environment to execute untrusted POC code in a way that would not introduce additional risk of compromise of our day-to-day developer machines.

Would this be safe?

What other security risks to your GitHub account exist if a malicious actor is able to achieve code execution inside of a codespace owned by your account in the following situations:

  • A code space generated for an external POC project
  • A code space generated from an organization’s project for which you are a member
  • A code space generated from an organization’s project for which you are an admin

Jonathan Leitschuh


Hey there @jlleitschuh! This is an excellent question. Today the security model for codespaces restricts the codespace’s authentication token’s surface area to the GitHub repository that the codespace was created from. Codespaces will automatically execute some setup scripts that could be defined as part of its .devcontainer contents. Blindly running POCs from untrusted repositories would not be recommended.

For your first bullet point a user’s codespace created from a fork of an OSS repository would not be able to clone from their employer’s organization-owned repository.

For codespaces created from an organization-owned repository the same repository scope exists. A codespace created from a private organization repository won’t have access to a different private repository owned by the same organization. Does that make sense?

We realize that these limitations are going to break the setup of more complicated projects that use Codespaces. We’re working on making the experience here better!

1 Like

Hi, is there some way to share (read-only or optionally read/write) access to a codespace? I’d like to have some way to let someone see what I’m doing at the moment, think programming/debugging together, or teaching.


@airtower-luna, Codespaces does not offer any built-in functionality for sharing a Codespace, but since you get the full power of VS Code, you can leverage any VS Code extension to add this functionality to your Codespaces. One common way to do this would be through the Live Share extension:

With Live Share, you can create a Codespace and share it with others who can see your editors and do pair-programming. You can also optionally share terminals and even the apps that you are running/debugging. Live Share has some built-in functionality to have read-only or read-write mode.

Hope that helps!


Codespaces will automatically execute some setup scripts that could be defined as part of its .devcontainer contents. Blindly running POCs from untrusted repositories would not be recommended.

Are there secrets that are injected into a codespace that could be maliciously compromised by an attacker? If so, what are their lifespan? Are the keys assigned given the same level of access that the user using the container has? IE. If I’m an admin on the repository, does the key in the container have that same Admin permission level? If malicious code execution were to occur inside of these various scenarios, what would an incident responder want to look for in terms of pivoting from that location further into the organization?


@jlleitschuh any secret that exists inside the Codespace should be considered compromised. The way we prevent lateral movement or privilege escalation today is by injecting a token that is only scoped to the repository. So if a malicious actor convinced you to open a Codespace on their repo, they could steal a token that gave them read/write permissions to that repo, but not any of your other repos.

We do not currently allow users to automatically inject other secrets into a Codespace, but if you manually added other secrets, those would be at risk.

We are working on building a concept of trusted vs untrusted repos which will impact what secrets are injected into the Codespace. If you designate a repo as trusted, it will get access to the repository-scoped GitHub access token as well as any other secrets you’ve specified. But for untrusted repos, it would only get the repository-scoped token.


And that is a wrap for our first-ever community AMA! If you’ve participated remember to fill out this form so we can send you a token of our appreciation for participating! AMA Badges will be awarded by weeks end.

If you have any other question about Codespaces, please open a new topic under the Codespaces Beta category.

Thanks again to the Codespaces team and to our community!

See you at the next one :slight_smile: