Bug Report

Hi, Running v2026.2.4. I have a scheduler script, that spawns off instances of another script. In a test run it spawned 76 child jobs. However I noticed from the scheduler/parent job, under the 'child jobs' tab, only a maximum of 50 jobs is displayed with no pagination, it seems they're just truncated at the 50 mark. I had to go into the main job list to find them. Thanks, Tom

Our Powershell Universal has been upgraded from 2026.2.3 from 2026.1.2. After upgrade, our API endpoints started encountering gateway timeouts. It seems that executing commands as simple as "Get-PSUSchedule -Integrated" in a custom API Endpoint hang or take excessively long to execute. The same command executed in the same environment in script or locally on the server takes about 20 seconds to execute. I increased the API endpoint timeout to 300s here and it still timed out. 2026-08-11 09:14:17.262 -04:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request starting HTTP/1.1 GET <redacted> - null null 2026-08-11 09:14:17.265 -04:00 [INF][Microsoft.AspNetCore.Routing.EndpointMiddleware] Executing endpoint 'GET:<redacted>' 2026-08-11 09:14:17.287 -04:00 [INF][] GET /logicmonitorcheck <redacted>026-08-11 09:19:21.245 -04:00 [INF][Microsoft.AspNetCore.Routing.EndpointMiddleware] Executed endpoint 'GET:<redacted>' 2026-08-11 09:19:21.245 -04:00 [ERR][Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware] An unhandled exception has occurred while executing the request. Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.") ---> System.OperationCanceledException: The operation was canceled. --- End of inner exception stack trace --- at ProtoBuf.Grpc.Internal.Reshape.UnaryTaskAsyncImpl[TRequest,TResponse](AsyncUnaryCall`1 call, MetadataContext metadata, CancellationToken cancellationToken) at PowerShellUniversal.Api.ApiGrpc.ExecuteAsync(ApiRequest request, CancellationToken cancellationToken) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Api\ApiGrpc.cs:line 193 at PowerShellUniversal.Api.ApiService.ExecuteEndpointAsync(HttpContext httpContext, Endpoint endpoint, Dictionary`2 variables) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Api\ApiService.cs:line 792 at PowerShellUniversal.Api.ApiService.ExecuteAsync(HttpContext httpContext, Endpoint endpoint) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Api\ApiService.cs:line 504 at Universal.Server.Routing.ApiEndpointSource.HandleAsync(HttpContext context, Endpoint endpoint) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Routing\ApiEndpointSource.cs:line 77 at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|7_0(Endpoint endpoint, Task requestTask, ILogger logger) at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) at PowerShellUniversal.FeatureMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\FeatureMiddleware.cs:line 42 at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at PowerShellUniversal.DisallowedModeMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\ModeMiddleware.cs:line 25 at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at PowerShellUniversal.CspMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\CspMiddleware.cs:line 28 at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at Universal.Server.Middleware.RoutingMiddleware.Invoke(HttpContext httpContext, IPolicyEvaluator policyEvaluator) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\RoutingMiddleware.cs:line 165 at PowerShellUniversal.PSUMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\PowerShellMiddleware.cs:line 15 at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at Universal.Server.Middleware.RegexApiMiddleware.Invoke(HttpContext httpContext, IApiService apiService) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\RegexApiMiddleware.cs:line 19 at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext) at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider) at Universal.Server.Middleware.WindowsAuthMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\WindowsAuthMiddleware.cs:line 58 at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at Universal.Server.Middleware.SwaggerAuthenticationMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\SwaggerAuthMiddleware.cs:line 51 at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at Universal.Server.Middleware.McpAuthenticationMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Middleware\McpAuthenticationMiddleware.cs:line 30 at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext() --- End of stack trace from previous location --- at StackExchange.Profiling.MiniProfilerMiddleware.Invoke(HttpContext context) in C:\projects\dotnet\src\MiniProfiler.AspNetCore\MiniProfilerMiddleware.cs:line 112 at AspNetCoreRateLimit.RateLimitMiddleware`1.Invoke(HttpContext context) in D:\a\powershell-universal\powershell-universal\src\AspNetCoreRateLimit\Middleware\RateLimitMiddleware.cs:line 109 at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddlewareImpl.<Invoke>g__Awaited|10_0(ExceptionHandlerMiddlewareImpl middleware, HttpContext context, Task task) 2026-08-11 09:19:21.246 -04:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request finished HTTP/1.1 GET <redacted> - 500 null text/plain 299970.7853ms

PSU 2026.1.6 Priority: High The behaviour has been more stable in recent releases, but modules that are not in the main PSU repo are still vanishing after a git sync when the sync changes files in the main repo. This can be fixed by the known method of reloading modules. If the git sync is stale and has no changes to sync, things are stable and don't require manual intervention. So: automated git sync -> git detects changes and PSU reloads config(?) -> git sync delayed trigger -> PSU script getting submodules -> modules with PSU resources vanish in the script view This is the general sequence, but I can't tell when exactly in the process the external modules vanish. It might be as early as the second step and everything after it doesn't matter. The consequence of this is not only cosmetic, the vanishing resources also can't be triggered via Invoke-PSUScript anymore.

Currently the identities search is case sensitive. Please remove case sensitivity

Title: VS Code extension: editing a file-backed API endpoint saves to the wrong path (.universal prefix dropped) ## Summary In the PowerShell Universal VS Code extension 2026.2.3, using the per-endpoint Edit action on an API endpoint backed by an external script file (-Path) opens and saves the file resolved against the repository root instead of the .universal directory where the runtime actually stores/executes it. Edits are written to the wrong location and never reach the running endpoint — the save silently has no effect. ## Environment - PowerShell Universal server: 2026.2.3 - VS Code extension: ironmansoftware.powershell-universal 2026.2.3 - Windows; repository at C:\ProgramData\UniversalAutomation\Repository (config-as-code, git-backed) ## Steps to reproduce 1. In the admin UI, create a file-backed endpoint via the Path parameter — URL /pathtest, Path pathtest.ps1. PSU creates ...\Repository\.universal\pathtest.ps1 and stores path = "pathtest.ps1". 2. In VS Code, use the endpoint's Edit action to open pathtest. 3. Modify the code and save. 4. Call GET /api/pathtest. ## Expected Changes are written to .universal\pathtest.ps1 and, after a configuration reload, the endpoint returns the updated output. ## Actual - Edit opens/saves a file at the repo root (...\Repository\pathtest.ps1) — a different file from the one the runtime reads. - The endpoint keeps serving the original code; the edit is silently lost. - Confirmation: writing directly to .universal\pathtest.ps1 does update the endpoint after reload, proving the runtime file is the .universal copy while Edit targets the repo root. ## Root cause (from the extension code) - getEditableEndpointPath() returns endpoint.path (e.g. "pathtest.ps1") with no .universal prefix. - editResource() sets configurationPath = resourcePath for endpoints (unlike scripts, which use getScriptConfigurationPath() with a base folder), then opens createConnectionFileUri(profile, configurationPath). - The psu:// filesystem provider calls getFileContent(toRelativePath(uri)) -> GET /api/v1/configuration/content/pathtest.ps1, relative to the repo root — not .universal. The stored path is .universal-relative (runtime), but the extension treats it as repo-root relative (editor); the two resolve to different files. ## Related symptoms - Inline endpoints (path = null) throw "Endpoint '/api/x' does not have a configuration file path." on Edit. - A file-backed endpoint whose -Path doesn't match a real file (e.g. -Path "/gam/get_userinfo" when the file is gam/Get_user_info.ps1) is likewise unopenable. ## Impact Per-endpoint editing of file-backed API endpoints from VS Code does not work — edits appear to succeed but are discarded. ## Suggested fix Resolve an endpoint's editable path against the .universal directory (the base the runtime uses for -Path), consistent with how scripts resolve via a base folder — e.g. have getEditableEndpointPath()/editResource() prefix .universal/ (or use fullPath) for endpoint resources.

Hi, I would like to log failed login attempts and have noticed that Write-PSULog -Level Error -Message "error" does not log at all when used inside the Authentication.ps1. I would appreciate it if either Write-PSULogs could be used or if auth failures were logged by the platform natively. A "auth failed" trigger event would also be helpful since there is already an event for API auth failure.

HideMiniMap switch is not working: New-UDCodeEditor -Code "Get-Process notepad" -Original "Get-Process code" -Theme 'vs-dark' -Language 'powershell' -Height '200' -Width '100%' -ReadOnly -Id 'codeEditor3' -HideMiniMap [image]

Hi, After providing the name and role and clicking OK, the modal stays in the loading state. Reloading the page after a minute shows that nothing happened. Creating External Accounts with a script works. Creating local DB Identitys are not affected.

Hi, I've noticed the following behaviour when using DontShow as a parameter definition in scripts example: param( [Parameter()] $Test, [Parameter(DontShow)] $Test2 ) When running the script in the GUI 'Test2' does not show, which is expected and correct. However, When using the following command in another script: This works: Invoke-PSUScript -Script "HelloWorld.ps1" -Integrated -Parameters @{Test="testString"} This fails: Invoke-PSUScript -Script "HelloWorld.ps1" -Integrated -Parameters @{Test="testString";Test2="asdsad"} The error message is: Unknown parameter Test2. Parameters for this script are Test Expected behaviour for me is that DontShow is reflected in the admin menu run script popup, but still available as a parameter via Invoke-PSUScript. Is this a bug or is this intentional behaviour? Thanks, Tom

Product / Version: PowerShell Universal 2026.2.3 Previous version: 2026.1.7 Environment: Windows Server, self-hosted, IIS-fronted Database backend: SQLite (database.db) Repository path: default .universal repository directory Summary: Creating new Variables works correctly. However, triggering "Reload Variables" under Settings → Files causes all existing Variables — both file-based (variables.ps1) and database-backed (-Database storage option) — to have their Value reset to $null. This effectively wipes previously working configuration (including Run-As credentials used by API endpoints) every time a reload is performed. Steps to reproduce: Run PowerShell Universal 2026.2.3 (upgraded from a prior 2026.1.7 release) with existing Variables configured (file-based and database-backed). Navigate to Settings → Files. Trigger "Reload Variables" (via the sync/reload action on that page). Observe: all previously existing Variables now show Value = $null in Platform → Variables. Newly created Variables (created after the reload) work fine until the next reload is triggered. Downstream impact: Because Run-As credential Variables lose their values after reload, API endpoints depending on them fail to start their proxy process: "System.Exception: Failed to login user (1326). System.ComponentModel.Win32Exception (1326): The user name or password is incorrect. at PowerShellUniversal.Automation.ProcessHelper.LogInOtherUser(...) at PowerShellUniversal.Automation.JobProcessManager.StartProcessAsNewUser(...) at PowerShellUniversal.Api.ApiGrpc.StartAsync(ExecutionEnvironment environment, Variable credential) at PowerShellUniversal.Api.ApiService.AddEndpointAsync(Endpoint endpoint) at PowerShellUniversal.Configuration.EndpointService.CreateAsync(...)" Question for support: Is this a known regression tied to the security fixes shipped in 2026.2.3 (CVE-2026-16801 — variable.ps1 escaping fix, and CVE-2026-16802 — secrets without a vault no longer written to variables.ps1)? Specifically: Does the reload logic now fail to parse Variables written in the old (pre-2026.2.3) format, silently defaulting Value to $null instead of erroring? Is this specific to database-backed Variables, file-based Variables, or both (we see it on both)? Is there a way to prevent "Reload Variables" from wiping values until this is fixed, or a recommended manual recovery step after a reload occurs?

PSU 2026.2.3 - PostgreSQL DB - Linux - Podman/Docker Rootless Hey, Noticed an issue with creating new secret and variables. I had issues with new secrets in prior versions but only had time today to investigate, so i don't know if its new. [image] Creating a secret / var and using it in an app always returns an empty string. Old secrets and vars are not affected. [image] [image] Oddly changing the order breaks the app [image] [image] To test i tried to output the variable in a script [image] [image] while testing i found some other bug: [image] [image] I hope this gets fixed soon

PowerShell Universal 2026.2.2.0 fails to start with a self-hosted PostgreSQL database. The service crashes with: System.ObjectDisposedException: Cannot access a disposed object. Object name: 'System.Threading.ManualResetEventSlim'. at Npgsql.Internal.NpgsqlConnector.ResetCancellation() This happens on a fresh, empty database, whether starting the Windows service or running `psu db schema` via CLI. This matches known open issues in the Npgsql project (npgsql/efcore.pg#3699, npgsql/npgsql#6415), tied to Npgsql.EntityFrameworkCore.PostgreSQL under .NET 10. As a test, I installed PowerShell Universal 5.6.12 (version before the .NET 10 upgrade) against the same empty database - the schema was created successfully with no errors. After uninstalling 5.6.12 and reinstalling 2026.2.2.0 against that same, now fully-migrated database, the service still crashes with the same exception, just at a different point during startup. This suggests the issue isn't limited to schema creation - it affects Npgsql more broadly under 2026.2.2.0/.NET 10, and makes PostgreSQL unreliable as a backend for this version.

The width of New-UDPaper and New-UDTable are different. [image] Inspecting the CSS, the Table has the width set to 100%, the paper not.

Trying to use the `New-UDMenu` component in a custom category-bar under my main app-bar for custom navigation using menues to navigate to pages, the `-ClassName` Parameter does not function like it does on any other component with this parameter. Its also the only component with a diffect description for the parameter, not mentioning a "CSS class to apply...", so this might not be a simple type error?

it used to tell you the current version and if there was an upgrade. by accident, we found it by scrolling all the way down on the home page and found it in the bottom right. not easy to find.

If you use credential on apps and upgrade from 2026.1.7 to 2026.2, 2026.2.1 or 2026.2.2 The app will be unable to start. If you remove the credential the app will be able to start. If you then set a credential and restart the app - the app will fail to start an report this: An error occured. Failed to login user (1326). System.ComponentModel.Win32Exception (1326): The user name or password is incorrect. at PowerShellUniversal.Automation.ProcessHelper.LogInOtherUser(ProcessStartInfo processStartInfo) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\ProcessHelper.cs:line 156 at PowerShellUniversal.Automation.ProcessHelper.StartProcess(ProcessStartInfo processStartInfo, ILogger logger) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\ProcessHelper.cs:line 41 at PowerShellUniversal.Automation.JobProcessManager.StartProcessAsNewUser(String powerShellPath, String commandLine, Variable credential, Dictionary`2 environmentVariables, String verb) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 914 at PowerShellUniversal.Automation.JobProcessManager.StartProcess(ExecutionEnvironment environment, Variable credential, String powerShellPath, String commandLine, ProcessType type, Action`1 onAgentOutput, Dictionary`2 environmentVariables) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 684 at PowerShellUniversal.Automation.JobProcessManager.StartDashboard(Int32 port, ExecutionEnvironment environment, Variable credential) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 429 at Universal.Server.Services.DashboardProxy.StartOutOfProcessAsync(Dashboard dashboard, ExecutionEnvironment environment) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardProxy.cs:line 242 at Universal.Server.Services.DashboardProxy.Start(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardProxy.cs:line 98 at Universal.Server.Services.DashboardManager.StartOnNode(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 95 at Universal.Server.Services.DashboardManager.Start(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 46 at Universal.Server.Services.DashboardManager.Restart(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 138 at PowerShellUniversal.AppPowerMenu.Restart() in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Shared\Apps\AppPowerMenu.razor:line 98 at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task) at AntDesign.MenuItem.HandleOnClick(MouseEventArgs args) at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task) at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

Head Element | Devolutions PowerShell Universal | Product guides & reference The example for Styles above shows -Children, however this param doesnt exist in the latest PSU version and instead it should be -Content

New-UDAutocomplete components with the -Multiple parameter allow individual options to be selected more than once. I previously opened an issue, with examples to reproduce the bug, here: https://github.com/ironmansoftware/powershell-universal/issues/5241 That was for version 5.6.7, but the bug still exists in 2026.2.3. Can this be fixed? Otherwise, is there a workaround?

I reproduced this on a PowerShell Universal dashboard page at `/test`. `New-UDTable -InitialState` accepts an initial state containing `Search`, `Filters`, `OrderBy`, and `PageSize`. However, when a table is recreated inside a synced `New-UDDynamic` with the same table ID, the refreshed `InitialState` is emitted by the server but is not reflected in the existing client-side table UI. Minimal reproduction ```powershell New-UDPage -Name 'Test' -Url '/test' -Content { New-UDButton -Text 'Apply Bob state' -OnClick { $Page:testCasesBulkNoteTableState = @{ Search = 'bob' Filters = @( @{ id = 'name' value = '-2' } ) OrderBy = @{} PageSize = 12 } Sync-UDElement -Id 'testClearFilterDynamic' } New-UDDynamic -Id 'testClearFilterDynamic' -Content { $tableState = $Page:testCasesBulkNoteTableState New-UDTable -Id 'table7' ` -Data @( [pscustomobject]@{ Name = 'Alice - 1' } [pscustomobject]@{ Name = 'Bob - 2' } ) ` -Columns @( New-UDTableColumn -Property 'Name' -Title 'Name' -Id 'name' ) ` -ShowSearch ` -InitialState $tableState } } ``` Expected behavior After clicking **Apply Bob state**, syncing the enclosing `New-UDDynamic` should cause the same-ID table to apply the newly rendered `InitialState`: ```json { "Filters": [{ "value": "-2", "id": "name" }], "PageSize": 12, "OrderBy": {}, "Search": "bob" } ``` In particular, the search input should show `bob`, and the state should apply in the same way as a table initially mounted with that payload. Actual behavior On first render, `$Page:testCasesBulkNoteTableState` is `$null`, so `table7` mounts with an empty search input. After the button assigns the state and calls `Sync-UDElement` on the enclosing dynamic region: - Server-side instrumentation shows the recreated `New-UDTable` component emits the exact `initialState` JSON above. - The post-sync payload is byte-for-byte identical to a separately mounted hard-coded control table that displays `bob`. - With the stable table ID `table7`, the original search input node remains connected after the dynamic sync and remains blank. - The updated `InitialState` is therefore not applied to the existing same-ID client table. Changing only the child table ID after the click, for example from `table7-r0` to `table7-r1`, forces a new mount and the search input correctly displays `bob`. Confirmed observations The reproduction ruled out: - `$Page:` scope availability after the click - Hashtable versus ordered hashtable / JSON serialization behavior - Filter ID casing; the final state uses `name`, matching the column ID - A mismatch in the emitted `initialState` payload - Syncing the table directly; only the enclosing `New-UDDynamic` can be synced in this scenario Request Could PSU provide a supported mechanism for a same-ID `New-UDTable` to apply a refreshed `InitialState` when its enclosing `New-UDDynamic` is synced? Alternatively, an explicit supported client-state update API for `New-UDTable` would address this use case. Changing the table ID is not a practical workaround because it resets the table's client state and uses component identity as a forced refresh rather than applying the intended updated state. Workaround The current workaround is to maintain a page-scoped revision and include it in the child table ID, incrementing that revision immediately before syncing the enclosing `New-UDDynamic`: ```powershell $Page:testCasesBulkNoteTableRevision = [int]$Page:testCasesBulkNoteTableRevision + 1 Sync-UDElement -Id 'testClearFilterDynamic' New-UDDynamic -Id 'testClearFilterDynamic' -Content { $revision = [int]$Page:testCasesBulkNoteTableRevision New-UDTable -Id "table7-r$revision" ` -InitialState $Page:testCasesBulkNoteTableState ` # existing columns and load-data configuration } ``` For example, the table ID changes from `table7-r0` to `table7-r1` when applying the preset state. This forces the client to mount a fresh table and causes `Search = 'bob'` to appear. It is a functional workaround, but it discards existing client-side table state, so it should not be required for a same-ID refreshed `InitialState`.

variables.ps1 serializer does not escape quotes in variable values — corrupts the config file **Version:** Reproduced on 2026.2.2 and 2026.1.6 (Windows, IIS-hosted and self-hosted) **Summary** Creating a plain (non-vault) variable whose value contains a quote character serializes an unescaped value into `.universal\variables.ps1`, making the file syntactically invalid. PowerShell Universal keeps serving variables from the database, so nothing visibly breaks — until the next configuration reload or service restart, when the file fails to parse ("Invalid configuration: ...variables.ps1") and variables fail to load. **Steps to reproduce** 1. Create a variable via the Admin UI or REST API: - Name: `QuoteTest` - Value: `conn"str'test;pwd=fake"x` (any value containing a single quote reproduces it) 2. Open `.universal\variables.ps1`. **Actual result** The serialized line is written with the embedded quote unescaped: New-PSUVariable -Name "QuoteTest" -Value 'conn"str'test;pwd=fake"x' The embedded `'` is not doubled, so the string terminates early and the file no longer parses (`TerminatorExpectedAtEndOfString`). Verify with: $errs = $null [System.Management.Automation.Language.Parser]::ParseInput( (Get-Content -Raw .\.universal\variables.ps1), [ref]$null, [ref]$errs) | Out-Null $errs **Expected result** Values are escaped for single-quoted PowerShell literals (`'` doubled to `''`), keeping `variables.ps1` valid for any value. **Impact / why this is nasty** - The corruption is **silent** : runtime serves variables from the DB, so the broken file sits armed until a restart or config sync, then every variable in the file is at risk of failing to load at once. - One bad value poisons quote-pairing for **every subsequent line** , so the parse errors point at unrelated variables many lines below the actual culprit, which makes diagnosis genuinely difficult. - Realistic trigger: pasting a SQL connection string whose password contains a quote — which is exactly how we hit it in production. **Workaround** Store quote-bearing values as vault-backed secrets (no value is serialized into variables.ps1), or hand-repair the file line with proper `''` escaping.

I've currently tested terminals on multiple versions of PSU on Windows Server 2022 and 2026 as well as Ubuntu 24.04.4. I start a fresh install, and without fail so far, every version beyond 2026.1.3 will fail to launch any terminal other than one tied to the Integrated environment. This includes the current latest, 2026.2.1 with the built-in PS7 environment as well as the Windows PowerShell environment on Windows. [image] The logs seem to show that it is launching successfully but it does not show this in the GUI: [11:47:56 INF] PowerShellUniversal.Automation.JobProcessManager Starting job using Process as interactive. [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: Received: ParentProcessId: 18064 UniversalPort: 62209 InstanceId: 9 [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: Connecting to universal. [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: D0629 11:47:56.370232 Grpc.Core.Internal.UnmanagedLibrary Attempting to load native library "D:\psu\versions\Universal.win-x64.2026.2.1\Hosts\7.5\grpc_csharp_ext.x64.dll" [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: D0629 11:47:56.429861 Grpc.Core.Internal.NativeExtension gRPC native library loaded successfully. [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: Server port:61507 I've not been able to find anyone else reporting this happening, but it's been pretty consistent for me across multiple servers and OSes. Anyone else see this or know of a solution?

V2026.2.2 IIS Hosting w/ MS SQL Persistence Two rather large issues I've been seeing, the first one more recent, far more pressing. I updated our beta environment to 2026.2.2 in hopes this would be resolved, but still seeing this error whenever trying to create new endpoints, anybody else seeing this? I've noticed it in the last few versions, and hoped it would have cleared itself up by now. After this error, the page usually temporarily returns a 503 error from IIS, as the app pool tends to recycle itself after this error presents, so thinking something's crashing. [image] Another I've noticed is when it comes to variables, we've been seeing this for a while, just never really gotten around to bringing it up, since we have found a workaround... When we create a variable of type "secret" and store it in the Database vault, the resulting entries in the Database show a duplicated, blank entry in "Variable" table for the new variable that was just created. This results in the variables page just spinning, never loading. The only fix has been to manually remove the "blank" row in the DB, and then it starts working again, and the secret works. [image] [image]

Hello, After upgrading from 2026.1.6 to 2026.2.0, a domain user can no longer start a script manually from the admin console. The job fails immediately with Failed to start script. Unknown identity: DOMAIN\Account I did some troubleshooting before posting here and I found out that the console identifies me as DOMAIN\Account (with domain name in uppercase), and automatically creates an identity for me that I can find under Security > Identities. This automatically generated identity is stored as domain\account (With domain in lowercase). I manually created a second identity for my account with domain name in uppercase, and I was able to start a job successfully. Here are some details about my environment : Version: 2026.2.0 Auth: Windows Authentication, AD domain account Database: PostgreSQL Licensed: Yes Install: As a Windows Service with SYSTEM account Thank you in advance for your help.

PSU 2026.1.6 [image] The UI says seconds, but based on the documentation and real world testing, this is actually minutes https://docs.devolutions.net/powershell-universal/powershell-commands/new-psuscript#timeout

[image] at System.Collections.Generic.Dictionary2.Add(TKey key, TValue value) at AntDesign.Select2.SetInitialValuesAsync(SelectOptionItem2 selectOptionItem) at AntDesign.Select2.AddOptionItem(SelectOptionItem2 optionItem) at AntDesign.SelectOption2.OnInitializedAsync() at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync() An error occured. An item with the same key has already been added. Key: Triggered This is while hosting with sql as the backend. I dont see this issue when useing a local sqllite Since this was my prod environment i had to revert back to 1.7 for now :(