Hello everyone. Since last night a couple of my projects which use the same invoke power shell activity at the beginning have been failing when running through assistant, and after investigating today it seems to be an issue with the invoke power shell activity.
No matter what command I enter in the CommandText field, it fails with the following error message: [Error] Invoke Power Shell: An error has occurred which PowerShell cannot handle. A remote session might have ended.
Here are the configuations for the activity:
Coninue On Error: Unchecked
CommandText: "Write-Output 'Hello world'" (tried with this as well as the regular command which fires a trigger in the event log which I handle through the task scheduler)
Input: empty
Execution Mode: PowerShell 5.1 (32-bit)
IsScript: Checked
Private: Unchecked
Type Argument: String for the hello world output, System.Management.Automation.PSObject for the actual command we run
Output: empty
The studio version is: 2026.0.198 STS
When running the same commands in a regular power shell window manually the work as they should.
These are the packages I have installed for the project with their versions:
Something changed on the machine overnight, not in your project. In order of probability:
EDR/AV policy push (CrowdStrike, Defender ASR, Carbon Black, SentinelOne) now blocking child-process spawning of powershell.exe from a non-shell parent.
This is the #1 cause of this exact symptom.
Windows Update / .NET servicing update applied overnight.
GPO change enforcing Constrained Language Mode, WDAC/AppLocker, or a restrictive Execution Policy.
Note it fails through Assistant-launched jobs run under a different token/session than Studio. Test in Studio too; if Studio works and Assistant doesn’t, it’s almost certainly a policy/context issue, not a package issue.
Solution Steps:
Step 1: Change Execution Mode to 64-bit
Open the Invoke PowerShell activity → set Execution Mode from PowerShell 5.1 (32-bit) to PowerShell 5.1 (64-bit) → run Write-Output ‘Hello world’.
Step 2: If still failing, set Execution Mode to “Current Process”
This runs PowerShell in-process instead of spawning a child process. Test the same command.
Step 3: Whitelist UiPath in your AV/EDR
Ask your security team to add exclusions for:
UiPath.Executor.exe
UiPath.Agent.exe
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
Check Defender/EDR logs at the failure timestamp for a blocked process-creation event.
Step 4: Verify PowerShell policy under the robot account
Run in PowerShell as the robot user:
Must return FullLanguage. If it returns ConstrainedLanguage, raise with your AD/GPO admin to exclude the robot machine from the WDAC/AppLocker lockdown policy.
Step 5: Roll back the package
Manage Packages → downgrade UiPath.System.Activities from 26.6.2 to the previous minor version → rebuild → test.
Step 6: Workaround if production is blocked now
Move the code into a .ps1 file and call it via Start Process: