2026.3.3 Running script causes issue with [string[]] type input when switching from Parameters to Action Preferences

Hello @realslacker

Thank you for reporting this issue and for providing clear reproduction steps.

The error appears to occur when returning to the Parameters tab after switching to Action Preferences with a `[string[]]` parameter.

I’ll work on reproducing this behavior in PSU 2026.3.3 using your example and check whether it also occurs in an earlier version.

I’ll share my findings here once the testing is complete.

Best regards,
Ruben Tapia

Hello @realslacker

Thank you for your patience.

I was able to reproduce the reported behavior in PSU 2026.3.3 and confirmed that the same exception also occurs in 2026.3.2.

Additional testing confirmed that the issue occurs when a `[string[]]` parameter contains a value and the user switches between the Parameters and Action Preferences tabs. The behavior was reproduced consistently across multiple attempts.

Based on these findings, I'll proceed with an internal escalation for further investigation.

I'll share any relevant updates here as they become available.

Best regards,
Ruben Tapia

Hello @realslacker,

Thank you for the clear steps and for your patience. Your example script is enough to trigger the error, so this looks like a defect in the Run Script dialog.

The error comes from the dropdown control the dialog uses for a [string[]] parameter (the AntDesign Select in your stack trace). In our test the same steps do not fail on 2026.3.0, so it came in with a later release. Going to the Execution tab and back causes it too, not only Action Preferences. Once it has appeared, the Run button starts nothing, and closing the dialog does not clear it: the Scripts page stays replaced by the error until you reload the page.

Until it is fixed, this worked in our tests on 2026.3.3 (Linux, in Chromium): make any change you need on the Action Preferences tab first, then enter the values on the Parameters tab last and click Run straight away. Do not switch tabs after entering a value. The job ran every time with one value and with two values (3 of 3 tries each). After an error, reloading the page and opening Run Script again worked (3 of 3 tries).

I have prepared the reproduction details as a defect report for our development team. I cannot give you a fix version or a date yet, and I will update this topic as soon as I have either.

Best regards,
Michel

I am also seeing this error when I have a [string] option with a validate set that I change AFTER changing a [string[]] option or if I change the value of the [string] option with a validate set and then the [string[]] option and close the run dialog.

Additionally, it seems that if there is a default value for the entry with validate set it is not filled in the Run dialog (not sure if that's intentional).

param( [string[]] $ChangeFirst, [ValidateSet( 'Value1', 'Value2', 'NotFilled' )][string] $ChangeSecond = 'NotFilled' )

Hello @realslacker,

Thank you for the second script. I ran both of your sequences on 2026.3.3 in our lab (Linux, Chromium), and both raise the same error as your first script.

Entering a value in the [string[]] field and then choosing a value in the ValidateSet field raises it, and Run then starts nothing (3 of 3 tries). Choosing the ValidateSet value first, then entering the [string[]] value and closing the dialog raises it as the dialog closes, and the Scripts page is replaced by the error (3 of 3). On 2026.3.0 neither sequence fails (3 of 3 each).

The workaround is the same as before with one addition: choose the ValidateSet value before you enter the [string[]] values, enter those last, and click Run straight away rather than closing the dialog. With your script the job received both parameters every time on 2026.3.3: with one value, with one value after changing an Action Preferences setting first, and with two values (3 of 3 each).

About the default: the ValidateSet field opens empty on both 2026.3.3 and 2026.3.0, but when we left it untouched, the job still ran with your script's own default, NotFilled (3 of 3 on each version). The empty field is not new: the same behaviour was reported on 2026.1.5 and is already logged as a known issue.

I have written up your two sequences for our development team's review. There is still no fix version or date for either issue; I will update this topic when I have one.

Best regards,
Michel

That works fine until you have multiple string parameters. On some of my more complicated scripts I've had to resort to using the Invoke-PSUScript cmdlet to run jobs. This is an annoyance for me, but some of my less technical users are basically unable to use the product right now.

Additionally, in the case where you are able to enter the parameters successfully and submit the job the dialog is not cleared.

Example:

param( [ValidateSet( 'Value1', 'Value2', 'NotFilled' )][string] $ChangeFirst = 'NotFilled', [ValidateSet( 'Value1', 'Value2', 'NotFilled' )][string] $ChagneSecond = 'NotFilled', [string[]] $ChangeThird, [string[]] $ChangeFourth  )

Hello @realslacker,

Thank you for the four-parameter script and for telling us how this affects your users. I ran it on 2026.3.3 in our lab and with [string[]] fields the Run Script dialog does misbehave on 2026.3.3 (the same error when it is closed by Esc or a click outside it, and a leftover layer that blocks clicks until you reload the page). It is logged as a defect with our development team, and I have documented your users' situation for their review. There is no fix released and no date yet, and I will update this topic when I have one.

For your less technical users, declaring those two parameters as [string] held in our tests. The dialog then shows a plain text box (https://docs.devolutions.net/powershell-universal/automation/scripts/parameters), and the script splits the value.

$Third = @($ChangeThird -split ',' | ForEach-Object { $_.Trim() } | Where-Object { $_ })

The same goes for $ChangeFourth. Users type alpha,beta in the box, and I got both values in the script with no error. Invoke-PSUScript callers must then pass one comma-separated string, so no value can contain a comma.

Best regards,
Michel

@Michel Audi don't love the work around. It breaks the ValidateSet behavior and requires users to know to enter a comma separated value. It also introduces a lot of error checking. For example should I trim spaces? What if the string should end or being with a space... do I require all strings to be quoted? Now I have to remove quotes and people have to remember to include quotes.

There really seems to be a lot of regression around inputs through the GUI.

Hello @realslacker,

Thank you for the honest feedback. You are right that the [string] workaround costs your users the ValidateSet behavior and makes them type a comma-separated list, and I understand the frustration with the GUI inputs in this release.

There is some progress on the error itself. Our development team has corrected the error with [string[]] fields in the Run Script dialog when you switch tabs or change another parameter, and the correction has passed their testing. It is planned for an upcoming release. I cannot confirm yet that it also removes the leftover layer that blocked clicks after Run, and the empty ValidateSet default remains a separate known issue. I do not have a release date yet, and I will update this topic when it is out.

On your two questions, in case you keep the workaround until then. The Trim() in my example removes the spaces at both ends of every value, so a value that has to start or end with a space cannot get through it. Quotes do not help either. With "gamma, delta" in the box, the line splits it into two values, "gamma and delta", each keeping one of the quote marks.

Handling both cases would mean writing your own parsing and teaching every user a quoting rule, which is the burden you describe. For scripts whose values can hold a comma or an edge space, I would not build that, and would keep running them with Invoke-PSUScript as you already do until the fix is installed.

Best regards,
Michel