wraptool-vscode

Review wraptool capability requests without leaving the editor: a tree of pending requests, an OS notification when a new one arrives, and Approve / Deny actions — a thin client of wraptool's /api/v1 admin API (see design/webui/admin-json-api.md in the wraptool repository, which owns the contract).

Step-by-step guides for people new to VS Code: installation and the user manual.

Setup

1. Enable the review UI in wraptool (admin.listen + admin.auth_token_file).
2. Set wraptool.adminUrl if it differs from http://127.0.0.1:8718. Plain http is accepted for loopback only — the admin token is a bearer credential, so any other host must be https.
3. Run wraptool: Sign In and paste the admin token. It is kept in VS Code's SecretStorage, never in settings.

The extension runs in the UI extension host (extensionKind: ui), so with Remote-SSH or a dev container it talks to your machine's loopback — where the admin listener lives — not the workspace host. That is deliberate: the agent-facing container must never reach the approval surface.

Development

npm install
npm test        # compile + run the test suite

src/core.ts holds every piece of logic that does not need the extension host — URL validation, the admin API client, the poll/notify state machine, message formatting — and imports no vscode. src/extension.ts is glue only. Tests in test/ run in a plain Node process against out/core.js: core.test.mjs for the pure helpers, client.test.mjs for the API client against a stubbed fetch, monitor.test.mjs for poll and notification state, and http.test.mjs for round-trips against a real loopback listener.

npm run test:integration   # smoke suite in a real VS Code extension host
npm run test:all           # both suites

test/integration/ holds the smoke suite, which the unit tests cannot cover: activation, command registration, agreement between the manifest and what the code actually registers, configuration defaults, and a full settings -> SecretStorage -> poll -> approve/deny round-trip against a stub listener, driven through the real commands.

vscode-test downloads a VS Code build into .vscode-test/ by default. That prebuilt binary needs the FHS dynamic loader, so on Guix or NixOS it fails with spawn .../code ENOENT; point the runner at an installation that does run. VSCodium works as well as VS Code — the runner launches the executable directly with the extension-host flags, and both accept them:

VSCODE_TEST_PATH=$(which codium) npm run test:integration

A headless machine also needs an X server — prefix with xvfb-run -a.

Press F5 in VS Code to launch an Extension Development Host.

npm run screenshots regenerates docs/screenshots/ by driving the extension in a headless editor (Xvfb, xdotool, ImageMagick; on Guix the first two are fetched through guix shell). Point VSCODE_TEST_PATH at the executable to capture with; it defaults to codium on PATH.

v1 scope

Polling only (wraptool.pollSeconds, default 5s) — wraptool's v1 API has no event stream. No rules editing, no details webview; the Web UI remains the full-featured surface.

License

GPL-3.0-or-later, like wraptool itself. See LICENSE.md.