JumpStart Workbench Deployment

JumpStart Workbench is distributed as two self-contained artifacts — a VS Code extension (ey-cosmos.cosmos-workbench, display name JS Workbench) published to the VS Code Marketplace, and a packaged Electron desktop app — plus an optional CLI/server mode for browser/PWA use. There is no hosted multi-tenant deployment; each consultant installs the extension or desktop app on their own machine.

Build And Package

Packaging always runs from the cosmos-workbench repo root, with cosmos-code (and cosmos-sdk-typescript) checked out as siblings (see Integration for the required layout).

VS Code Extension

bun run vscode:package                                          # host platform only
node packages/vscode/scripts/package-vsix.mjs darwin-arm64 win32-x64  # standard publish set
node packages/vscode/scripts/package-vsix.mjs --all                # same standard set

Each target produces one platform-specific .vsix in packages/vscode/dist-vsix/; no universal VSIX is built because each one carries the matching runtime binary:

These two targets are the standard publish set. Other targets (darwin-x64, win32-arm64, linux-x64, linux-arm64) can be built by passing them explicitly when there is demand.

Build the Cosmos Code runtime first with bun run build --skip-embed-web-ui in cosmos-code/packages/opencode; the packaging script only copies whatever is already in dist/, so a stale build silently ships an old runtime. Build feature branches with OPENCODE_CHANNEL=develop, because the runtime stores sessions in a per-channel database and a different channel opens an empty one.

Packaging stages the built Cosmos Code binary into packages/vscode/resources/opencode-cli/ and verifies it against a cosmos-runtime.json manifest before producing the .vsix. Rebuilding the VSIX for a plain code change is the slow path — use bun run vscode:dev for iteration (see DEV-LOOP.md in the repo).

Desktop App

bun run electron:build

Runs, in order: build the web UI and stage it into packages/electron/resources/web-dist; stage the built Cosmos Code runtime into packages/electron/resources/opencode-cli; bundle Electron main code; rebuild native modules for the Electron runtime; run electron-builder.

Linux AppImages require FUSE (libfuse2/libfuse2t64) to run, or APPIMAGE_EXTRACT_AND_RUN=1 as a fallback. Auto-update on Linux only works when the app is running from a writable AppImage path.

Distribution

The VS Code extension is published as ey-cosmos.cosmos-workbench to the VS Code Marketplace, and the CI workflow (.github/workflows/vscode-extension.yml, run on v* tags or by manual dispatch) also publishes it to Open VSX. A local publish uses vsce publish --packagePath <vsix> for each target with a Marketplace PAT for the ey-cosmos publisher; the repo's docs/PUBLISHING.md describes the full release steps, including bumping the version in all five package.json files together. Desktop installers and side-loaded .vsix files can still be shared directly, matched to the recipient's OS and architecture.

Install (VS Code Extension)

Install JS Workbench (ey-cosmos.cosmos-workbench) from the Extensions view, or side-load a .vsix as below. The extension requires VS Code 1.106 or later.

1. Uninstall the old extension first, if present. The extension identifier changed from ey-cosmos.cosmos-dev-studio to ey-cosmos.cosmos-workbench; VS Code treats them as separate extensions and will run both (two runtimes, two chat views) if both are installed:
   bash

   code --uninstall-extension ey-cosmos.cosmos-dev-studio
   

   Credentials (~/.local/share/cosmos-code/auth.json) and settings keys are unaffected by the rename.
2. On macOS, clear the download quarantine before installing a .vsix that arrived via Teams, email, or a browser — otherwise macOS kills the embedded runtime on launch:
   bash

   xattr -dr com.apple.quarantine cosmos-workbench-<version>-darwin-arm64.vsix
   

3. Install via the Extensions view (... menu → Install from VSIX...) or:
   bash

   code --install-extension cosmos-workbench-<version>-darwin-arm64.vsix
   

4. Reload VS Code, open the JS Workbench view, then go to Settings → Providers → Cosmos and click Sign in to Cosmos. Sign-in uses OAuth with PKCE — no client secret or config file needed. The workspace is bound to the organization named jumpstart when you belong to it (or to your only organization); otherwise pick one, then confirm a project. Use Change Organization or Change Project from the Command Palette to switch later.

The extension writes ~/.config/cosmos-code/cosmos-code.jsonc (Windows: %USERPROFILE%\.config\cosmos-code\cosmos-code.jsonc) with Cosmos service endpoints on first activation and adds a cosmos provider if one is missing. When a release raises the config migration version, the five Cosmos service URLs are reset to the bundled defaults once and the stored token is cleared, so you sign in again; other settings are kept. It also registers the bundled SAP MCP server as mcp.sap unless you defined that entry yourself. Credentials live separately in ~/.local/share/cosmos-code/auth.json, never in the config file.

Network Notes

The extension relaxes TLS verification for the runtime it starts (NODE_TLS_REJECT_UNAUTHORIZED=0), because EY network interception re-signs traffic with a CA the bundled runtime does not trust by default. To keep verification enabled instead, set NODE_EXTRA_CA_CERTS to the corporate CA bundle before starting VS Code; an explicitly set NODE_TLS_REJECT_UNAUTHORIZED is also respected. SAP connections have their own certificate settings (see Integration).

Troubleshooting

Related Documentation

• Overview
• Architecture
• Integration