Fix VS Code tasks.json PowerShell -Command Error

VS Code’s shell task type defaults to cmd.exe on Windows, which automatically prefixes your PowerShell script path with powershell.exe -Command. PowerShell then misinterprets that -Command as a parameter for its internal Set-Location command (used to change to your workspace directory), triggering the “Cannot find parameter named ‘Command’” error in tasks.json. The cleanest fix? Switch the task "type" to "powershell"—it runs the script directly without the shell middleman.

Contents

• The Problem with Shell Tasks and PowerShell
• Why VS Code Inserts -Command Before Your Script
• Fix 1: Switch to PowerShell Task Type
• Fix 2: Call powershell.exe Explicitly with -File
• Other Quick Tweaks for tasks.json
• Best Practices for VS Code PowerShell Scripts
• Sources
• Conclusion

The Problem with Shell Tasks and PowerShell

Picture this: you hit Ctrl+Shift+P, run your “Hello, World” task, and bam—PowerShell chokes on Set-Location complaining about a mysterious -Command parameter. Your simple tasks.json looks innocent enough, right? Just "type": "shell" and a path to hello_world.ps1. But under the hood, VS Code’s shell task doesn’t execute that .ps1 directly. On Windows, it fires up cmd.exe, passes the script path, and cmd.exe thinks, “Oh, a PowerShell file—I’ll invoke powershell.exe -Command followed by the path.”

That -Command switch? It’s legit PowerShell syntax for running inline code. Except here, the whole chain—workspace Set-Location, then -Command yourscript.ps1—gets jammed into one mangled argument. PowerShell parses -Command as belonging to Set-Location, not as its own switch. Result: ParameterBindingException with NamedParameterNotFound. Frustrating, especially when your script is dead simple like Write-Host "Hello, World".

This hits anyone using VS Code tasks.json with PowerShell scripts on Windows. It’s not a bug in your code—it’s the shell task workflow.

Why VS Code Inserts -Command Before Your Script

VS Code tasks have types like “shell”, “process”, or “npm”. "type": "shell" means “run this in the system’s default shell.” Windows default? cmd.exe. When cmd.exe sees a .ps1 path, it auto-detects and prefixes powershell.exe -Command.

Here’s the breakdown from the command line equivalent:

cmd /c powershell.exe -Command "Set-Location 'D:\work\GIT\joint-observation-complex.vscode'; D:\work\GIT\joint-observation-complex.vscode\scripts\hello_world.ps1"

PowerShell kicks off with Set-Location 'D:\work...' -Command 'D:\work...\scripts\hello_world.ps1'. Set-Location (aka cd) doesn’t know -Command, hence the error at “строка:1 знак:62”.

Why does VS Code do Set-Location first? Tasks run with your workspace as the current directory. Without it, relative paths in scripts break. Sneaky, but necessary—until it collides with cmd.exe’s habits.

This Stack Overflow thread nails the exact mechanics, confirming cmd.exe’s prefixing behavior trips up the parameter binding.

Fix 1: Switch to PowerShell Task Type

Easiest win: change "type": "shell" to "type": "powershell". VS Code detects this and invokes PowerShell natively—no cmd.exe involved.

Updated tasks.json:

{
 "version": "2.0.0",
 "tasks": [
 {
 "label": "Hello, World",
 "type": "powershell",
 "command": "${workspaceFolder}/scripts/hello_world.ps1"
 }
 ]
}

Boom. Runs cleanly: Hello, World prints without errors. PowerShell handles the directory change itself, and your script executes as intended. This is the idiomatic choice for .ps1 files in VS Code tasks.json—lightweight and foolproof.

Test it. You’ll wonder why you didn’t do this sooner.

Fix 2: Call powershell.exe Explicitly with -File

Prefer sticking with shell tasks? Override cmd.exe by calling PowerShell directly with -File, which tells it “this is a script file, not inline code.”

Tweak:

{
 "version": "2.0.0",
 "tasks": [
 {
 "label": "Hello, World",
 "type": "shell",
 "command": "powershell.exe",
 "args": ["-File", "${workspaceFolder}/scripts/hello_world.ps1"]
 }
 ]
}

-File bypasses the -Command confusion entirely. Your script path becomes a proper file argument. Works great if you need shell features or have complex args.

Or inline it: "command": "powershell.exe -File \"${workspaceFolder}/scripts/hello_world.ps1\"". Quotes handle paths with spaces.

Other Quick Tweaks for tasks.json

Stuck on shell type? Try these:

• Set working directory: Move into the script folder to shorten paths.

"options": { "cwd": "${workspaceFolder}/scripts" },
"command": "hello_world.ps1"

No full path needed—PowerShell infers it.

• Call operator with quotes: "command": "powershell.exe -Command \"& '${workspaceFolder}/scripts/hello_world.ps1'\"". The & forces script invocation; quotes protect the path.

• Avoid .ps1 extension issues: Sometimes cmd.exe fumbles extensions—explicit -File sidesteps that.

These shine when scripts take arguments or you chain tasks. But honestly, "type": "powershell" covers 90% of cases without hacks.

Best Practices for VS Code PowerShell Scripts

Don’t stop at fixes. Nail your workflow:

1. Install the official PowerShell extension—syntax highlighting, IntelliSense, debugging.
2. Use ${workspaceFolder} for paths—portable across projects.
3. Add "group": "build" or "presentation": { "echo": true, "reveal": "always" } for better task UX.
4. For params: "args": ["-param1", "value"] passes cleanly to scripts.
5. Debug? Hit F5 on .ps1 files—the extension handles it.

PowerShell in VS Code gets powerful fast. Once tuned, tasks.json becomes your automation superpower—no more Set-Location headaches.

Sources

1. VS Code не удается найти путь - Stack Overflow
   (Core explanation of cmd.exe prefixing, task types, and all listed fixes.)

Conclusion

The -Command error boils down to cmd.exe meddling in VS Code’s shell tasks.json—switch to "type": "powershell" and you’re golden, no quotes or workarounds needed. For edge cases, -File or cwd tweaks keep things flexible. Set this up right, and PowerShell scripts in VS Code run smoothly every time, saving you debug time on real work.