OpenChamber: an agent workspace that follows your sessions across desktop, web, VS Code and mobile
Agentic Development Environment based on OpenCode AI agent
At a glance
- What is it?
- OpenChamber wraps the OpenCode CLI in a multi-surface workspace for starting, reviewing and releasing AI coding work. The interesting part is not the chat UI but Session Goals, Multi-run and Private Relay, and the cost of that breadth is a Node 22 requirement, an external OpenCode install on everything except desktop, and a security model you configure yourself.
- Who is it for?
- Adopt OpenChamber if you already run the OpenCode CLI, want agent sessions to survive a device switch, and need goal loops or parallel model runs without building that orchestration yourself. Do not adopt it if you need a permission model you do not have to assemble, or if you cannot run Node.js 22+ on the host that serves the web UI.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenChamber adds on top of the OpenCode CLI
The README describes OpenChamber as "an open-source workspace for running and reviewing AI coding work on desktop, web, VS Code, and mobile." That phrasing matters more than it looks. OpenChamber is not a model, not an agent runtime, and not a replacement for the OpenCode CLI. The CLI is the thing that talks to models and edits files. OpenChamber is the layer that starts sessions, keeps them alive across devices, shows you what changed, and gives you somewhere to approve it. The README is explicit that CLI/Web and the VS Code extension "use your installed OpenCode CLI," while the desktop build "bundles the matching OpenCode CLI, so no separate OpenCode installation is required." That split tells you who the project is for: developers who already have an OpenCode workflow and want persistence and review around it, rather than people shopping for a first coding agent. The stated surfaces are desktop (macOS, Windows, Linux), Web/PWA, VS Code, iOS and Android, plus a CLI/server mode for workstations and servers. The pain it targets is concrete. Agent sessions are long, they get interrupted, and the diff they produce is often too large to read top to bottom. OpenChamber's answer is to keep the session addressable from whatever device you are holding and to turn the diff into something you can walk through.
Session Goals, Multi-run and Fusion: the mechanisms that differ from a chat window
Three features carry most of the project's weight, and each has a stated mechanism. Session Goals give a session "a finish line." According to the README, OpenChamber "checks the result after every turn and keeps the agent working until it completes the goal, gets blocked, or reaches the limit you set," and it "can continue after you close the app." The loop is therefore turn-based with a post-turn check and an explicit limit, which is the right shape: an unbounded loop with no stop condition is a billing incident, not a feature. Multi-run takes one task and gives it to "up to five models, each in its own session and optionally its own worktree." The worktree detail is the part worth noting, because it means parallel runs can write to disk without colliding, and you compare real builds rather than transcripts. Fusion then takes the strongest parts of those runs and combines them "into a new session," which is a merge of results rather than a vote. Changes Walkthrough addresses the review side: it "groups related edits into steps, puts them in the order the change makes sense, and explains how the pieces fit together." Preview closes the loop from the other direction. It opens your running app beside the conversation, and pointing at an element sends the agent "its screenshot, styles, position, and browser errors." That is a much narrower and more useful payload than a pasted stack trace. The desktop app can do the same with any web page in its built-in browser. Scheduled tasks reuse the goal loop: a prompt runs once, daily, weekly, or on a cron schedule, and scheduled tasks "can use Session Goals, so they continue toward an outcome instead of stopping after one response."
Installing it: which command applies to which surface
The install path depends entirely on which surface you want, and the README does not pretend otherwise. Desktop users download from GitHub Releases. On Linux the artifact is an AppImage in x86_64 and ARM64 builds, and the documented steps are to make it executable and keep it somewhere writable so in-app updates work: chmod +x OpenChamber-*.AppImage then ./OpenChamber-*.AppImage. Two constraints are stated plainly. AppImages require FUSE (libfuse.so.2), and without FUSE you run with APPIMAGE_EXTRACT_AND_RUN=1. VS Code users install from the Visual Studio Marketplace or search for "OpenChamber" in Extensions. The web and PWA path is the one with the most moving parts. It requires Node.js 22+ and your installed OpenCode CLI, and the README gives this install command: curl -fsSL https://raw.githubusercontent.com/openchamber/openchamber/main/scripts/install.sh | bash. You then start it with openchamber --ui-password be-creative-here. The documented operations are openchamber status, openchamber connect-url --qr, openchamber tunnel start --provider cloudflare --mode quick --qr, openchamber startup enable, openchamber logs, openchamber stop, and openchamber update. The networking defaults are stated directly: OpenChamber binds to localhost by default, and the README says to use --lan only on a trusted network and to protect browser access with --ui-password. Treat that sentence as the security posture, not as a suggestion. If you expose the UI on a LAN address without a password, you have put an agent that edits your files behind nothing but your network boundary.
Private Relay, tunnels and the access model you are actually choosing
Remote access is where OpenChamber makes its most opinionated choice. Private Relay pairs a device with a one-time QR code and connects "without opening ports or exposing a public server." The README states the connection is end-to-end encrypted and can be revoked at any time. That is a narrower exposure than a tunnel, and the alternatives are listed rather than hidden: direct connections, LAN/VPN access, Cloudflare and Ngrok tunnels, and SSH. The tunnel command in the README, openchamber tunnel start --provider cloudflare --mode quick --qr, is the convenient one and also the one that puts your workspace behind a third-party hostname. Quick tunnels are fine for a five-minute check from a phone and a poor default for a workspace that can run shell commands. The honest reading is that OpenChamber gives you several doors and expects you to pick. Nothing in the supplied material describes a granular permission system, per-command approval rules, or a sandbox around the agent. The README points to a security guide at packages/docs/content/docs/security.mdx, and that file is where you should look before pointing this at a repository you care about. Until you have read it, assume the agent inherits whatever your OpenCode CLI can do on that machine.
Where OpenChamber is the wrong tool
The clearest limitation is the dependency split. Desktop bundles the matching OpenCode CLI. Everything else does not. The README says CLI/Web and VS Code "use your installed OpenCode CLI," which means version drift between OpenChamber and your OpenCode install is your problem to diagnose, and the troubleshooting guide is the place the project expects you to look. If you want a single self-contained binary on a server, the desktop bundle is not available to you there. The second limitation is Node.js 22+. That is a hard floor for the web and PWA path, and on long-lived servers it is often the constraint that decides whether you can run this at all. Third, the multi-device story depends on a running server. The README says the connection "can be revoked at any time" and that sessions remain available when you switch devices, but that only holds while the host process is up. openchamber startup enable exists precisely because the server has to survive logout, and if it does not, your phone shows nothing. Fourth, Multi-run with up to five models is a cost multiplier, not a free comparison. The README mentions tracking token use and costs across sessions, which implies the project knows this, but the decision to fan out one task to five models is yours and it bills accordingly. Finally, if your work is small, single-file edits, this is a large surface for a small job. A terminal and the OpenCode CLI will be faster than installing a workspace, a PWA, and a mobile client.
How it differs from running OpenCode CLI in a terminal, and from editor-native agents
The real alternative for most readers is the thing OpenChamber sits on: the OpenCode CLI by itself. The difference is persistence and review. A terminal session ends when the terminal ends, and the diff arrives as one block. OpenChamber adds a server that holds sessions, a Changes Walkthrough that sequences a diff into steps, Preview that ships element context back to the agent, and a goal loop that survives the app being closed. If you never switch devices and never need a guided diff, none of that earns its install cost. The other comparison is an editor-native agent, which is what the VS Code extension here competes with on its home turf. The distinction is where state lives. An editor-native agent is scoped to the window you have open; OpenChamber's sessions are held by a server and reattached from a phone, a browser, or another machine. That is a genuine architectural difference and also the reason the security surface is larger. A second alternative worth naming is a plain tunnel plus a web terminal: cheaper to reason about, no session model, no diff walkthrough, and no goal loop. OpenChamber's bet is that agent work has become long enough and parallel enough that the orchestration layer deserves to be a product. The Multi-run and Session Goals features are the evidence for that bet, and they are the parts you cannot get from the CLI alone.
Maintenance, licence and what to check before you commit
OpenChamber is MIT-licensed, which is permissive and carries the usual absence of warranty; that is a statement about the licence text, not legal advice, and if you redistribute it you should read the file yourself. Maintenance signals visible in the supplied material are a steady release cadence through September 2026, with v1.23.0 titled "Finer control over code changes," v1.22.2 titled "Reliable project actions," and v1.22.1 untitled, plus an update command (openchamber update) and a self-hosting section referenced but truncated in the README. The upgrade path differs by surface: AppImage users get in-app updates only if the file sits in a writable location, which is why the README mentions it at all, and CLI users run openchamber update. The costs you should budget for are not licence fees. They are a Node.js 22+ runtime on the host, an OpenCode CLI you keep in step with OpenChamber outside the desktop build, a server process that must stay up for cross-device sessions, and token spend that scales with however many parallel runs you launch. The documentation set is broad (quickstart, install, connect-devices, private-relay, multi-run, session-goals, walkthrough, preview, github, mobile, security, troubleshooting), which is a good sign for operability and also means the answers exist and you are expected to read them rather than guess.
Editorial conclusion
Adopt OpenChamber if you already run the OpenCode CLI, want agent sessions to survive a device switch, and need goal loops or parallel model runs without building that orchestration yourself. Do not adopt it if you need a permission model you do not have to assemble, or if you cannot run Node.js 22+ on the host that serves the web UI. Before committing, verify three things in your own environment: that the OpenCode CLI version you have is the one OpenChamber expects, that Private Relay pairing works from the network your phone is actually on, and that your threat model tolerates a browser-reachable agent workspace even with --ui-password set.
Community notes