Read-only file verb (file.read) scoped to the workspace folder, allowed on cloud containers

Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 1mo ago ·closed by John Lauer

Context: shared Hydrogen workspaces (hydrogen/workspace.json in a project repo; wiki dispatch A on prod, adom-wiki 1.7.42, adom-cli 0.6.0, Hydrogen Cloud dispatch D deployed today). Hydrogen Cloud's Project workspaces dropdown and its Apply button run adom-cli hydrogen workspace apply in the container through this extension's POST /terminal/tui verb, which works on cloud containers. What the cloud cannot do is READ the container's checkout: /exec is disabled on cloud by policy (correctly), and there is no file verb, so the dropdown lists a mirror of hydrogen/workspace.json kept in a bucket instead of the file in ~/project, and Apply cannot consult ~/.adom/launches.json to know which apps already serve.

Ask: a read-only file verb, allowed on cloud containers the way terminal.tui is.

GET /file?path=<relative> (or POST /file/read {path}): returns the file's bytes (or {content, size, mtime} as JSON for text), 404 when absent.
Scope: paths resolved under the workspace folder /home/adom/project only (the same scope rule the extension already enforces elsewhere), no symlink escape, plus an explicit allow-list for ~/.adom/launches.json (the adom-cli launch registry) since it lives outside the workspace.
Read-only, no listing needed for this use (a GET /file/list?path= would be welcome but is not required).
Feature-detect through the /health verb roster (file.read), like every other verb.

Consumers ready to switch the day it lands: Hydrogen Cloud src/lib/server/sharedWorkspaces.ts (the only file that changes there, per the HC thread), and the wiki's Open in Hydrogen deep link. Until then adom-cli posts the file to the cloud's write route on export and apply as a workaround.

Reference: ~/project/hydrogen-cloud-workspaces-spec.md and ~/project/shared-workspaces-plan.md on Colby's container; adom-vscode 1.1.49 is what the cloud verified against.

2 Replies

John Lauer · 8d ago

Shipped in adom-vscode 1.1.115 (published, GitHub main 0adcf39). A read-only file verb, allowed on cloud containers too:

GET  /file?path=<path>
POST /file/read   {"path": "<path>"}

A relative path resolves under ~/project; ~/ expands to the home directory; absolute paths work.
Allowed: anything under ~/project (checked on the real path, so a symlink cannot point out of it), plus ~/.adom/launches.json.
Regular files up to 2 MB. Text comes back as content ("encoding":"utf-8"), anything else as base64, with size, mtime and mtimeMs.
A missing file returns {"ok":false,"notFound":true}, so you can tell absent from refused.
/health lists it as file.read, so a caller can check for it before using it.

Verified live on a workspace running 1.1.115: a text file under ~/project, ~/.adom/launches.json, a missing file, POST, and refusals for ../../../etc/passwd, /etc/shadow and a symlink in ~/project pointing at /etc/passwd.

Existing workspaces pick it up with adom-vscode update (or the next auto-update). Closing; reopen if the shape doesn't fit what you're building.

John Lauer · 8d ago

Correction to my last line: the upgrade is adom-wiki pkg update adom-vscode (daemon-managed updates also pick it up), then reload the VS Code window. adom-vscode update updates VS Code extensions, not adom-vscode itself.