Change:
}, [TaskSettingId.AllowAutomaticTasks]: { type: 'string', <del> enum: ['on', 'auto', 'off'], </del> <ins> enum: ['on', 'off'], </ins> enumDescriptions: [ nls.localize('task.allowAutomaticTasks.on', "Always"), <del> nls.localize('task.allowAutomaticTasks.auto', "Prompt for permission for each folder"), </del> nls.localize('task.allowAutomaticTasks.off', "Never"), ], <del> description: nls.localize('task.allowAutomaticTasks', "Enable automatic tasks in the folder - note that tasks won't run in an untrusted workspace."), default: 'auto', </del> <ins> description: nls.localize('task.allowAutomaticTasks', "Enable automatic tasks - note that tasks won't run in an untrusted workspace."), default: 'on', </ins> restricted: true }, [TaskSettingId.ShowDecorations]: {

Discussion:
notice that the has a -script run the task manually reload window :bug: the task doesn't start automatically
cc you fixed this in the past
I certainly caused this w the task reconnection - will look into it
this is working for me now - likely fixed with one of my recent PRs related to automatic tasks
Sorry, this doesn't work
you need to allow automatic tasks to run. have you run !
https://user-
https://user-
Why is this now needed? I have trusted this workspace and I have run this exact task successfully in the past?
it's always been needed. if you've ever hit disallow, it won't work. once you've allowed for the folder once, you shouldn't have to again
I doubt that's true. When I hit allow it writes a workspace setting and that wasn't needed, it came in via I have been using this feature years before this change - albeit infrequently in side projects. I already have the - option and I have given trust to the folder. So, why do we put up further hurdles to use this feature?
was to prevent these tasks from running automatically without consent of the user in a workspace that may or may not have been set up /configured by them.
some people can find it jarring and unwanted if they run automatically - even if they trust the workspace and happen to have that in their file
If I'm remembering right there was always an opt-in via notification (maybe requiring engaging with the task system before it shows?). Whether a task runs on startup is a user preference, so instead of a hidden preference stored in local storage, tasks has moved to a setting. Is the problem that there was no migration to the setting?
Yes I think so
Looping in for reference but if I remember correctly this notification was the workaround for the lack of workspace trust. We prompted folks with an FYI to ask them for consent - similar prompts existed for eslint or tsserver and workspace trust is the answer No. This is a workspace configuration file which means "team preference". It is the same as using source maps for debugging or not. Or what typescript version to use etc.

Also, the "Manage Automatic Tasks in Folder" writes a workspace setting not a user setting
It was here , derived from this terminal change The discussion in the terminal feature request is here: I did remember some of this wrong after digging into it and it was primarily for security, but it's not the only reason for it now. The UX of this is an important part that was refined over time and carried over to terminal profiles; I have a preference of never wanting a workspace to modify my default terminal profile, regardless of whether I trust it. I disagree, I've always had auto run tasks disabled as I want to control when they run. This was a consideration when the notification was . Source maps are a bad comparison as if they work they're almost always a better experience (though I often disable them to access ran variable names). Yes, we simplified it from opt-in to auto running tasks per workspace as that's handled by workspace trust now, to simply "am I a user who wants to enable auto run tasks?". That seems like it aligns with you wanting to have them always enabled and me wanted to have them always disabled.
I also have many my preferences but the team preferences overrule them: source maps, prettier, lint rules etc pp. That's part of agreeing what are team and personal settings. As a side note: I am not aware that auto tasks have ever been a topic for us (VS Code) and I also don't see any of them in our file. Don't get me wrong: I am happy with a "overrule team decision and go with my preference" path. I think this applies to a few none-critical things, like I want that for source maps. Anyways, the implementation for auto-run task is poor: no migration, essentially breaking the feature the "manage automatic task in folder"-command writes a team/workspace-setting which defeats the purpose of overruling team configuration the default value for is . Its docs say "Prompt for permission for each folder" which is not true and misleading
My initial feeling about this was if the folder is trusted, the tasks should run automatically when configured to do so. Several points I encountered when I raised this were: the manage automatic tasks command has been around for a long time and we didn't want to remove it for those that are used to it The setting would make it easier and more discoverable to manage automatic tasks.

I am in favor of removing the prompt per folder and respecting 1) a trusted workspace 2) the setting as configured via the actions or directly. I am also in favor of making this a user setting instead of a workspace/folder specific one.
I like that but the action shouldn't write a workspace-setting because is already a "workspace setting". I would argue this should only be allowed as user-setting (which I believe our settings model supports). Also, the default should be because you conflict team-choice - doing that shouldn't be default. In untrusted workspaces don't ever auto-run a task and maybe show a squiggle in that signals that
Yes I meant as a user setting and agree with you re untrusted workspaces I am in favor of making this a user setting instead of a workspace/folder specific one.
We're bringing this to the UX sync to decide what the right approach is
Proposal: Untrusted: automatic tasks Trusted: based on user setting
Approved in the UX sync
Storage target will now be user and storage scope will be profile