Codespaces by organization, not repository

I’m maintainer of the pREST open source project, inside the organization we have some repositories, I have to create a codespace for each repository, it would be more practical to create a codespace for the organization and in the workspace contain clone of all the existing repositories of the organization

1 Like

Codespaces is bound by user per repository apparently, but in the UI its represented as per repo per organization, which I believe is the new system.

Thanks for the feedback @avelino!

Org level Codespaces is something that we’ll think about.

In the mean time, you may be able to set up a work around by cloning additional repositories into your codespace from the terminal. You could also automate that with the postCreateCommand in devcontainer.json


Being able to have a .devcontainer directory in an organization’s .github repo could be handy.

1 Like

I agree with this, it’s a pain to setup authentication and everything else for every repo. Probably to the point where it’s too painful to use vs just developing locally. I would even argue that it would be more practical to have codespaces at the user level then automatically clone the appropriate repo in when you click “Open in codespace”.

Or alternatively some way to share user settings (auth, config, etc) between codespaces, that could also solve this problem.

1 Like

We have a similar issue and are planning to resolve it by creating a “codespaces” repo within the org. That repo would host all codespace config and automatically clone the different repos during startup using postCreateCommand. The downside with this is that then each repo cannot be used independently in Codespaces.

I like the idea of shared or inherited config! That would allow us to manage common Codespace settings in one place, and also customize it for each repository.

1 Like