API endpoints can't be edited using VS Vode

API endpoints can't be edited using VS Vode

avatar

Editing an API endpoint using VS Code and PSU Extension doesn't work. When creating an API endpoint I tried supplying a Path: testendpoint.ps1. However in vs code the file it seems to be editing is not the file live on powershell universal. How is this supposed to work?

All Comments (7)

avatar

Hello scheived,

Thank you for the additional report.

This appears to match the behavior you previously documented in case 55738, where editing a file-backed API endpoint through the VS Code extension targets a different file path than the one PowerShell Universal actually uses for the endpoint.

For endpoints created with `New-PSUEndpoint -Path`, the path is expected to be relative to the `.universal` directory. Based on what you are seeing, we need to verify whether the VS Code extension is resolving that path differently when using the Edit action.

We already have the detailed reproduction information from your previous report, so there is no need to provide it again. We will use that scenario for our internal reproduction and continue the investigation from there.

References:
https://docs.devolutions.net/powershell-universal/api/endpoints
https://forum.devolutions.net/topics/55738/vs-code-extension-editing-a-filebacked-api-endpoint-saves-to-the-wrong

Best regards,
Ruben Tapia

avatar

One additional note: we are also tracking related VS Code extension behavior in case 55651. That investigation has reproduced issues with the extension and bug reproduction steps have already been submitted upstream.

We are going to compare the API endpoint editing behavior reported here and in 55738 against those findings to determine whether they share the same underlying issue or need to be tracked separately.

References:
https://forum.devolutions.net/topics/55651/vscode-extension-for-powershell-universal-anybody-using-it
https://forum.devolutions.net/topics/55738/vs-code-extension-editing-a-filebacked-api-endpoint-saves-to-the-wrong

Best regards,
Ruben Tapia

avatar

Hello scheived,

Just a quick update. Cases #55738 and #55846 have now been escalated together for further review, since both reports describe the same file-backed API endpoint editing behavior in the VS Code extension.

We have included the path-resolution details and the relationship between the two reports so the issue can be reviewed as a single investigation rather than duplicated.

We will update the forum once we have additional findings.

Best regards,
Ruben Tapia

avatar

Hi Ruben,

I just checked the other two tickets / posts you mentioned but I haven't found yet a statement:
Is this an official bug which will be fixed with future releases?

I'm asking since I get two different error messages.

Setup
PSU Version: Version 2026.2.4
Developer License (although issue seems to be identical on our productive server)
Windows Server Version 24H2 (OS Build 26100.33158)
VSCode Version: 1.134.0
VSCode Extension Version: 2026.2.5

Case A
Added a test endpoint withouh specifying an explicit path, hence saving directly to the endpoints.ps1 file:

New-PSUEndpoint -Url "/VSCodeExtensionTest/defaultEndpointsFile" -Description "Test to verify if the endpoint can be edited through VSCode extension if its saved in the default endpoints file" -Method @('GET') -Endpoint {
    # Enter your script to process requests.
    Write-Information "That's the default endpoint file!"
}


Resulting error message when trying to edit the endpoint through the VSCode extension:

Endpoint '/VSCodeExtensionTest/defaultEndpointsFile' does not have a configuration file path.


Case B
Added a test endpoint withouh specifying an explicit path, hence saving the code logic to an external file:

New-PSUEndpoint -Url "/VSCodeExtensionTest/customEndpointsFile" -Description "	Test to verify if the endpoint can be edited through VSCode extension if its saved in the custom endpoints file" -Method @('GET') -Path "customEndpointsFile.ps1" 


Resulting error message when trying to edit the endpoint through the VSCode extension:

cannot open psu://dev/customEndpointsFile.ps1?1b6fe5b7-7182-445a-b69d-d14ca558d2c0. Detail: Unable to read file 'psu://dev/customEndpointsFile.ps1?1b6fe5b7-7182-445a-b69d-d14ca558d2c0' (Error: Unable to resolve nonexistent file 'psu://dev/customEndpointsFile.ps1?1b6fe5b7-7182-445a-b69d-d14ca558d2c0')


Questions
So these two different error messages raise some questions for me:

  • Is it a hard requirement to use a path (instead of saving the API endpoint in the default endpoints.ps1 file) in order to be able to edit it through the VSCode extension?
    • If so, is that somewhere stated in the docs because I couldn't find any info.
  • If not, can you confirm that this is a bug?


If it's a bug:

  • Does it only affect the VSCode extension, only the PSU server itself or both?
  • I know it's quite a stretch but do you have an estimation when this could possibly be fixed?


Thank you in advance for your efforts!

Best regards,
Viktor

avatar

Hello viktorkiss,

Thank you for the detailed additional testing.

I have added your latest reproduction details, including the results with PSU Server 2026.2.4 and VS Code Extension 2026.2.5, to the existing escalated investigation covering cases #55738 and #55846.

I also asked Development for an updated status regarding whether this has been formally confirmed as a bug, the affected component scope, and whether there is currently a target release or ETA that we can share publicly.

I will update this thread once we receive further information.

Best regards,
Ruben Tapia

avatar

Hello @viktorkiss ,

We received an update from Development.

This has been confirmed to require a server-side fix, and the fix is currently targeted for PowerShell Universal 2026.3.0. The current expectation is for that release to be available in approximately one to two weeks.

So, to answer your earlier questions, this is not limited to the VS Code extension itself. A PSU Server change is required to correct the behavior.

Thank you again for the detailed reproduction information. It was very helpful in validating the affected scenarios.

Best regards,
Ruben Tapia

avatar

Hi Ruben,

Thank you so much for the quick response and the transparent communication, really appreciated!

We'll than just wait for the next release.

BR,
Viktor

PS: Since I haven't seen it mentioned yet in a post - outstand customer service so far, please keep up the good work.