VS Code extension: editing a file-backed API endpoint saves to the wrong path (.universal prefix dropped)

VS Code extension: editing a file-backed API endpoint saves to the wrong path (.universal prefix dropped)

avatar

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.

All Comments (1)

avatar

Hello scheived,

Thank you for the detailed report and for documenting the path-resolution behavior so clearly.

We will reproduce this scenario internally using PowerShell Universal Server 2026.2.3 and the VS Code extension 2026.2.3, including verification of the file opened by the Edit action, the path written by the extension, and the file actually executed by the endpoint.

Once we confirm the behavior in our lab, we will escalate the findings internally with the reproduction steps and supporting evidence for further review.

We will update this thread when we have additional information.

Best regards,
Ruben Tapia