Bug Report: PowerShell Commands Fail with “Duplicate Key” Error in Wrapper Script

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

PowerShell commands executed through Cursor agents fail with an “An item with the same key has already been added” error, even though the actual PowerShell commands execute successfully. The issue is in Cursor’s wrapper script that processes command output.

Steps to Reproduce

Steps to Reproduce

  1. Run any PowerShell command through a Cursor agent (e.g., powershell -Command "Write-Host 'test'")
  2. Command executes successfully
  3. Cursor’s wrapper script fails during post-processing

Error Message

Get-ChildItem : An item with the same key has already been added.
At C:\Users\[USER]\AppData\Local\Temp\ps-script-[ID].ps1:40 char:16
+     $envVars = Get-ChildItem Env: | Sort-Object Name
+                ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-ChildItem], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.GetChildItemCommand

Root Cause

The error occurs at line 40 of Cursor’s temporary PowerShell wrapper script when it attempts to enumerate all environment variables using Get-ChildItem Env:.

Windows allows the same environment variable key to exist in multiple scopes (Process, User, and Machine), which is normal behavior. When Cursor’s script tries to collect these into a collection (likely a hashtable or dictionary), it fails because duplicate keys cannot be added.

Affected Environment Variables

The following environment variables have duplicate keys across scopes:

  • Path
  • PSModulePath
  • TEMP
  • TMP
  • OneDrive
  • OneDriveConsumer
  • ComSpec
  • OS
  • windir
  • USERNAME
  • PROCESSOR_ARCHITECTURE
  • PROCESSOR_IDENTIFIER
  • PROCESSOR_LEVEL
  • PROCESSOR_REVISION
  • NUMBER_OF_PROCESSORS
  • PATHEXT
  • DriverData
  • AMDRMSDKPATH
  • platformcode
  • RegionCode
  • OnlineServices

Expected Behavior

Expected Behavior

Cursor’s wrapper script should handle duplicate environment variable keys gracefully, either by:

  1. Using a method that doesn’t fail on duplicates (e.g., [System.Environment]::GetEnvironmentVariables() with proper deduplication)
  2. Filtering duplicates before processing
  3. Using a collection type that allows or handles duplicates appropriately

Actual Behavior

The wrapper script crashes when encountering duplicate environment variable keys, even though the actual user command executed successfully.

Workaround

  • Run PowerShell commands directly in terminal instead of through Cursor agents
  • Use CMD (cmd /c) for simple commands when possible
  • Use -NoProfile flag to reduce environment variable conflicts (partial workaround)

Operating System

Windows 10/11

Version Information

System Information

  • OS: Windows
  • Cursor Version: 2.4.21
  • PowerShell Version: Windows PowerShell 5.1 (or PowerShell Core if applicable)

Additional Notes

  • The actual PowerShell commands work correctly when run directly
  • This appears to be a bug in Cursor’s post-processing/wrapper script, not in PowerShell itself
  • The issue may have been exposed or worsened by recent Windows updates that modified environment variable handling

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the report.

This is a new bug with the PowerShell wrapper script that Cursor uses to run commands through the agent. The issue is that the script tries to collect environment variables via Get-ChildItem Env:, and on Windows the same variable (Path, TEMP, etc.) can exist in multiple scopes (Process, User, Machine), and the script can’t handle that.

There isn’t an official fix yet, but there’s a workaround that has helped with other PowerShell issues caused by the same wrapper script:

  1. Open Cursor Settings (Ctrl+Shift+J)
  2. Go to Agents, then find Legacy Terminal Tool
  3. Turn it on
  4. Press Ctrl+Shift+P then run Terminal: Kill All Terminals
  5. Fully restart Cursor
  6. Try the commands again

Legacy Terminal Tool uses the older implementation, which may avoid this wrapper script issue.

If it doesn’t help, let me know.

Related issues with the same wrapper script: