OpenChamber, A to Z: what the SDK can change, what only React source can change

🎯 TL;DR — the real answer

Three sentences:

1. Yes, A-to-Z is possible. Nothing is hidden or compiled-only in a proprietary way: the React UI (4,388 files), the Express server, the Electron shell, the Capacitor mobile app and the VS Code extension are all in the repository under MIT.
2. But "can" is not "should". Roughly 60–70% of everyday customisation — colours, panels, menus, slash commands, tool rendering, integrations, status widgets, file editors, git hosts — is achievable with the extension SDK and JSON config without touching React.
3. The remaining 30–40% — layout shell, composer, timeline visuals, settings pages, onboarding, auth/relay, mobile and VS Code behaviour — requires editing React/JS source and accepting merge work with every upstream release.

🧭 The three customisation layers

Each layer is a different contract with different maintenance cost. Choose the lowest layer that can express your change.

📋 A-to-Z capability matrix

Legend: SDK no React edit · PART partially, or needs a small core patch · CODE React/server source required.

Visual identity

Layout and navigation

Chat and agent interaction

Data, integrations and services

Platform and deployment

🧩 What the SDK can do (full contribution surface)

These are the only ways an extension can enter the app. Each is declared in package.json under openchamber.contributes and validated on disk at install time.

Host API you can call

connectHost() exposes a permission-checked RPC, not a DOM API: onReady, onDirectory, onSession, onSessionLifecycle, onConnection, onSettings, onItem, onAction, onResolve, onFileOpen, onFileSnapshot, onFileSaved, onStatusControl, onPopoverClosed, plus methods such as toast, compose, attach, prompt, startSession, openSession, listProjects, listWorktrees, listSessions, storage.get/set/delete/keys, generate, setBadge, setHeight, openCommit, openUrl, openPopover, request, oauthStart, readFile, writeFile, listDir, stat.

Theme tokens are pushed into the iframe on every onReady, so your extension can look native — including syntax colours — without importing app CSS.

🚫 What the SDK cannot do

This list matters more than the previous one, because these are the requests that look possible and are not:

• Touch the host DOM or CSS. Every extension runs in a sandboxed iframe with its own document. No selectors reach app elements, and the app's React context is not shared across the boundary.
• Restyle or rearrange an existing panel. Extensions add slots; they cannot edit the sidebar, composer, timeline, diff viewer or settings pages.
• Inject UI anywhere outside the declared surfaces. Rail panel, page, dialog, status section, file editor, docked surface, popover. There is no "render a button in the header" hook.
• Add a settings section of its own. Only the fields declared under integration.settings, rendered in the integration card.
• Change keyboard shortcuts, default models, the notification policy, or theme defaults. All core.
• Ship TypeScript or ESM. Install rejects it: the panel must be a classic IIFE and the service plain compiled JS. No runtime compilation exists anywhere.
• Run continuously. Background work is on-demand, ends after the handler settles, and is capped at ~20 s per invocation.
• Read secrets. Tokens stay on the server; the iframe gets account state, never the credential.
• Run on mobile or VS Code. Only web and desktop load extensions today; the other surfaces report them as unsupported.
• Change the extension contract itself. A new contribution type is a change to packages/sdk and packages/ui/src/lib/guests — a core patch, not an extension.

⚛️ What needs React source edits

Everything here is a normal component edit, but it is your fork now. The app is TypeScript + React 19 + Tailwind 4, built with Vite 7.

Yes, literally every file is editable

There is no generated UI code you are forbidden to touch, no closed binary in the frontend path, and no obfuscation. The practical ceiling is not permission, it is:

• Compilation: React 19 + TypeScript + Tailwind 4 + Vite 7; the server runs on Node ≥ 24.14 (Bun 1.4.4 for the build).
• Coupling: shared stores (zustand), the streaming bridge and the settings registry mean a "small" change can ripple.
• Merge cost: upstream ships quickly; every core file you edit is a future conflict.
• Licence: MIT — keep the copyright and permission notice in redistributions.

⏱️ Effort and maintenance cost

Ranges assume you know React and TypeScript; they are estimates, not measurements.

🛠️ Recommended workflow

1. Write the change down as a sentence

"Add a Deploy panel that shows CI status and can start a deploy." → extension. "Make the sidebar 40 px wider and move sessions to the left." → React edit. The sentence selects the layer.

2. Exhaust layer 0 before writing anything

Themes, settings, project actions, magic prompts, OpenCode config, skills and MCP servers cover a surprising amount of "customisation" with zero maintenance.

3. Build the extension against the documented slots

my-ext/
├── package.json        # openchamber.contributes block
├── panel/index.html    # sandboxed page
├── panel/main.js       # built IIFE — the app never compiles TS
└── icon.svg            # optional, package-local

bunx openchamber-guest-bundle panel/main.ts panel/main.js
# then: Settings → Extensions → add folder / zip / git URL

Install from a folder while developing, so edit → rebuild → reload is instant. Switch to a pinned git URL for distribution.

4. Keep the fork surgical

• One branch, one purpose: custom/theme, custom/shell — never mixed.
• Prefer token overrides and new files over edits inside big components.
• Pin the release tag; rebase monthly rather than continuously.
• Track every core file you touch in a short list. That list is your real maintenance bill.

5. Choose your distribution

⚠️ Hard limits and risks

📚 Sources

• github.com/openchamber/openchamber — monorepo main, app version 2.5.2, MIT.
• packages/sdk/README.md — manifest fields, capabilities, install rules, actions, pages, status sections, storage, services, UI kit.
• packages/sdk/API.md — full host/guest protocol, subscription and method list, limits, error codes.
• packages/sdk/DOCUMENTATION.md — architecture of the guest contract, service providers, surfaces, file editors.
• packages/docs/content/docs/extensions.mdx, sdk.mdx, sdk/host.mdx, sdk/ui.mdx — user-facing documentation.
• docs/CUSTOM_THEMES.md and packages/ui/src/lib/theme/DOCUMENTATION.md — theme authoring and validation.
• packages/extensions/DOCUMENTATION.md and registry.json — built-in allowlist, empty today.
• Package manifests, packages/ui/src tree (4,388 files, 40.6 MB), packages/web/server (hand-written ESM JS), read 27 October 2026.