Bug Report

@adam, /ponytail found an issue in your mermaid bundle, looks like a map is not needed: 4. Generated source maps add about 10 MB (Modules/UniversalDashboard.Mermaid/0.0.1/*.bundle.map, UniversalDashboard.Mermaid.psm1:2-7) - What this is: The module ships four JavaScript bundles plus four large source maps. - Problem: The module registers only .js files at runtime. The source maps are useful for browser debugging but are not needed to render the production diagram. - Fix: Omit the .map files from the production module, or keep them only in a separate debug package. - If we skip it: Clone, sync, and deployment size increase without changing application behavior.

------------------------------------------------------------ Product: PowerShell Universal Version: 2026.3.3 Hosting: IIS OS: Windows Server 2025 Database: SQL Server ------------------------------------------------------------ CONTEXT The script is not run directly by the user. The user calls an authenticated API endpoint, and it is the endpoint code that runs the script with Invoke-PSUScript: User (AD group member, role DLG-PSU_2424) -> calls API endpoint (Authentication enabled, restricted to DLG-PSU_2424) -> endpoint code runs Invoke-PSUScript -> script Add-UserToADGroup.ps1 Endpoint code (simplified): param($Param1) Invoke-PSUScript -Name '<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1' -Parameters $Param -Wait The endpoint itself is reachable and executes correctly: the access denied error is raised by the Invoke-PSUScript call inside the endpoint. Replacing the Invoke-PSUScript line with $ClaimsPrincipal returns the expected identity, role and permissions (see EVIDENCE below), and replacing it with Get-PSUScript on the same script succeeds. ------------------------------------------------------------ SUMMARY When a custom role is granted scoped permissions on a single script (or even the global automation.scripts/execute permission), calling Invoke-PSUScript from an API endpoint fails with: "Permission denied. The role specified does not have access to this resource" Get-PSUScript on the same script, from the same endpoint, succeeds with the same role, which shows that the scoped permission is matched correctly for read access. The call only succeeds when a parent-scope permission is added to the role: either automation/read or automation/execute. Both grant access to all automation resources, which defeats folder/script-level delegation. EXPECTED BEHAVIOR A role with automation.scripts/view + read + execute permissions scoped to a single script should be able to run that script through Invoke-PSUScript from an API endpoint, without needing access to the whole automation scope. ACTUAL BEHAVIOR Invoke-PSUScript, called from the API endpoint, is denied unless the role has automation/read or automation/execute. ------------------------------------------------------------ CONFIGURATION Role: DLG-PSU_2424 - Claim type: http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid - Claim value: AD group SID - Role permissions: automation.scripts/view Scoped permissions (created from the script's Permissions dialog, assigned to the role): - automation.scripts.<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1/read - automation.scripts.<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1/execute API endpoint: - Authentication: enabled - Roles: DLG-PSU_2424, DLG-PSU_Administrator - Execution roles: DLG-PSU_2424, DLG-PSU_Administrator ------------------------------------------------------------ EVIDENCE: CLAIMS ARE CORRECTLY RESOLVED Returning $ClaimsPrincipal from the endpoint (called by a member of the AD group) shows: Type : http://schemas.microsoft.com/ws/2008/06/identity/claims/role Value : DLG-PSU_2424 Type : PSUPermission Value : automation.scripts/view Type : PSUPermission Value : automation.scripts.<Folder>\\Add-UserToADGroup\\Add-UserToADGroup.ps1(.*)/read Type : PSUPermission Value : automation.scripts.<Folder>\\Add-UserToADGroup\\Add-UserToADGroup.ps1(.*)/execute The role and permissions are correctly present in the identity. Cached claims were ruled out (new sign-in after every change). ------------------------------------------------------------ STEPS TO REPRODUCE 1. Create a custom role with only automation.scripts/view. 2. Create a script in a subfolder, open its Permissions dialog and grant read and execute to the role. 3. Create an authenticated API endpoint restricted to that role, containing: Get-PSUScript -Name '<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1' # Test A Invoke-PSUScript -Name '<Folder>\Add-UserToADGroup\Add-UserToADGroup.ps1' # Test B 4. Call the endpoint as a user holding only that role. ------------------------------------------------------------ TEST MATRIX (all tests run from inside the API endpoint) Additional permissions on the role Get-PSUScript Invoke-PSUScript ------------------------------------------------------------------------------------------- 1. none OK DENIED 2. none, with -Wait OK DENIED 3. none, with -Integrated OK DENIED 4. automation.jobs/read OK DENIED 5. automation.scripts/execute + automation.jobs/create OK DENIED 6. automation.environments/read OK DENIED 7. automation.jobs/* OK DENIED 8. automation.computers/read OK DENIED 9. automation/read OK OK 10. automation/execute OK OK 11. automation/* OK OK ------------------------------------------------------------ ANALYSIS - The scoped permission pattern is matched correctly for read (test A succeeds from the endpoint). - The failure is not related to jobs, environments or computers (tests 4, 6 to 8). - Even the global automation.scripts/execute is not sufficient (test 5). - Any permission at the parent automation level, regardless of access type (read or execute), unlocks the call (tests 9 and 10). This suggests that the authorization check performed by Invoke-PSUScript, when called from an API endpoint, evaluates a resource at the automation scope level instead of automation.scripts.<path>, so scoped permissions are never considered. ------------------------------------------------------------ IMPACT Folder- and script-scoped delegation (as described in the Permissions documentation) cannot be used for scripts invoked from API endpoints. The only working workaround is granting automation/read or automation/execute, which exposes or allows execution of every script on the instance, including scripts running under privileged credentials.

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

Reproduce Bug: Run > Terminals Create new terminal (environments test: Integrated, PS7, PS5.1) Connect to Terminal Error Text: XtermBlazor fit addon assets failed to initialize. Error: XtermBlazor fit addon assets failed to initialize. at registerXtermFitAddon (https://<HOSTNAME>/assets/js/site.js?v=2026.3.3-37052641275:415:11) at async w.beginInvokeJSFromDotNet (https://<HOSTNAME>/_framework/blazor.server.js?v=2026.3.3-37052641275:1:4167) at async Xt._invokeClientMethod (https://<HOSTNAME>/_framework/blazor.server.js?v=2026.3.3-37052641275:1:67161) at Microsoft.JSInterop.JSRuntime.InvokeAsync[TValue](Int64 targetInstanceId, String identifier, JSCallType callType, Object[] args) at Microsoft.JSInterop.JSRuntimeExtensions.InvokeVoidAsync(IJSRuntime jsRuntime, String identifier, Object[] args) at PowerShellUniversal.PsuTerminal.OnAfterRenderAsync(Boolean firstRender) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Shared\Components\PsuTerminal.razor:line 144 at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

It looks like there's a problem with the 2026.3.X images for Windows Server 2022. I'm getting this message when running docker pull: a Windows version 10.0.26100-based image is incompatible with a 10.0.20348 host The first layer for the 2026.3.0 and 2026.3.1 images for ltsc2022 is this: Apply image 10.0.26100.32230 However, on 2026.2.5, it's this: Apply image 10.0.20348.2700 Since my docker host is running Windows Server 2022, I can't check the new version of PowerShell Universal. Should I make a separate forum post for this issue, or is this something you can look into?

Example Script: param( [string[]] $MultiStringInput ) Reproduce Bug: Run script Enter value in "Parameters" section Switch to "Action Preferences" Switch back to "Parameters" Error Message: An item with the same key has already been added. Key: examplevalue at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value) at AntDesign.Select`2.CreateDeleteSelectOptions() at AntDesign.Select`2.OnParametersSetAsync() at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)

add 3 variables put values in all 3 try to edit another one, it will not pull the value that is in the database/variables.ps1 it pulls the value from the last edit of a different variable

I set up a new API Rate Limit like allways but the saving took for ever [image] After Reloading the page all rate limit entries are gone / not loading anymore. The page is still responsive. [image] I can see the newly created rate limit in the ratelimits.ps1 file.

Version: 2026.3.3.0. Hosting: Windows, self-hosted Kestrel (not IIS). Error: Request body too large. The max request body size is 30000000 bytes from Set-PSUCache -Integrated. What I tried: Kestrel:Limits:MaxRequestBodySize in appsettings.json, then a service restart. It made no difference. Question: is there a supported way to raise the limit, or a recommended pattern for large cache items? Cheers,

I have found if a data grid column is set to type 'date' or 'dateTime', an error appears when rendering the app. I do not see any additional logs throwing in the app's logging page or PSU's logging page. 2026.1.5: [image] 2026.3.3: [image] Code: New-UDPage -Url "/report-testreport" -Name "report-testreport" -Content { New-UDDataGrid -LoadRows { $Data = @( @{ Name = 'Adam' Number = Get-Random -Minimum 1 -Maximum 10 Boolean = if ((Get-Random -Minimum 1 -Maximum 10) -ge 6) { $true } else { $false } DateTime = Get-Date } @{ Name = 'Tom' Number = Get-Random -Minimum 1 -Maximum 10 Boolean = if ((Get-Random -Minimum 1 -Maximum 10) -ge 6) { $true } else { $false } DateTime = Get-Date } @{ Name = 'Sarah' Number = Get-Random -Minimum 1 -Maximum 10 Boolean = if ((Get-Random -Minimum 1 -Maximum 10) -ge 6) { $true } else { $false } DateTime = Get-Date } ) $Data | Out-UDDataGridData -Context $EventData -TotalRows $Data.Count } -Columns @( New-UDDataGridColumn -Field 'Name' New-UDDataGridColumn -Field 'Number' New-UDDataGridColumn -Field 'Boolean' New-UDDataGridColumn -Field 'DateTime' -Type 'dateTime' # Both 'date' and 'dateTime' cause the errors. Commenting out the type parameter prevents the error. ) } -AutoInclude

Since Agent 2026.3.3 importing the Universal Module fails with Method 'ClearTimedOutSessionsAsync' in type 'UniversalDashboard.Services.SessionManager' from assembly 'UniversalDashboard, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation. Importing the module in a "normal" PowerShell session works fine as well as I don't see issues in the Server, only the agent seems to break upon importing.

PSU 2026.3.3 IIS Hosted Endpoint/API $ClaimsPrincipal looks to be a json string instead of the [ClaimPrincipal] class as indicated in the documentation here: Variables | Devolutions PowerShell Universal | Product guides & reference . Attempting to filter under the assumption that it's the .Net class fails: $ClaimsPrincipal.Claims | ?{ $_.Issuer -eq 'https://www.poshtools.com' } | ?{ @('MyApproved','GroupsHere') -contains $_.Value }) Instead, I have to convert it from JSON to then be able to filter: ($ClaimsPrincipal | ConvertFrom-Json).Claims | ?{ $_.Issuer -eq 'https://www.poshtools.com' } | ?{ @('MyApproved','GroupsHere') -contains $_.Value } Is this intentional or a bug? If it's intentional, the documentation should probably be updated.

This goes back many versions, and I may have created a GitHub issue for it. I'm raising it now that I am using Out-UDDataGridData correctly and are still observing the auto-sizing bug. In our data grid, we have some columns rendered with UDChips inside. It appears the columns will only auto-size to the largest first chip in the column. Subsequent chips are cut off if they don't fit, displaying three dots that can easily be missed. Double-clicking the column resize handle changes the column width back to the width of the largest first chip. If you make the column smaller than the first chip, the chip is still visible, but the text inside gets cut off. Here are some screenshots that hopefully clarify what we observe, as well as the data grid code we are using. [image] [image] [image] [image] [image] Data grid code: New-UDDataGrid -AutoSizeColumns -ShowPagination -PageSize 25 -RowsPerPageOptions @(10, 25, 50, 100) ` -LoadRows { # Map "does not contain" / "does not equal" to "not contains" / "not equals" foreach ($item in $EventData.Filter.Items) { switch ($item.operator) { 'doesNotContain' { $item.operator = 'notContains' } 'doesNotEqual' { $item.operator = 'notEquals' } } } $Data | Out-UDDataGridData -Context $EventData -TotalRows $Data.Count } ` -Columns @( New-UDDataGridColumn -Field Id New-UDDataGridColumn -Field DisplayName New-UDDataGridColumn -Field UserPrincipalName New-UDDataGridColumn -Field Licenses -Render { $EventData.Licenses -split ';' | ForEach-Object { New-UDChip -Label $_ } } New-UDDataGridColumn -Field Skus -Render { $EventData.Skus -split ';' | ForEach-Object { New-UDChip -Label $_ } } )

I can confirm that I do not get the multi-pwsh error on the environments page anymore. I'm not sure if I mentioned it in this post or another, but PowerShell 7.5 still doesn't ship with the execute flag set. I can create a separate thread for that.

When moving a script into a folder the schedule is not updated with the new path and then the schedule disappears from the UI. I have been resorting to editing the schedules.ps1 and updating the path manually, but it would be nice to have this handled automatically. I am seeing this on all versions of PSU and most recently on 2026.3.1.

[Reposting with fully sanitized screenshot because there's apparently no way to modify a screenshot or edit a post after making it] Hi there, New PSU user here. I am working through configuring our server, running PSU as a service on Windows Server, no IIS. While running the PSU service as local system, I created a web app and configured Run-As credentials to use a domain account and had no issue. When I moved converted PSU service to run as a service account, as it's documented that this is best practice, my web apps will no longer start. I already tried re-creating the run as account credential secrets while running PSU service as the service account; this is not the issue. The credentials validate successfully. The PSU Service account is a local admin on the server. When I look in event viewer, I see that the Run As account is attempting to log into the server interactively (logon type 2), which is something we explicitly block for service account in our environment. Can someone explain to me if this is a bug or by design for some reason? I don't understand why the Run As account is attempting to log in interactively. See attached screenshot for details. I had this issue in 2026.2.4 and attempted an upgrade to 2026.3.1 but that did not fix the issue. [image]

Clicking the button throws the following in the console: [image]

Not sure if anyone else has experienced this or not, but it seems the updater doesn't set the correct permissions multi-pwsh to access the repo: An error occurred trying to start process '/opt/psuniversal/multi-pwsh' with working directory '/home/psuniversal/.PowerShellUniversal/Repository'. Permission denied at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec) at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start(ProcessStartInfo startInfo) at PowerShellUniversal.Automation.MultiPwshService.RunAsync(String[] arguments, CancellationToken cancellationToken) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\MultiPwshService.cs:line 674 at PowerShellUniversal.Automation.MultiPwshService.DiscoverPowerShellVersionsAsync(CancellationToken cancellationToken) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\MultiPwshService.cs:line 128 at PowerShellUniversal.Automation.MultiPwshService.GetPowerShellVersionsAsync(Boolean refresh, CancellationToken cancellationToken) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\MultiPwshService.cs:line 93 at PowerShellUniversal.EnvironmentsForm.OnInitializedAsync() in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Pages\Settings\EnvironmentsForm.razor:line 175 at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync()

Nothing happens when we try to filter or sort columns: [image]

We got this error on 2026.1.5 hoping that 2026.3.0 would fix it, but it appears the issue persists. We have the ExchangeOnlineManagement module installed, version 3.10.1, and it is failing to load a .NET core DLL: Microsoft.Identity.Client.dll. We have reinstalled the module to no avail. This is using the integrated environment until the other environments get fixed. Here is the exact error message: Could not load file or assembly '/home/psuniversal/.PowerShellUniversal/Repository/Modules/ExchangeOnlineManagement/3.10.1/netCore/Microsoft.Identity.Client.dll'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)

https://docs.devolutions.net/powershell-universal/api/endpoints The log is not live and is lacking a refresh button. Currently only refreshing the page shows new logs. The documentation states: "You can write to the live log from within your endpoints with cmdlets like Write-Host." However, that does not work. Only Write-PSUError seems to write anything. I would appreciate it if the documentation contained more examples on how to use the Test tab correctly. Looking into the dev tools shows requests to /assets 404 Not Found. This is for all admin UI pages as far as i can tell Please refer to my other issues for questions about my setup.

OS: Linux Docker Image: devolutions/powershell-universal:2026.3.0-ubuntu-24.04 Note: This container has updated through almost every 2026.* release without any problems causing failed starting OBS: Image is baked into another image but other versions haven't been a problem PowerShell Universal fails to start because the security proxy does not become available within the configured startup timeout. After starting with new imagine Startup sequence: - PowerShell Universal begins starting. - Startup reaches "Starting security service..." - The security service does not successfully start within 30 seconds. - PowerShell Universal then aborts startup. - Reverting to 2026.2.5 successfully starts it again Displayed error: PowerShell Universal failed to start. Check the logs for more information. Failed to load PowerShell Universal. Timed out waiting for security proxy to start. Waited 30 seconds. Consider increasing the SecurityProxyTimeout setting in appsettings. Expected behavior: PowerShell Universal should successfully start the security service and complete application startup.

[image] Tested with a .jpg

Had about 44 changed files pending in my dev instance. Clicked "Commit Changes" at the top (to get to the Git tab), and the page froze for about a minute. Did not have this issue on previous versions. [image] [image] (browser task manager, it got even higher then in the screenshot for both size and CPU) I think this is due to all checked files being loaded at once when the page opens. I suggest the content of the changed files to be loaded upon expanding the change editor and having all changes closed by default.

Hi, I'm experiencing an authorization issue in PowerShell Universal in version 2026.3.2 that only occurs when using the built-in Test tool. I have an API endpoint that starts an automation script using: Invoke-PSUScript -Name "script.ps1" -Parameters @{Variable = $Variable} -Wait The script is configured to run with the Administrator role. When the endpoint is called externally using Invoke-RestMethod , everything works correctly and the script executes as expected. However, when I use the Test feature from the PSU web interface, I receive the following error: Permission denied. The role specified does not have access to this resource. Has anyone encountered this behavior before? Thanks!