A VS Code task can be set to run when its folder opens, using runOptions.runOn with the value folderOpen. It only runs in a trusted workspace, and the task.allowAutomaticTasks setting defaults to off, so VS Code asks you once before allowing it.
How automatic tasks are defined
Tasks live in .vscode/tasks.json inside a workspace folder. Each task can carry runOptions. The runOn field accepts default or folderOpen. With default, the task runs only when you execute it through the Run Task command. With folderOpen, it runs when the containing folder is opened.
There is a good use for this. A team might start a watcher or a local dev server automatically. The same mechanism is also a way for a repository to run a command on your machine at open time, which is why the guardrails matter.
The three guardrails
The VS Code documentation describes these:
- Workspace Trust. Automatic tasks never run in an untrusted workspace, whatever the setting says.
- The setting.
task.allowAutomaticTasksisoffby default. You are prompted once to Allow or Disallow. Choose Disallow and tasks will not run and you will not be prompted again. - The management command. Tasks: Manage Automatic Tasks lets you change your choice later.
If you set task.allowAutomaticTasks to on, trusted workspaces run automatic tasks without prompting. That is convenient for your own projects and a poor default for everything else.
A sensible policy
- Leave
task.allowAutomaticTasksat its default. - When prompted in a repository you did not write, open
tasks.jsonand read the task first. - Answer Disallow if you are unsure. You can always run a task by hand.
- Keep unfamiliar repositories in Restricted Mode until you have read the
.vscodefolder. The checklist for opening unfamiliar repositories walks through it.
What to look for in a task
Read the command and args. Ask whether the command is something you recognise, like a build tool you already use. Be wary of commands that fetch and run content from a URL, that call a shell with a long encoded string, or that touch files outside the project.
Teams: put it in review
Because tasks.json is a file in the repository, changes to it show up in pull requests. Treat edits to .vscode like edits to a build script. A reviewer who sees a new folderOpen task should ask why it is needed.
Where this goes wrong
The usual failure is habit. A developer sets task.allowAutomaticTasks to on because their own project uses a watcher, then clones a stranger's repository next week. If they also trusted the parent folder, the project opens trusted and its automatic task starts without a question. Two convenient settings combine into an open door.
The fix is cheap. Keep the setting at its default, scope trust to individual project folders, and let the one time prompt do its job.
Alternatives to automatic tasks
If the goal is a smooth onboarding, there are options that do not run code at open time: a documented make dev or npm script, a dev container with an explicit start command, or a README section with the three commands a newcomer needs. Each one makes the developer press a button, which is exactly the property that keeps the editor honest.
Quick check
If I click Disallow, will VS Code keep asking?
No. According to the documentation, tasks will not run and you are not prompted again. Use Tasks: Manage Automatic Tasks to change that.
Do automatic tasks run in Restricted Mode?
No. The documentation states they never run in an untrusted workspace.
Sources
Last reviewed: 19 October 2026.
