Change:
const failed: string[] = []; try { <del> const installedExtensionsManifests: IExtensionManifest[] = []; </del> if (extensions.length) { this.logger.info(this.location ? localize('installingExtensionsOnLocation', "Installing extensions on {0}...", this.location) : localize('installingExtensions', "Installing extensions...")); } const installVSIXInfos: InstallVSIXInfo[] = []; <del> let installExtensionInfos: CLIInstallExtensionInfo[] = []; </del> <ins> const installExtensionInfos: InstallGalleryExtensionInfo[] = []; </ins> const addInstallExtensionInfo = (id: string, version: string | undefined, isBuiltin: boolean) => { installExtensionInfos.push({ id, version: version !== 'prerelease' ? version : undefined, installOptions: { ...installOptions, isBuiltin, installPreReleaseVersion: version === 'prerelease' || installOptions.installPreReleaseVersion } }); };

Discussion:
<!-- Please search existing issues to avoid creating duplicates, and review our troubleshooting tips: --<!-- Please attach logs to help us diagnose your issue. Learn more here: and here: --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --- VSCode Version: 1.85.1 Local OS Version: Ubuntu 23.10 Remote OS Version: Remote Extension/Connection Type: Containers <!-- If your bug is related to Remote-SSH, please use the SSH-specific reporter: --Steps to Reproduce: the following file: / rebuild the container in vscode installed python extension will randomly be the latest one (currently v2023.22.1) instead of the pinned one. I suspect that this could be triggered by the fact that the extension depends on . Here's a log of a faulty install: <!-- Check to see if the problem is general, with a specific extension, or only happens when remote --Does this issue occur when you try this locally?: Not tested <!-- If your issue only appears in Codespaces, please visit: --
Thanks for opening. This sounds like a key potential insight. curious to get your thoughts here.
I think you mentioned that version pinning doesn't work from the server CLI?
Extension pinning is supported in CLI now. But this would have been caused by the extension dependency from extension as mentioned.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.85.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

Behaviour: Upon opening a GitHub code space with the following configuration of extensions, I get an error saying that one of the extensions are not installed (but it should be installed since it is in the list).VS Code Version: Version: 1.83.1 (Universal) / Commit: OS Version: macOS 13.6 (22G120) GitHub code spaces with the following .devcontainer (see below) the GitHub code space loaded you get the error: "Cannot activate the 'autopep8' extension because it depends on the 'Python' extension, which is not loaded. Would you like to reload the window to load the extension?" In speaking with the GitHub code spaces team, I learned that: "It looks like all of the extensions are being passed into the VS Code server at the same time, so it would require upstream changes in VS Code to handle the installation order in a better way." and "My guess is that the extensions are installed in parallel and the python one just takes longer to install/activate and the pep8 one is trying to activate too early before the python finishes installing" includes
I've also been seeing such issues for months, particularly for extensions that depend on . As someone maintaining the development setup environment for a team, it would be really helpful to have any solution that works without a manual reload or custom configuration for each user.
We have a similar issue with C#. If you install the C# extension or the C# DevKit extension, it will install quicker than it's dependent ".NET Install Tool" extension. This race condition leads to a prompt that shows up the majority of the time to reload the editor to install the dependent extension.
I have been running into this same situation, except inside a devcontainer. The Black Formatter extension and the Flake8 extension fail 100% of the time and VSCode suggests reloading. Reloading always works. Is anyone aware of a workaround in the meantime to enforce an ordering?
I stumbled upon a workaround with a long-running in , so I suspect for anyone having this issue you could potentially do something like: Not pretty, but neither is the "always click the reload button" option.
I'm seeing the same behavior as with a slight clarification: I have the following in my Order (moving python above black-formatter, flake8, and isort) doesn't seem to matter.

Visual Studio Code Version: 1.84.2 (user setup) Commit: Date: 2023-11-09T10:51:52.184Z Electron: 25.9.2 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.
This bug makes it rough to create a "minimal" template for .NET and Python developers in GitHub Codespaces with the .NET/Python extensions as it will almost always ask you to reopen the codespace. Even this configuration will require a "reopen" prompt: EDIT: Adding photos ! ! Something like an "extension-order" setting, similar to the features, would be amazing in VS Code or development containers.
Or at least loading extensions in the order as given in the list, then users could at least easily hand-sort to avoid these annoying dependency problems until a "real" fix comes along. Presumably/hopefully this could be a quick fix as it's a small change?
Can anyone reproducing this issue, please share following logs? F1 Open View... Server
use this link to open the  repository as a codespace: devcontainer configuration: waited for the C# extensions to install and to observe the "Cannot activate the 'C#' extension because it depends on the '.NET Install Tool' extension, which is not loaded. Would you like to reload the window to load the extension?" popup. 1 Open View Server 's the logs:
I repeated this experiment using a Codespace on a different repository and configuration file. Repository:  Codespaces link: Devcontainer configuration: I could not repro the same issue that observed. I may be missing an important step to repro.
Thanks for the log. From the log it seems following extensions are requested to be installed github.codespaces and following extensions are requested to be installed again ms-dotnettools.vscodeintellicode-csharp ms-dotnettools.csdevkit ms- ms- By any chance, you have settings sync enabled and you have above extensions synced?
I do have settings sync enabled with the C# and C# DevKit extensions.
Thank you for trying I tried your and also didn't see the issue.

Given , maybe the codespace takes just long enough to load things before opening the window to avoid the Reload prompt? Although it does seem to be doing things in the right order ... this is the end of F1 Open View Server from that codespace I reproduced the issue in a smaller repository () via the Dev Containers and WSL extensions and the following container spec ! Help About: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Windows_NT x64 10.0. Note this is an older version of VS Code than I used above in F1 Open View Log (Remote Server) This is without Settings Sync enabled !
We closed this issue because we in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our and . Thanks for your understanding, and happy coding!
I have to admit that I'm confused. The linked page talks about closing out-of-scope feature requests. I don't see how this can be relevant here, as this report is of extension loading being broken/erroring. In fact, I'm confused why the label was removed by Furthermore, users have supplied logs as requested, and even repos for reproduction, yet the label was not removed, and now failing extension loading is closed as ? I'd be curious about the decision process here, to be honest.
Yeah - I also disagree with closing as here. I'm continuing to see wierd bugs with extensions here - these are effective usability problems that cause friction and requires workarounds. Example with latest version of VSCode: Upon opening a GitHub code space with the following configuration of extensions, I get an error saying that one of the extensions are not installed (but it should be installed since it is in the list). GitHub code spaces with the following .devcontainer (see below) the GitHub code space loaded you get the error: "Cannot activate the 'autopep8' extension because it depends on the 'Python' extension, which is not loaded.

Would you like to reload the window to load the extension?" Despite clearly declaring Python extension, I get this error in the log: Now if I close and reopen the codespace, I get thing working: and my poetry managed environment is available to Jupyter. It's really hard for my users to understand why they have to restart VSCode and reopen the codespace before the extension works.
I work at GitHub and I would be happy to jump on a call and walk you through how to reproduce this if you can't reproduce.
Thanks for feedback. I closed this because I do not see us investing resources in fixing issues like this in the next 6 months. Not saying it is invalid. We might still reopen it after I discuss with As for GitHub - I suggest to reach out to the Codespaces team and if they have capacity they can invest in making a PR.
any updates or ? I have another instance of this again: with clearly in the devcontainer ! with a of:
Will investigate and see if I can repro
! please see full server log here: With and latest version System info
this shows another simple repro example, they even provided a repo that reproduces this issue every time and it only has two extensions listed in
As a follow-up to luabuds post above, this is the logs from F1 Open View Server.
PR to fix:
thanks