Atrium

See the page, not its source.

Click a Markdown file in the Explorer and Atrium opens VS Code's native Markdown Preview. Click an HTML file and Atrium opens VS Code's Integrated Browser. Right-click → Open With → Text Editor when you want the source.

Atrium can also run static websites with JSON-file persistence and packaged Node web apps with their own backend and local database. Add an atrium.json manifest, then open Explorer → Atrium Servers to see your apps and their status.

Version 0.14.0 adds the managed Node runtime. Static schema-1 packages remain compatible. App publishers can use the managed app contract and Node Notebook example.

Atrium Servers

Give a supporting VS Code assistant a prepared app folder containing atrium.json and ask “Add this app to Atrium.” The assistant uses Atrium's included skill and app-management tool to register it. The app appears as Stopped in Explorer → Atrium Servers. Press Run to start its local server and open the website in VS Code's Integrated Browser.

If you ask the assistant to open or launch the app, it can register, run, and open it in one action. Atrium: Open App Folder provides the same shortcut through a folder picker. Atrium: Add App registers a folder without starting it.

Each row shows Stopped, Starting, Running with its port, Stopping, or Error. These statuses describe the local server, not the health of external APIs. Local apps require a trusted workspace on the local desktop; the view explains when running is unavailable.

You can run several websites at once. New and removed workspace manifests update the list automatically. Editing a running website's manifest stops its server so you can restart with the new configuration. Removing a workspace folder stops its servers; explicitly registered apps remain in that workspace's catalog until unregistered. Unregistering never deletes files. Servers start on a launch/run request, not on workspace startup, and stop when the workspace closes.

Try a packaged app

1. Install or update Atrium from the Marketplace and verify version 0.14.0 or later in Extensions. Reload VS Code if prompted.
2. Obtain a complete built app folder from its publisher and make it available locally. The extension does not include example app folders. The 0.14.0 release provides atrium-node-notebook-v0.14.0.zip separately. Repository/release access is required, or transfer the ZIP through an approved channel and extract it on the test computer.
3. Open a trusted local workspace. Give the folder to a supporting assistant and ask “Add this app to Atrium.” Or run Atrium: Add App and select the folder.
4. Press Run in Atrium Servers. For a Node app, confirm that you trust its code; it runs with your operating-system permissions. The website opens in Integrated Browser.
5. Save a test record, reload, then Stop and Run again to check persistence. Sign in with Microsoft only if the app supplies a shared-data connection.

Node Notebook is a local-only persistence test; it does not exercise Microsoft sign-in. A work-account test needs a publisher-prepared SharePoint app and test list. Company access policies, native prompts, and the real assistant workflow still need the work-computer pilot.

Microsoft accounts and SharePoint (experimental)

The app package supplies its SharePoint connection. Open the app and choose Sign in with Microsoft when it needs shared data. Atrium first tries an authorized VS Code Microsoft session, then lets VS Code show normal sign-in or consent if necessary. The Microsoft account row can also sign in directly. End users do not enter tenant/client IDs or configure a list connection first.

Identity sign-in requests User.Read. A schema-2 app using VS Code's built-in client requests delegated Sites.Read.All by default, or Sites.ReadWrite.All when its publisher declares microsoft.write: true. Schema-1 Academy connections continue to request Sites.ReadWrite.All. A publisher can instead supply a custom client and selected-list access; no broader scope is used as a fallback. Microsoft's client permissions and company policies still determine whether access is allowed. Microsoft sign-in and session reuse have been verified; company SharePoint reads, saves, and two-user permissions/conflicts remain experimental pending a work-computer pilot. Personal Microsoft Lists at lists.live.com are not supported by this Microsoft Graph connector.

App authors supply siteId and listId in the manifest's microsoft object. Optional tenantId, clientId, and access support deployment policy. Advanced local bindings can override the destination. See the Agent Academy publisher guide for its required columns and permission modes.

A synced SharePoint/OneDrive folder launches like any local app. A remote folder URL uses reviewed, bounded import; opening that app requires explicit approval to run its code. Optional URL discovery/import can request additional permissions. A SharePoint list link by itself is not an app.

Assistant app management

Atrium automatically contributes its atrium-apps skill to VS Code Chat. No separate skill-installation step is needed in supporting VS Code chat agents. The skill and #atriumApps tool distinguish add (register and leave stopped) from launch (register, run, and open). Supply the folder with an explicit request; Atrium does not intercept arbitrary chat attachments.

Atrium: Install Assistant Skill remains an optional way to copy the skill into .github/skills/atrium-apps/ for assistants that read workspace skills. It does not overwrite existing files. An assistant outside VS Code can dispatch vscode://vegadevshop.atrium/add?source=<encoded-absolute-folder> for registration or /launch?source=<encoded-absolute-folder> to open the app, then verify the result in Atrium.

What it opens

• Markdown (.md, .markdown) → VS Code's native Markdown Preview, including its parser, themes, plugins, security controls, links, and live reload.
• Local HTML (.html, .htm) → VS Code's Integrated Browser, with native browser behavior, relative assets, navigation, developer tools, and file-change reload support.
• If a native visual editor is unavailable, Atrium opens the file as source and explains why.

Copilot Chat integration (optional)

Atrium registers a URI handler at vscode://vegadevshop.atrium/open?file=<absolute-path>. Any time Copilot Chat (or anything else that emits vscode:// links) ends a response with a link in that format, clicking uses the same route as Explorer: Markdown Preview or Integrated Browser.

Wire Copilot into this by adding to your .github/copilot-instructions.md:

## File references

Whenever I create or edit an `.md`, `.markdown`, `.html`, or `.htm` file, end the response with:

[label](vscode://vegadevshop.atrium/open?file=<urlencoded-absolute-path>)

<urlencoded-absolute-path> is the file's absolute path through encodeURIComponent.

Settings

No settings are required for native previews, local apps, or starting Microsoft sign-in. atrium.microsoft.tenantId and atrium.microsoft.clientId are optional advanced deployment defaults; leave them empty to use VS Code's Microsoft client. Packaged identity values take precedence. Optional: workbench.editorAssociations if you want different defaults for a specific file type. To edit .md as source instead of preview, add:

"workbench.editorAssociations": {
  "*.md": "default"
}

Why Atrium?

VS Code already has excellent visual editors, but files normally open as source. Atrium is the missing default-open behavior: click the file, see the result. It does not parse or render your content itself.

Commands

Local apps (experimental)

Schema 2 runs a packaged .mjs module exporting createApp, using VS Code's supported embedded Node runtime. Atrium owns the listener, protected proxy, lifecycle, health checks, and per-user data directory outside the app package. A native trusted-code prompt precedes each new process. These apps have the user's OS permissions; this is not a sandbox. Node packages must be built before distribution; no dependency install or shell command runs on Add/Run. The direct remote importer stays static-only; use a complete synced/downloaded folder for Node apps.

The optional schema-2 Microsoft bridge accepts ordinary SharePoint list fields. It requests read access by default and write access only with microsoft.write: true. Publishers supply the destination and list schema. VS Code owns sign-in; real company-account tests remain pending. Schema-1 Academy behavior below is unchanged. Full contract, adapter, limits, and test plan: Managed apps.

A static schema-1 app is a folder containing atrium.json, a static app directory, and a constrained data directory:

{
  "schemaVersion": 1,
  "app": { "root": "app", "entry": "index.html" },
  "data": { "root": "data", "writable": ["*.json"] }
}

Load /_atrium/client.js in the page, then use window.atrium.storage.read("dashboard.json") and window.atrium.storage.write("dashboard.json", value). Each website binds to 127.0.0.1 on its own available port, accepts JSON up to 1 MiB, and confines access to manifest-declared paths. Local apps require a trusted local filesystem workspace in desktop VS Code.

See examples/local-dashboard for a runnable example.

For a people directory, owned skill registry, and training-progress dashboard, run npm run dev:academy and open the printed local URL. Agent Academy saves to a local JSON file by default. A publisher can package a SharePoint List connection for use through Atrium in VS Code; the app then requests Microsoft sign-in when needed. Live access requires a prepared list, user rights, and the permissions allowed by the organization's policies. A custom selected-permission deployment also requires its app-specific grant. The local sample needs none of these.

Apps that need stale-write protection can use storage.readVersioned(key, fallback) to get { value, version }, then pass that version as the third argument to storage.write(key, value, version). A stale write returns HTTP 412. This coordinates tabs on one local server, not independent synchronized filesystem copies.

License

MIT