Bug Report

[image]

I just updated my PSU server to the latest version. Now when I edit a script the code window contains this white text box. It is messing with the line numbers and super annoying as nothing lines up. Any idea on how to get rid of it? [image]

https://github.com/ironmansoftware/powershell-universal/issues/4914 I still need a way to set -OnLoadOptions and -Value at the same time

This may be another one of those instances where it's just unsupported when running gMSA's but I'll note it here just in case it is a bug :) My running environment is: OS: Windows Server 2022 PowerShell Universal: Version 2026.2.5 PSU runs as a Windows Service as LocalSystem Repro script: #.universal\scripts.ps1 (Sanitized): New-PSUScript -Name 'Test.ps1' -Description 'Test' -Path 'Test.ps1' -Environment 'PowerShell 7' -Credential 'MyGmsaAccount' -Role @('MyRole') -PortalOutputType 'Text' -Icon 'alert' -DisplayOutputOnExecute -ExecutionRole @('MyRole') # Script contents Param( [ComponentModel.DisplayName("Upload File")] [File]$File ) 'Filename is {0}' -f $File.FileName Set-Content -Path 'C:\test.xlsx' -AsByteStream -Value $File.Content When choosing to run the script by uploading a file, the following error is logged in the console (before any of my script logic is executed): Could not find file 'C:\Windows\TEMP\psufile.128.bin'. (Number is variable through executions)

Related to the issue in Issues with scripts that take files as input and run as gMSA - Devolutions Forum I have a role required to run the script, if my coworker who only has "MyRole", they can start the script and upload it, but in the admin console the job sits at "Awaiting user feedback". Opening the job reveals that it is expecting File (as a string). Considering it works for me as an Administrator, but not for the user who only has MyRole, I assume it's some kind of permissions related issue, but I don't think it should be? Correct me if I'm wrong. Details are the same as before, my running environment is: OS: Windows Server 2022 PowerShell Universal: Version 2026.2.5 PSU runs as a Windows Service as LocalSystem Script is: #.universal\scripts.ps1 (Sanitized): New-PSUScript -Name 'Test.ps1' -Description 'Test' -Path 'Test.ps1' -Environment 'PowerShell 7' -Credential 'MyGmsaAccount' -Role @('MyRole') -PortalOutputType 'Text' -Icon 'alert' -DisplayOutputOnExecute -ExecutionRole @('MyRole') # Script contents Param( [ComponentModel.DisplayName("Upload File")] [File]$File ) 'Filename is {0}' -f $File.FileName Set-Content -Path 'C:\test.xlsx' -AsByteStream -Value $File.Content The role they're using is this specific one: New-PSURole -Name "MyRole" -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups" -ClaimValue "MyRole"

PSU: 2026.2.5 If you have AiTools in a module and then you add a new tool via the GUI, PSU adds ALL the tools into the new, local AiTools.ps1. So the new file has all the tools from the module AiTools.ps1 + the just generated tool. This reminds a bit of the buggy behaviour from read-only sections in earlier versions (4.x/5.x).

PSU 2026.1.6 Priority: High When using multiple MCP tools in parallel (e.g. >10) the server CPU load caps at 100% for several seconds and PSU gets unresponsive. Each MCP job spawns a Universal.Host process that consumes approximately 7~10% CPU. These jobs do very light work, most just start an asynchronous REST API call and check for completion with most calls completing in seconds. I'd wager the time it takes for PSU to prepare these jobs is greater than the time it takes for the content of the jobs to finish. Our AV and EDR tools are surely involved in creating this load and we are testing what happens if they are off or the PSU processes are excluded. But I don't think this will fully fix the problem. I would like to have the load problem permanently fixed, but for a workaround i would be satisified with a rate limiting for MCP tools. Can you please - either fix the problem or create a workaround - in the 2026.1.x version family? This happens on both of these types of machines: RDP -> VM (dev machine) Windows Server 2019 local access HTTP Portable zip 6 cores @ 2.80GHz 24GB RAM LB -> VM (test machine) Windows Server 2022 remote access HTTPS with official cert MSI install 4 cores @ 2Ghz (restricted by hypervisor policy) 8GB RAM I haven't tested it yet on our prod cluster, but i would expect the same: LB -> 2 VMs Windows Server 2022 remote access HTTPS with official cert MSI install 4 cores @ 2Ghz (restricted by hypervisor policy) 8GB RAM

make a change in dev let psu git pull go to files reload endpoints changes still not being applied go to /endpoints and click the restart endpoints button now the new line is working

Hi Folks, I was running 2026.2.0 and suddenly after a server restart some of my portal apps wouldn't start up, I traced this down to my run as account in the environment. when I tried to re-enter the username and password, it failed to validate. I have tried to recreate them, and even different accounts, yet it continues to fail to validate. I have updated now to version 2026.2.6 same issue persists. I have tried domain\username username username@domain neither work. process is: I go to platform > variables > create secret > select PSCredential > enter username and password and hit validate. failed toast message appears. Server is a member of the domain, and account is a member of the same domain. is there anything that can be done?

FYI, the last few releases are not listed in the Releases view. Version 2026.2.5 [image]

This is from a Blank PSU app that I had open while shutting down my PC for the day. After coming back this morning, my browser automatically opens my last pages, and all PSU apps recently have returned completely blank. The setup includes 2 PSU servers with a Postgres database on version 2026.2.3. A load balancer/reverse proxy is in place with sticky sessions enabled. (ip hashing) There seems to be an error indicating that sticky sessions are not enabled. I request this scenario to be handled properly or that the page would auto-reload when an old WebSocket connection can't be established. [2026-08-22T09:15:04.232Z] Information: Normalizing '/dashboardhub?dashboardid=6&pageid=1...' to 'https://domain.com/dashboardhub?dashboardid=... 3f0d01ed210f9fa93137.bundle.js:60 WebSocket connection to 'wss://domain.com/dashboardhub?dashboardid=...' failed: (anonymous) @ 3f0d01ed210f9fa93137.bundle.js:60 3f0d01ed210f9fa93137.bundle.js:60 [2026-08-22T09:15:04.355Z] Information: (WebSockets transport) There was an error with the transport. 3f0d01ed210f9fa93137.bundle.js:60 [2026-08-22T09:15:04.355Z] Error: Failed to start the transport 'WebSockets': Error: WebSocket failed to connect. The connection could not be found on the server, either the endpoint may not be a SignalR endpoint, the connection ID is not present on the server, or there is a proxy blocking WebSockets. If you have multiple servers check that sticky sessions are enabled. log @ 3f0d01ed210f9fa93137.bundle.js:60 APPNAME:1 EventSource's response has a MIME type ("text/html") that is not "text/event-stream". Aborting the connection. 3f0d01ed210f9fa93137.bundle.js:60 [2026-08-22T09:15:04.450Z] Error: Failed to start the transport 'ServerSentEvents': Error: EventSource failed to connect. The connection could not be found on the server, either the connection ID is not present on the server, or a proxy is refusing/buffering the connection. If you have multiple servers check that sticky sessions are enabled. log @ 3f0d01ed210f9fa93137.bundle.js:60 3f0d01ed210f9fa93137.bundle.js:60 [2026-08-22T09:15:04.606Z] Error: Error parsing handshake response: Error: Message is incomplete. log @ 3f0d01ed210f9fa93137.bundle.js:60 3f0d01ed210f9fa93137.bundle.js:60 [2026-08-22T09:15:04.606Z] Error: Connection disconnected with error 'Error: Error parsing handshake response: Error: Message is incomplete.'. log @ 3f0d01ed210f9fa93137.bundle.js:60 3f0d01ed210f9fa93137.bundle.js:60 Uncaught (in promise) Error: Error parsing handshake response: Error: Message is incomplete. at X._processHandshakeResponse (3f0d01ed210f9fa93137.bundle.js:60:97903) at X._processIncomingData (3f0d01ed210f9fa93137.bundle.js:60:96893) at N.onreceive (3f0d01ed210f9fa93137.bundle.js:60:91400) at N._poll (3f0d01ed210f9fa93137.bundle.js:60:70873) 3f0d01ed210f9fa93137.bundle.js:60 [2026-08-22T09:15:04.643Z] Information: Using HubProtocol 'json'. 3f0d01ed210f9fa93137.bundle.js:60 Uncaught (in promise) Error: Error parsing handshake response: Error: Message is incomplete. at X._processHandshakeResponse (3f0d01ed210f9fa93137.bundle.js:60:97903) at X._processIncomingData (3f0d01ed210f9fa93137.bundle.js:60:96893) at N.onreceive (3f0d01ed210f9fa93137.bundle.js:60:91400) at N._poll (3f0d01ed210f9fa93137.bundle.js:60:70873)

Hey! I just upgraded to 2026.2.5, though the component has been broken for quite some time, the 'whats new' section on the admin home, shows old info and doesnt seem to update: [image] I'm not sure if this is because outbound access is restricted on my server, and maybe the location of this has been moved to devolutions which is why it's no longer updating, or if there's another issue? I couldnt find any way to hide/disable the component in settings. Obviously, this is causing no impact at all, but figured I'd get it raised anyway. Thanks, Tom

Added the plugin yesterday and built some generic endpoints, chased down some issues I was having. I don't expect this to impact the plugins functionality, but I'm able to workaround these for the time being. PSU Version: 2026.2.2 (also found in 2026.2.4 DLLs) Host: Windows Server 2025 Web: IIS DB: SQL Component: PowerShellUniversal.Language.CSharp Finding #1 - ApiRequest.Roles is nested under nullable parent SecurityContext and is List<string> not string[] // expected usage, from current documentation var roles = request.Roles ?? Array.Empty<string>(); // corrected, working var roles = request.SecurityContext?.Roles ?? new List<string>(); Finding #2 - ref/using extraction match literal CRLF. LF-only lines never hit. CSharpExecutionService extracts directives with: private readonly Regex _reference = new Regex("#ref (.*)\r\n"); private readonly Regex _using = new Regex("#using (.*)\r\n"); Finding #3 - Directive-extraction is not anchored and will hit on comments and string literals. Reference #2. Finding #4 - Matched `#using` directives are not terminated with `;`. Documentation shows code snippets without trailing `;` // reproduce with #ref System.Collections #using System.Collections.Generic var roles = request.SecurityContext?.Roles ?? new List<string>(); // corrected with trailing ; on using directive

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.