Unable to handle local filesystem via API endpoint on Windows?

PowerShell Universal Universal API
1 
Product: PowerShell Universal
Version: 2.9.3

So I’m having some issues with modifying the local filesystem on Windows via API specifically and I cannot for the life of me figure out why.

All I tried was a simple ‘ls’ and for some reason it won’t work on a Windows host at all.
It works well on Linux via both API endpoint and as an Automation script, but for Windows it only works via Automation script but not API endpoint.

All that happens is that the script/endpoint gets stuck at “Executing…” and runs the CPU to a crawl meaning I have to kill the Universal.Server before the OS freezes. Again, this does not happen at all on Linux and does not happen when running it as an automation script.

Any idea what is causing this odd behaviour?
If it was a permission issue, it doesn’t feel like the automation script should work either.

No logs are showing what’s wrong either from what I can tell, only gives an exception error when I eventually cancel the request.

sheet

[14:25:11 WRN] No exception handler was found, rethrowing original exception.
[14:25:11 ERR] Connection id "0HMGMVAN0GGPG", Request id "0HMGMVAN0GGPG:00000002": An unhandled exception was thrown by the application.
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Cancelled", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1649161511.148000000","description":"Error received from peer ipv6:[::1]:23883","file":"..\..\..\src\core\lib\surface\call.cc","file_line":1067,"grpc_message":"Cancelled","grpc_status":1}")
   at Universal.Server.Services.ApiGrpc.ExecuteAsync(apiRequest request, CancellationToken cancellationToken) in D:\a\universal\universal\src\Universal.Server\Services\API\ApiGrpc.cs:line 149
   at Universal.Server.Services.ApiService.ExecuteAsync(HttpContext httpContext) in D:\a\universal\universal\src\Universal.Server\Services\API\ApiService.cs:line 323
   at Universal.Server.Middleware.RoutingMiddleware.Invoke(HttpContext httpContext, IPolicyEvaluator policyEvaluator) in D:\a\universal\universal\src\Universal.Server\Middleware\RoutingMiddleware.cs:line 94
   at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
   at Universal.Server.Middleware.SwaggerAuthenticationMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\a\universal\universal\src\Universal.Server\Middleware\SwaggerAuthMiddleware.cs:line 42
   at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.<>c__DisplayClass6_1.<<UseMiddlewareInterface>b__1>d.MoveNext()
--- End of stack trace from previous location ---
   at AspNetCoreRateLimit.RateLimitMiddleware`1.Invoke(HttpContext context) in D:\a\universal\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.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.HandleException(HttpContext context, ExceptionDispatchInfo edi)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
   at Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
2

I found a (somewhat) solution, although I am still unsure about why this behaviour is different specifically for Windows.
For some reason it only happens when not specifying the output.

So for example “ls ‘C:’ | Out-String” works, but simply “ls ‘C:’” does not.
Doesn’t have to be a string either, “ls ‘C:’ | Select-Object Name” works as well.