When writing PowerShell scripts, I noticed when certain cmdlets encounter problems they bring up an interactive prompt, Remove-Item on a non-empty directory being an example. This is deadly when attempting to automate tasks, I'd much rather the action just fail and either throw an exception or return a bad return code so that the entire script isn't locked up waiting for a response.

Is there any way to force PowerShell to automatically fail as opposed to seeking user input on actions?

  • I think you should rename your question "How can I make Remove-Item fail fast?"
    – Jay Bazuzi
    Mar 27, 2013 at 20:38
  • 1
    This isn't specifically about Remove-Item, it's just an illustrative example. There are lots of other cmdlets that will block waiting for user input under the right conditions.
    – Chuu
    Mar 27, 2013 at 21:17

7 Answers 7


The solution proposed by Eris effectively starts another PowerShell instance. An alternative way to do this, with simpler syntax, is to shell out to another instance of powershell.exe.

powershell.exe -NonInteractive -Command "Remove-Item 'D:\Temp\t'"
  • 2
    I really like the solution, but it bring back nightmares of writing reliable stored procedures in TSQL before TRY/CATCH which required surrounding literally every query with error detection boilerplate.
    – Chuu
    Oct 6, 2015 at 17:21

See Get-Help about_Preference_Variables:

    Determines whether Windows PowerShell automatically prompts you for
    confirmation before running a cmdlet or function.


None:    Windows PowerShell does not prompt automatically.
                         To request confirmation of a particular command, use
                         the Confirm parameter of the cmdlet or function.


> $ConfirmPreference = 'None'
  • I found that to see the problem I had to set. $ConfirmPreference = 'Low'
    – Guy Thomas
    Mar 26, 2013 at 11:00
  • This does not appear to work. Remove-Item on a directory still gives you a prompt after setting $ConfirmPreference to 'None' or 'Low'
    – Chuu
    Mar 27, 2013 at 19:07
  • Works for Remove-ADUser (Server 2012R)
    – velkoon
    Dec 10, 2019 at 21:59

Ok, This is really ugly, but holy mustard stains it "works".


  • I have not figured out how to continue after the first error
  • In this case, it removes plain files, then stops at the first folder
  • I have not figured out how to make this cmdlet work if I add the UseTransaction parameter
  • This will only work for the Simple case (commands that don't do a lot of stuff with the current environment). I have not tested anything complex

    $MyPS = [Powershell]::Create()
    $MyPS.Commands.AddParameter("Path", "D:\Temp\t")


Exception calling "Invoke" with "0" argument(s): "A command that prompts the user failed because the host program or the 
command type does not support user interaction. The host was attempting to request confirmation with the following 
message: The item at D:\Temp\t has children and the Recurse parameter was not specified. If you continue, all children 
will be removed with the item. Are you sure you want to continue?"
At line:19 char:1
+ $MyPS.Invoke()
+ ~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : CmdletInvocationException
  • The reason I haven't marked this as a solution is I haven't found time to test it. Has anyone deployed or tested this code besides the author?
    – Chuu
    Oct 30, 2013 at 15:36
  • Works here. It is better than piping input into that cmdlet since "y" works for US-English, but not for German and those many other languages around the globe. So if you want to deploy one script to many hosts internationally this would be my solution since it is impossible to globally force every machine to be one language. May 23, 2021 at 18:53

I was also having the same issue. The solutions tried by me included:

  • ECHO 'Y' |
  • Command-Name -Force
  • $ConfirmPreference = 'None'

However, none of them seemed to do the trick.

What finally solved the problem was:

Powershell-Cmdlet -Confirm:$false

It suppresses all confirmation prompts for the duration of the command and the command would be processed without any confirmation.


All of the above solutions failed for me when I was create a directory, which meant that I was prompted to OK every single directory that my script created - which was a lot. What worked for me was to apped | Out-null in order to pipe the results to Out-Null

New-Item -ItemType Directory -Path $directory -Force:$true | Out-Null

Note that $Directory is a string with the full path to the directory you want to create. Hope this saves somebody some time :P


I suggest two techniques

a) Append -force

b) Append -errorAction silently continue

This is how I research which cmdlets support a particular parameter

Get-Command | where { $_.parameters.keys -contains "erroraction"}
  • One of the reasons I started down this path is that I usually want to do the opposite of -force, i.e. something like -alwaysbackoff. I've found that most commands that support -force don't seem to have any option to back off though.
    – Chuu
    Mar 24, 2013 at 8:39
  • 1
    As an aside, a convenient abbreviation for -errorAction SilentlyContinue is -ea 0.
    – Jay Bazuzi
    Mar 25, 2013 at 3:43

I was trying to do the following:

net use * /delete

And it prompted me every time to answer yes or no. Solution that worked for me and may work in other cases:

net use * /delete /y
  • 1
    That only works because you're passing an answer the cmdlet needs in the initial argument set. It will work for a cmdlet that specific needs that input, it does not work in other cases. Mar 9, 2021 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.