Skip to content
fuck-powershell

curl silently becomes Invoke-WebRequest

aliases · case

5.1misleading-erroragentciscriptfirst-partyrepro: verifiedalias-shadowing
Affectspowershell 51, windows
Fails asPARAMETERBINDING
Mechanismalias shadowing
Safe fixcurl exe

Symptom

Section titled “Symptom”

A script or coding agent runs curl -s -o out.json https://api.example.com under Windows PowerShell and gets a parameter-binding error, a prompt hanging on input, or an HTML-ish object instead of a file. The error mentions Invoke-WebRequest parameters, not curl — which sends you debugging the wrong tool.

Repro

Section titled “Repro”
Terminal window
# Windows PowerShell 5.1
Get-Command curl          # -> Alias  curl -> Invoke-WebRequest
curl -s https://example.com
# Invoke-WebRequest : Parameter cannot be processed because the parameter name 's'
# is ambiguous. Possible matches include: -SessionVariable -SkipCertificateCheck ...

Observed live: an AI agent driving a Slack integration issued curl for an API round-trip; PowerShell resolved the alias, the flags bound to Invoke-WebRequest parameters, and the call failed with an error that pointed nowhere near the cause.

Cause

Section titled “Cause”

Windows PowerShell 5.1 ships curl and wget as built-in aliases for Invoke-WebRequest. An upstream attempt to remove them (PR #1901) was closed unmerged for compatibility; 5.1 keeps the aliases forever. PowerShell 7 removed them on all platforms, so the same command behaves differently across versions.

Workaround

Section titled “Workaround”
  • Call curl.exe explicitly — the .exe suffix bypasses alias resolution.
  • Or use Invoke-RestMethod/Invoke-WebRequest with native parameters on purpose.
  • Agent system prompts targeting Windows should ban bare curl/wget.

Refs

Section titled “Refs”