A Positional Parameter Cannot Be Found That Accepts Argument True | Fix

What This Powershell Error Message Actually Means

When PowerShell throws the line A positional parameter cannot be found that accepts argument 'True', it is telling you that it received the value $true (or True) in a position where it expected some other kind of argument. The command line has more values than the cmdlet, function, or script can map to its positional parameters, so PowerShell refuses to guess and raises this message instead.

PowerShell parameters come in two main flavors: named and positional. Named parameters use a dash and a name such as -Path or -Recurse. Positional parameters can be supplied without the name because PowerShell knows the order. When you pass True in the wrong spot, the command line no longer matches that expected order, which leads to the error.

The phrase A positional parameter cannot be found that accepts argument 'True' does not mean PowerShell cannot handle boolean values. It simply means that the specific command you just typed does not have any parameter in that position that can legally take the value True. The fix comes from aligning your arguments with the parameters that actually exist.

• Read the full error text — Check which cmdlet name appears in the message so you know which command is failing.
• Look at the argument order — Compare the way you typed the command with the syntax for that cmdlet.
• Watch stray “true” values — A leftover $true or True at the end of a line is a very common trigger.

A Positional Parameter Cannot Be Found That Accepts Argument True Error Causes

In practice, this error appears in a small number of recurring patterns. Often you are close to correct syntax, but one True value sits where PowerShell expects something else. Understanding these patterns turns a confusing red message into a quick fix.

Using Switch Parameters Like Normal Booleans

PowerShell switch parameters are flags. They are either present or not present. A classic case looks like this:

# Wrong
Get-ChildItem -Recurse -Force $true

# Right
Get-ChildItem -Recurse -Force
  

In the wrong version, $true becomes an extra positional argument after all named parameters, so PowerShell looks for a parameter that can accept that value and fails. In the right version, -Force stands alone. The switch is either on or off based on its presence.

Misplaced Boolean Values For Non-Switch Parameters

Some parameters are real booleans rather than switches. You can set them to $true or $false, but they still need to match the parameter they belong to. A pattern that often causes trouble looks like this:

# Wrong
Test-Feature $true "Server01"

# Right
Test-Feature -Enabled $true -ComputerName "Server01"
  

In the wrong version, PowerShell maps the first value to the first positional parameter. If the parameter order does not match, $true lands on a parameter that expects another type, and the function call falls apart. Using named parameters makes the intention clear and prevents $true from drifting into the wrong slot.

Extra Arguments At The End Of A Command Line

Another common cause is a stray token at the end of the command, often from a half-removed condition or an old test. A line such as:

Get-Service -Name "Spooler" True

contains an extra value after "Spooler". The Get-Service syntax does not have any positional parameter left to map that True value, so you see a positional parameter cannot be found that accepts argument true across your console.

• Check for leftover test flags — Remove any True or $true you used while debugging a pipeline.
• Compare with documentation — Use Get-Command -Syntax to verify how many positional parameters the command accepts.
• Group values with names — Once arguments have clear parameter names, stray values stand out instantly.

Quick Ways To Fix The Error In Interactive Powershell

When you see this message in an interactive session, the goal is to adjust your command with as little disruption as possible. The fixes are usually straightforward once you check the syntax that PowerShell expects for the cmdlet or function you are running.

1. Check The Command Syntax — Run Get-Command -Syntax to see valid parameter sets and the order of positional parameters.
2. Switch To Named Parameters — Replace raw values with explicit names so that booleans and strings cannot swap places by accident.
3. Remove Extra True Values — Trim any trailing True or $true that does not match a parameter in the syntax output.
4. Use Help For Extra Context — Run Get-Help -Detailed to see which parameters accept booleans and which ones are switches.

In many teams, the error shows up when someone copies a line from an online snippet and adds $true to a switch parameter because they are used to languages where every flag takes an explicit boolean. In PowerShell, switches do not need that value. Removing the extra word or converting the parameter to a proper boolean flag eliminates the message.

• Keep booleans named — Call parameters such as -Enabled or -Confirm with their full names and pass $true or $false explicitly.
• Leave switches alone — For switches such as -Recurse, just include the name when you want the behavior, without any extra value.
• Use line breaks — Split long commands across several lines with backticks so you can see each argument clearly.

Fixing The Error In Powershell Scripts And Functions

When the error appears inside a script rather than a one-off command, you need to look at both the call site and the function definition. Sometimes the call is fine, and the parameter definitions create confusion about which arguments are positional and which are named.

Define Parameters With Clear Types

A clean parameter block helps PowerShell map arguments correctly. This example separates switch and boolean flags:

function Invoke-Maintenance {
    [CmdletBinding()]
    param(
        [switch]$Force,
        [bool]$EnableLogging
    )

    if ($Force) {
        # skip safety prompts
    }

    if ($EnableLogging) {
        # write logs
    }
}

With this design you would call the function as:

Invoke-Maintenance -Force -EnableLogging $true

If instead you call:

Invoke-Maintenance $true $true

PowerShell can still map the arguments, but once you add more parameters or change the order, that style becomes brittle and can lead to A positional parameter cannot be found that accepts argument true when the mapping no longer fits.

Reordering Parameters In Existing Scripts

Existing scripts written without clear parameter names often rely on positional order. When someone adds a new parameter to the beginning of the list, older calls start sending values to the wrong place. A call that once worked may suddenly throw the error message you are chasing.

• Scan the parameter block — Check which parameters have position attributes and how they line up with existing calls.
• Add explicit names in calls — Update script calls to use named parameters so future changes in order do not break them.
• Stage changes — Adjust one function at a time and test each call path rather than editing several related scripts at once.

Examples Table Of Correct Versus Wrong Syntax

The patterns behind the error repeat across many commands. This small table shows common variations where a positional parameter cannot be found that accepts argument true, paired with a corrected version and a short explanation. Each row mirrors a real kind of mistake rather than a contrived case.

Treat the wrong commands in the table as a checklist. If your own line looks similar, remove the extra True value, add missing parameter names, or convert the flag into a proper switch. That small change is often enough to clear the error message.

How To Prevent This Error In Everyday Powershell Work

Once you have fixed the current command, you probably want to avoid seeing the same red text again next week. The good news is that a few simple habits remove most cases where a positional parameter cannot be found that accepts argument true pops up in scripts or interactive sessions.

1. Favor Named Parameters Over Positional Ones — Write commands like Test-Connection -ComputerName "Server01" -Quiet instead of piling up values without names.
2. Separate Switches And Booleans — Use [switch] for on/off flags without a value and [bool] when you genuinely need a true or false argument.
3. Keep Long Commands Readable — Break wide command lines into one parameter per line so that an extra value stands out during code review.
4. Run Syntax Checks Early — When you start using a new cmdlet, call Get-Command and read the syntax block before writing longer scripts around it.

As you work more with PowerShell, you will spot the patterns faster. Seeing A positional parameter cannot be found that accepts argument true then becomes a quick reminder to check for an extra boolean, a missing parameter name, or an outdated script call rather than a blocker that slows your shell session.

Over time these habits keep your scripts easier to read, easier to adjust, and far less likely to break when someone adds new parameters or updates existing cmdlets on a server. Instead of chasing the same error across many files, you can spend your energy on the actual task your automation should handle.

Send us your feedbackTell us what you thought about this post

Name * Email *

Your comment *

Quick check — what is …? *

Send feedback