Inconsistent terminal styles

I noticed that when launching the same repo in Codespaces, the terminal style of the launched instance varies. Attached are 2 screenshots of the same repo launched in different Codespaces. The first one gets a really nice styling of the terminal showing branch info. The other one ended up with a more simple styling without branch info.

I am not doing my own customizations of the terminal look and feel via dotfiles, and the only difference really is that both instances were launched the same repo with the same config at different times.

The image being used is

Does anyone know why this happens?

The top one is the updated version of the image. The lower is an older version. You can force Codespaces to use the most up to date version by specifying the full version number in devcontainer.json or your dockerfile.


Region rollouts can cause the cached version sometimes be the previous incarnation while the rollout is happening.

I see. Is there a way to check the image version from the terminal?

@Chuxel Inconsistencies in the image in which my codespace runs still trip me up almost every time I launch a new codespace. Just now launching a codespace based on results in this prompt:

Screen Shot 2020-10-30 at 12.00.00 AM

I am looking at the prompt definition in the repo and what I see there is not what I see in the codespace instance, even when I lock the image to a specific version, like

On top, I see this permission error where node_modules is owned by root:

I don’t think this is a caching issue because I’m locking the image version in devcontainer.json as suggested. And I am really confused because when locking the image version does not result in the expected codespace, what other moving parts are there that impact codespace generation?

This could be a new issue I’ve noticed where the default shell seems to end up with sh instead of bash unless your devcontainer.json includes a terminal settings. If you type bash do you see the correct prompt?

Yes, it’s as you described and I see the correct prompt after typing bash.

Hi @Chuxel / @454de6e,
There was a new issue that was causing vscode settings to be not applied properly. A fix is being currently deployed to Production.

We will take a look at the permission issue. It might be caused by the postcreatecommand or the oryx command not being run as the remoteUser, defined in the devcontainer.json.


Just wanted to confirm that the fix has been rolled out for the vscode settings issue, and the terminals should now behave as expected.
Thank you for reporting.


Looks like I can’t connect to any newly created codespace. See error message.

@454de6e there seems to be a regression. We have identified the issue and a fix for that will be out today.
Sorry for the inconvenience caused.

@454de6e, a fix for this has been deployed. Can you try to create a new Codespace and let us know how it goes? Thanks!

I can launch a container now, but the terminal is still not a bash by default. See screenshot.

If you open a new terminal after that, is it bash? Currently the settings are copied in a bit after the container is started, so there’s a small race condition between how fast the connection is established and how fast the settings copy runs (both happen in parallel). If the settings copy is after the connection, a new terminal should be spawned as bash instead of sh.

It’s as you described: when opening a new terminal it’s bash as expected.

Thanks for confirming. We’re looking at moving the settings copy earlier in the flow and ensuring that it’s a blocking action for connection to avoid inconsistencies based on settings not being applied to the initial terminal.

I am getting a little frustrated because now I’m running into a settings sync issue when launching a codespace in the browser. See screenshot.

Can you refresh the page / reconnect? VS Code’s Settings Sync service made a breaking change recently in the data format, so if you synced data from a newer Insiders build (such as on your desktop) and then opened in an older build, that error pops up. We just finished rolling out a new Insiders build in all regions in the web so that error message should go away if you connect from the browser. VS Code is also looking at how to minimize breaking changes in the settings sync service going forward.

I can confirm the first shell opened is /bin/sh instead of the default shell in the .devcontainer.json configuration.
Subsequent shells do use the devcontainer setting.