Bug Report

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

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.

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`.

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?

Hey, I just tried using Set-PSUCache for the first time. The data im storing could be considered sensitive and I noticed that there's a -Roles param on this cmdlet, and a column in the database for roles (Though the roles dont show in the UI from the cache menu). In my script I have the following command: Set-PSUCache -Key "Keyname" -Value $Data -Persist -Role "RoleName" -Integrated This works the first run, when the cache doesnt exist, but if I rerun my script, it fails with: Status(StatusCode="Unknown", Detail="Exception was thrown by handler.", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1784817449.405000000","description":"Error received from peer ipv6:[::1]:58801","file":"..\..\..\src\core\lib\surface\call.cc","file_line":953,"grpc_message":"Exception was thrown by handler.","grpc_status":2}") I've tried adding the role to the execution roles on the script (I also have the role on my account while running the script). I've tried with and without -Integrated but it's the same issue. Removing the role entirely seems to work fine without issue.

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.

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.

Parameters look normal when editing a script's schedule like below: [image] Re-running a failed job the parameters show up like this: ' [image]

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]

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.

When testing a PowerShell Universal API endpoint using the built-in Test tab, it is not possible to send a request with the Content-Type: application/json header. The Test UI only allows adding a header named ContentType, but this does not result in an actual HTTP Content-Type header being sent. As a result, the request body is not treated as application/json, and parameter binding does not work. Steps to reproduce Create an API endpoint like: param( [string]$Subject, [string]$Description, [string]$Reference ) return New-PSUApiResponse -StatusCode 200 -Body $Subject Open the endpoint's Test tab. Configure: Method: POST Header: ContentType: application/json Body: { "Subject": "PSU Test", "Description": "Description Stuff", "Reference": "PSUTEST-2", } Click Invoke . Expected behavior The request should be sent with: Content-Type: application/json and the JSON body should be bound to the parameters: $Subject = "PSU Test" Actual behavior Parameter binding fails with an error similar to: A parameter cannot be found that matches parameter name '{ "Subject":"PSU Test", ... }' The same request works correctly when sent externally (e.g. via Invoke-RestMethod, Postman, or curl) with a proper Content-Type: application/json header.

Version: 2026.2.1 I went to rerun a job and the popup doesnt show any labels on my params, or any values as seen here: [image] Notice the 3 params in the background, all are switches. (There's an additional parameter defined in the script - a string, but it was not supplied in the schedule that ran this.)

I use Invoke-PSUScript to start jobs from endpoint calls, and frequently use the Log tab in the endpoint code editor for debugging or traceback etc. Sadly this log is hard to read for 2 reasons: 1) it does not support ANSI sequences, but still displays them as text. 2) return values from Invoke-PSUScript do get written in the log, even if they are captured. So a simple $DisplayName = Invoke-PSUScript -Script 'getUser.ps1' -Wait sould not write the return value itself to the log, since it is captured in a variable, but it still does and on top all outputs (return / write-Information, etc) of that script contain ANSI sequences: [Information] [Api-/data/getUser:GET] DisplayString : John Doe So I would love to either have the log support those ANSI sequences or have it stripe them off. Also, captured return values from scrips should not appear in the log, which would be consistend to the powershell behavior in general.

fyi :) [image]

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)

Product: PowerShell Universal 2026.2.1 (upgraded from 2026.1.1 — issue does not exist on 2026.1.1) Environment: Linux (Docker), multi-node, PostgreSQL, configuration as code (git-synced .universal repository) Summary Since upgrading to 2026.2.1, endpoint URL validation rejects a static endpoint URL whenever a parameterized endpoint exists whose path starts with the same segments. The two routes are distinct (different segment counts) and represent the standard REST collection/item pattern ( GET /resource + GET /resource/:id ). This configuration has been working unchanged since v4 and loads fine on 2026.1.1. Minimal reproduction endpoints.ps1: New-PSUEndpoint -Url "/test" -Method GET -Endpoint { "static" } New-PSUEndpoint -Url "/test/:param" -Method GET -Endpoint { $Param } On configuration sync, validation of the static URL fails with: Endpoint URL /test is not valid. It matches an existing internal URL: GET:/test/:param Important detail for reproducing this: the error does not necessarily appear on the very first registration into an empty database. It appears once the parameterized route is already registered — i.e. on the next configuration sync, after a restart, or when a second node in a multi-node setup loads the same repository. This may be why issue #5627 (same error class, App URLs) could never be reproduced in-house. Real-world error (verbatim) Invalid configuration: endpoints.ps1 (Endpoint URL /v1/runner/jobs is not valid. It matches an existing internal URL: POST:/v1/runner/jobs/:jobId/status at PowerShellUniversal.Configuration.UrlValidator.ValidateStaticUrls[T](T item, String url, String[] methods) in src\PowerShellUniversal.Configuration\UrlValidator.cs:line 185 at PowerShellUniversal.Configuration.UrlValidator.Validate(Endpoint endpoint) in src\PowerShellUniversal.Configuration\UrlValidator.cs:line 47 at PowerShellUniversal.Configuration.EndpointService.UpdateAsync(ModelOperationContext`1 context) in src\PowerShellUniversal.Configuration\Endpoints.cs:line 213 at UniversalAutomation.Services.ConfigurationScript`1.ReadAsync(...) in src\PowerShellUniversal\ConfigurationScript.cs:line 461 Our production configuration (unchanged for years): POST /v1/runner/jobs GET /v1/runner/jobs GET /v1/runner/jobs/:jobId POST /v1/runner/jobs/:jobId/status GET /v1/runner/jobs/:jobId/status ... Note that /v1/runner/jobs (3 segments) is reported as "matching" POST:/v1/runner/jobs/:jobId/status (5 segments). A correct route matcher can never match these two — it looks like `ValidateStaticUrls` truncates parameterized route templates at the first route parameter and then compares the remaining prefix against static URLs. Knock-on effects environments.ps1 is marked invalid with the same error, because the environments sync re-triggers endpoint validation: at PowerShellUniversal.Configuration.EnvironmentsConfigurationScript.OnReadAfterAllAsync(SyncContext syncContext) in src\PowerShellUniversal.Configuration\Environments.cs:line 43 So a single validation false positive invalidates both the endpoints and the environments configuration — the entire custom REST API is down. In our case several hundred deployed agents lost connectivity after the upgrade; this is a hard outage for us. What we tried Curly-brace syntax ( /test/{param} ) instead of :param — not supported, does not work. Reordering the endpoint definitions — no effect (validation compares against routes already registered from the previous sync / the other node). Looked for a setting to disable or relax endpoint URL validation — none exists as far as we can tell (neither in appsettings.json nor in the feature flags). Merging the two routes into a single endpoint is not possible: an endpoint has exactly one URL, and /test must remain directly callable. Renaming routes so that no static URL is a prefix of a parameterized one would break all deployed API clients — not feasible. Expected behavior A static URL should only be rejected when it actually conflicts with an existing route (same method and same path shape/segment count) — as was the case up to and including 2026.1.1. Related https://github.com/ironmansoftware/powershell-universal/issues/5627 — same error class for App URLs ("was working for years"), closed unresolved when the repo was archived. The reproduction above is deterministic and should finally make this debuggable. The validator appears to have been introduced with the CVE-2026-3563 fix (advisory DEVO-2026-0008) in 2026.1.4. We jumped from 2026.1.1 directly to 2026.2.1, so this validation ran against our repository for the first time. Questions Can the false positive in UrlValidator.ValidateStaticUrls be fixed so that the standard REST pattern ( GET /resource + GET /resource/:id ) validates correctly again? Until a fix ships: is there any supported way to bypass or relax endpoint URL validation? We are currently blocked from running 2026.2.x at all.

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

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.

PSU Version: 2026.2.1 Custom script base path configured in settings I'm trying to move this: SubFolder1\ScriptName.ps1 into SubFolder1\SubFolder2\ScriptName.ps1 I click edit properties on my existing script, choose the new folder from the drop down, then hit OK. No errors, and I get a toast saying "Script Saved", but the script stays in the same location.

I m running into issues while accessing variables for a while now and I could finally pin down two reproducable issues. I created 3 Secret variables: SecTest = Secret without any role SecTestRole = Secret with added role after creation SecTestRoleRem = Secret with added role after creation, then removed the role again SecTest should now be equivalent to SecTestRoleRem, but turns out, they are not. Small script to inspect variables: $names = @("SecTest","SecTestRole","SecTestRoleRem") $names | ForEach-Object { Write-Information "Access via Secret:name Secret:$_ :" Write-Information (Get-ChildItem "Secret:$_") $PSUVariable = Get-PSUVariable -Name $_ Write-Information ($PSUVariable | ConvertTo-Json) } Result of the Script: Access via Secret:name Secret:SecTest : S123456 { "Id": 23, "Name": "SecTest", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": null, "Scope": 0, "Tags": [], "Tag": [], "Roles": null, "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } Access via Secret:name Secret:SecTestRole : 78293479 { "Id": 26, "Name": "SecTestRole", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": [ "Execute" ], "Scope": 0, "Tags": [], "Tag": [], "Roles": [ "Execute" ], "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } Access via Secret:name Secret:SecTestRoleRem : The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Cannot find path 'SecTestRoleRem' because it does not exist. 2 Issues: None of the secret variables contain a "Value" or "DisplayValue", which I would expect them to. SecTestRoleRem is no longer accessable via (Get-ChildItem "Secret:SecTestRoleRem") after the role removal. To add further details, this script: Write-Information "SecTest" Write-Information ($Secret:SecTest) $PSUVariable = Get-PSUVariable -Name "SecTest" Write-Information ($PSUVariable | ConvertTo-Json) Write-Information (Get-ChildItem "Secret:SecTest") Write-Information "SecTestRoleRem" Write-Information ($Secret:SecTestRoleRem) $PSUVariable = Get-PSUVariable -Name "SecTestRoleRem" Write-Information ($PSUVariable | ConvertTo-Json) Write-Information (Get-ChildItem "Secret:SecTestRoleRem") Should basically handle both secret variables the same, since they are configured the same, but will result in: SecTest S123456 { "Id": 23, "Name": "SecTest", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": null, "Scope": 0, "Tags": [], "Tag": [], "Roles": null, "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } S123456 SecTestRoleRem System.Management.Automation.InformationRecord { "Id": 28, "Name": "SecTestRoleRem", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": null, "Scope": 0, "Tags": [], "Tag": [], "Roles": null, "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Cannot find path 'SecTestRoleRem' because it does not exist. So removing roles from secret variables does break them. Adding back a role, makes them usable again, until you remove the role again. And Get-PSUVariable on secrets does not retrieve the value. PSU Version2026.2.0

PSU 2026.1.6 In Automation -> Jobs when selecting columns, if you select 'Origin', the table updates one last time and after that it gets stuck. You can select and deselect what you want, it doesn't update the columns and it doesn't refresh the table anymore. Also after selecting it, Origin appears two times in the list of selectable columns. Right now, as I see it, the only way to reset the view would be to delete the user or execute SQL: UPDATE "main"."Identity" SET "JobColumns" = NULL WHERE "name" = "USERIDENTITY"

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?