Change:
this._registerCommands().then(() => TaskCommandsRegistered.bindTo(this._contextKeyService).set(true)); ServerlessWebContext.bindTo(this._contextKeyService).set(Platform.isWeb && !remoteAgentService.getConnection()?.remoteAuthority); this._configurationResolverService.contributeVariable('defaultBuildTask', async (): Promise<string | undefined> => { <del> let tasks = await this._getTasksForGroup(TaskGroup.Build); </del> <ins> // delay provider activation, we might find a default task in the tasks.json file let tasks = await this._getTasksForGroup(TaskGroup.Build, true); </ins> if (tasks.length > 0) { const defaults = this._getDefaultTasks(tasks); if (defaults.length === 1) {

Discussion:
This issue is to ressurrect which was fixed, then closed, then reverted without comment. The issue remains in 1.81.1. Attempting to run any task loads ALL extensions. For example, for me it loads PlatformIO, Rust Analyzer, etc. when I'm working on a C project. <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.81.1 OS Version: Linux Steps to Reproduce:
Any update on this? I'm still encountering this bug using 1.84.2, and it's very overwhelming to have every extension startup all at once (with their associated notifications) when you just want to debug your project :/ ~@ meganrogge since you were the one to revert the fix commit, could you at least explain why?~ Ok so it seems that the fix commit was reverted in , and then that revert was reverted itself in because of the current issue; however, something must have broken, because despite the double-revert, the original issue (i.e. the current one) is still happening in 1.84.2
I am a maintainer of the Go extension. We are observing that the Go extension is activated randomly due to this bug. Is there any workaround extension authors can use until this issue is addresssed?
This is an extremely annoying bug. I have the rust-analyzer extension installed, and when I'm working on non-rust projects (e.g., a platformio C++ arduino project), rust-analyzer shows a very urgent red error message at the bottom of my screen.

From all the related bugs, it sounds like this is a vscode issue, and extension authors are unable to fix it.
Seeing this issue as well from within a Swift project. I found this issue via:
I see the issue here. I don't think we ever should've adopted implicit activation for tasks - which means that is as an activation event for any extension that contributes a task . Thus, that extension will get activated when the build task command is run for example because in doing that, we call activate task providers, which fires the events for the whole registry. We fire events for the whole registry for that case because tasks (including a build task) are provided in the extension programmatically and we want the execution of the task after user request to be expeditious vs waiting for on-demand extension activation. Reverting this should fix it:
This would also happen when debugging if the configured task for debugging lacks a , which may be undefined
I have to revert this fix once again because we need to activate all task providing extensions when debugging as otherwise, a might not be found. A user can set their to be anything. Similarly, build tasks can be set programmatically, using the API property. Thus, when the build task is run, we need to activate all extensions that contribute tasks. In order to minimize the number of extension activations, we encourage people to set the property for their .
This is unfortunate. Is there an alternative approach to fix this issue? Or is there some capability for tasks that we would have to add to tackle this?
One idea for the debugging case would be to add a task property for .
I can repro when I set to be . Currently, when is used as a we fetch all tasks, activating all providers, then filter to find the default build task. We then run it, which redundantly activates that provider. The fix is to wait on activation. If we find a default build task, then its provider will be activated when it's run. If we don't find one, then we'll fall back to the current behavior - activating all providers.
I think that's good behavior. We might still be able to add some optimization for the case of extension-provided configurations.

Maybe in workspace storage we keep a small LRU (say ~5 entries) to associate labels of tasks with the extensions that provide them, to avoid having to activate all extensions all the time if I run some ?
Thanks for improving this. I just tried it out and it behaves better for me. Adding verified label if you can still reproduce with the latest VS Code Insiders build do let us know. Thanks!