Sign in

JumpStart Workbench

Overview of JumpStart Workbench, EY's fork of OpenChamber packaged as a VS Code extension and desktop app for Cosmos-registered agents

consumerjumpstartworkbenchvscodeelectroncosmos-code

Updated 2026-11-03

Verified 2026-11-03

JumpStart Workbench is EY's fork of OpenChamber (cosmos-workbench), repackaged as the ey-cosmos.cosmos-workbench VS Code extension and an Electron desktop app. It lets a signed-in EY user drive Cosmos-registered agents from an editor sidebar, a native desktop window, or the CLI/TUI, using the same session-management, multi-run, and change-review UX that OpenChamber provides upstream — pointed at Cosmos instead of a standalone OpenCode install.

Unlike JumpStart SAP Intelligence and JumpStart AMS, which are server-hosted web applications, JumpStart Workbench runs on the consultant's own machine: as an editor extension, a packaged desktop binary, or a locally-run web/CLI server.

What It Is

  • An EY-branded fork of the open-source OpenChamber project, not a new product built from scratch.
  • Distributed as a VS Code extension (display name JS Workbench, publisher ey-cosmos, extension ID ey-cosmos.cosmos-workbench, version 2.1.x, VS Code 1.106 or later) published to the VS Code Marketplace, and as an Electron desktop app for macOS, Windows, and Linux.
  • Every build embeds a signed Cosmos Code binary — EY's fork of the OpenCode CLI/TUI — instead of depending on a system-installed OpenCode.
  • On first activation, it seeds a cosmos provider into the user's Cosmos Code config so there is something to sign in to immediately. It never writes secrets; the only later change it makes to an existing cosmos provider is a one-time endpoint migration when the bundled config migration version changes (see Integration).
  • It registers a shared SAP MCP server for the runtime and manages per-user SAP connection profiles, so sap_* tools are available to agents without any separate install.

Why It Matters

Consultants and engineers already have Cosmos-registered agents, skills, and tools; JumpStart Workbench gives them a familiar, IDE-integrated way to run agent turns, review diffs, and manage sessions without leaving their editor or needing a separate web app. Because the runtime is a private, signed Cosmos Code build, agent behavior (for example the main-agent-only chat restriction described below) is enforced by the embedded binary, not by trusting the client UI.

Architecture At A Glance

SurfacePackageRole
VS Code extensionpackages/vscodeSidebar chat, session/agent management webviews, editor selection context
Desktop apppackages/electronNative shell around the same web UI/server, SSH, tunnels, native notifications, auto-update
Web / PWApackages/webBrowser-hosted UI and server, used standalone or embedded by desktop/VS Code
Shared UIpackages/uiReact UI, state, and sync logic shared across all surfaces
Mobilepackages/mobileCapacitor iOS/Android shell connecting to an existing server
Embedded runtimestaged cosmos-code binarySigned Cosmos Code CLI/TUI, staged into each package's resources at build time

See Architecture for how these surfaces relate to the embedded runtime and to Cosmos, and for what was changed versus upstream OpenChamber.

Key Capabilities

  • Session-driven agent work — start, resume, and review agent sessions from the sidebar, desktop window, or CLI/TUI, backed by the same session model as upstream OpenChamber (Session Goals, Multi-run, Changes Walkthrough, Preview).
  • Cosmos-backed runtime, not upstream OpenCode — the VSIX and desktop app ship a signed Cosmos Code binary staged by scripts/cosmos-runtime.mjs; verify-opencode-cli.mjs re-hashes it against a cosmos-runtime.json manifest so a packaged build can prove what it contains.
  • Zero-touch first run — packages/vscode/src/cosmos-config-seed.ts writes a minimal cosmos provider stanza (endpoints only) on first activation if none exists. An existing provider keeps its settings, except that the five Cosmos service URLs are reset to the bundled defaults once per config migration version.
  • Organization and project binding — each workspace is bound to a Cosmos organization and project. The organization named jumpstart is used by default when the user belongs to it; the Change Organization and Change Project commands switch the binding.
  • Environment switching — the Switch Environment command moves the runtime between the Develop and UAT Cosmos environments (and a local stack for locally built runtimes) and asks the user to sign in again.
  • Shared SAP tools — a bundled SAP MCP server is registered as the runtime's mcp.sap entry, and the SAP: Add or Edit Connection, SAP: Test Connection, SAP: Update Connection Password, and SAP: Remove Connection commands manage per-user SAP systems.
  • Deterministic runtime resolution — resolveOpencodeCliPath() prefers the bundled runtime over any OpenCode binary already installed on the machine, so the extension is self-contained by default.
  • Namespace isolation from upstream OpenChamber — every VS Code-global identifier (view container, views, commands, webview view types, the diff URI scheme) is renamed to a cosmos.*/cosmos-diff namespace so JS Workbench can coexist with a real OpenChamber install in the same window.
  • Main-agent-only chats — the selected main agent handles all chat work; agent mentions are sent as text rather than delegated to sub-agents, and this restriction is enforced by the embedded Cosmos Code runtime.

Relationship To Other Cosmos Repos

JumpStart Workbench, cosmos-code, and cosmos-sdk-typescript are sibling repositories checked out side by side (see Integration for the required layout). cosmos-code's ADK v2 WebSocket client resolves @cosmos/sdk via a file: link to cosmos-sdk-typescript, and JumpStart Workbench stages a locally-built cosmos-code binary rather than depending on it through a package registry.