Bug Report

The official docs are incomplete — see below. Working config: environment: Plugins__1: PowerShellUniversal.Plugins.OpenTelemetry OpenTelemetry__Otlp__Endpoint: "http://prometheus:9090/api/v1/otlp/v1/metrics" OTEL_EXPORTER_OTLP_PROTOCOL: "HttpProtobuf" OTEL_EXPORTER_OTLP_ENDPOINT: "http://prometheus:9090/api/v1/otlp/v1/metrics" Gotcha 1 — plugin identifier must be fully qualified ¶ Unlike Plugins__0: PostgreSQL / SQL, the OpenTelemetry plugin's docs page names its Identifier as PowerShellUniversal.Plugins.OpenTelemetry. That full string is what belongs in the Plugins array. Using the short form OpenTelemetry (the natural guess given the other plugins' convention) silently does nothing — no log line, no error, no export attempt. The only way to notice is that Prometheus's own prometheus_http_requests_total{handler="/api/v1/otlp/v1/metrics"} counter never increments. Gotcha 2 — export protocol defaults to gRPC ¶ The plugin uses the standard .NET OtlpExporterOptions, which defaults to gRPC . Prometheus's OTLP receiver speaks HTTP/protobuf , not gRPC, so the mismatch causes the exporter to fail silently — OTel SDK export failures log via its own internal event source, not the application's regular ILogger, so nothing shows up in docker logs. Fix by setting OTEL_EXPORTER_OTLP_PROTOCOL. The plugin reads this flat env var directly and binds it to the C# OtlpExportProtocol enum — so it needs the C# member name , not the OTel-spec string: ✅ HttpProtobuf ❌ http/protobuf — this is the value used in virtually every other OTel doc/example, and it crashes PSU at startup with: System.FormatException: http/protobuf is not a valid value for OtlpExportProtocol. [...] FTL Fatal error starting PowerShell Universal.

There's quite a few minor issues with the docs, probably caused by the migration to the Devolutions side. https://docs.devolutions.net/powershell-universal/powershell-commands/new-udtable#example-7 Has markdown accidentally included at the end of the code block (I've seen a few of these but this one I remember). A lot of links are dead, for example all of https://docs.devolutions.net/powershell-universal#security and https://docs.devolutions.net/powershell-universal#development There's a difference in the list of variables described in the docs and the showcase https://docs.devolutions.net/powershell-universal/platform/variables#built-in-variables https://showcase-psu.devolutions.net/Variables I'd suggest that the parameter info shown in the showcase, vs docs - is reviewed. There is a lot of info on the parameters in the showcase, including what types they accept, which isn't even in the docs. Just the first page for example https://showcase-psu.devolutions.net/Autocomplete vs https://docs.devolutions.net/powershell-universal/powershell-commands/new-udautocomplete Additionally, there's no documentation which describes what a 'site' license is. https://store.devolutions.net/package#psu Is this the same as the 'Enterprise' license before? https://web.archive.org/web/20240910103959/https://ironmansoftware.com/pricing/powershell-universal, which was 'One License for your Entire Organization'. Further described on https://support.ironmansoftware.com/portal/en/kb/articles/kb0014-enterprise-versus-per-server-licensing-faq . I say this because site is a bad name for a license like this IMO, especially if in the Docs the only mention of the word site is in the context of licensing is for IIS Sites https://docs.devolutions.net/powershell-universal/licensing#what-if-i-have-multiple-sites-on-a-single-iis-server

I can't get the vertical divider to show up - it appears to have no styling so is invisible. PowerShell Universal 2026.2.5 (32409143550) It's also not shown in the showcase : [image]

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

PSU version: 2026.2.5 I believe that the Portal search should be case insensitive instead as it can be quite confusing when you don't immediately find results you expect due to casing issues.

When editing a script, under 'Edit Script Properties' the icon field autocomplete doesnt work. If you type in 'user' for example, it shows a blank list: [image] Rather than available options, 'user', 'user-add', 'user-remove' etc

PSU Version: 2026.2.5 If a script has been tagged and is displayed in the portal - but doesnt have permissions for execute and the user tries to run it, you just get a script with a preloader/spinner which sits there indefinitely. I'd suggest maybe a permission check on the resource to grey out the 'submit' button to execute in the first place, or alternatively some sort of error message / feedback when the execution tries but fails.

[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]

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.