OpenChamber wraps the OpenCode CLI in a review workspace for five surfaces

Multi-run gives one task to five models in separate worktrees

Multi-run hands the same task to up to five models, each in its own session and optionally its own worktree, so parallel attempts cannot overwrite one another in the same directory. You read the five results, pick one, or use Fusion to fold the strongest parts into a new session. Cost matters here too, because the cross project view already lists approvals, provider limits, token use, and costs, and five concurrent models means five concurrent bills. Read the mode as a way to widen your options, not as a way to have a tool pick for you.

The isolation is the part worth leaning on. When each run has its own worktree, a model that rewrites package manifests or a migration file does not strand the other four, and Fusion combines the strongest parts into a new session.

Session Goals run on a stop condition, not on a judgement

Session Goals give a session a finish line. After every turn the workspace checks the result and keeps the agent working until the goal is complete, until the agent is blocked, or until the limit you set is reached, and the run can continue after you close the app. Scheduled tasks can carry the same goal, so a prompt set to run once, daily, weekly, or on a cron schedule aims at an outcome rather than stopping after one response.

Completion means whatever your goal statement describes, and the other two endings are a stall and a cap. A goal phrased as something a test can confirm behaves very differently from one phrased as an outcome you will judge by reading a diff..

Preview sends the agent an element instead of a paragraph

Preview turns pointing into instructions. You point at an element and the agent receives that element's screenshot, styles, position, and browser errors, which removes the old routine of describing a target in prose and hoping the description lands. The desktop build does the same for any web page in its built in browser, not only your own dev server.

What comes back is still an agent edit. If your feedback reaches the agent through pull request comments instead, that is the separate GitHub path, where a session starts from an issue or pull request with its context attached and failed checks or review comments travel back to the agent.

Desktop bundles its OpenCode, web and VS Code do not

The install paths are not interchangeable. The desktop build bundles the matching OpenCode CLI, so no separate OpenCode installation is required, while CLI, Web, and VS Code use the OpenCode CLI you already have and the CLI needs Node.js 24.14 or newer. That split has a direct consequence: two machines can open the same project and run different OpenCode versions, so a session that behaves one way on desktop may behave another way in a browser tab.

The container is explicit about the version it pins, which is the clearest statement of the split in the repository:

RUN npm install -g @opencode/[email protected]

Linux users get x86_64 and ARM64 AppImages, and the build itself follows the versions in the monorepo manifest, [email protected] as the package manager and node >=24.14.0 in engines. For the AppImage route, make the file executable and keep it somewhere writable:

chmod +x OpenChamber-*.AppImage
./OpenChamber-*.AppImage

Docker refuses to boot until you set OPENCHAMBER_UI_PASSWORD

The compose file will not start without a UI password. The environment block uses a shell guard that aborts the run on an unset value, which matters because Docker binds OpenChamber to 0.0.0.0 for port mapping and the comment above the line says UI auth is required for that reason. The guard is deliberately loud:

      OPENCHAMBER_UI_PASSWORD: ${OPENCHAMBER_UI_PASSWORD:?Set OPENCHAMBER_UI_PASSWORD before exposing OpenChamber through Docker}

The suggested pattern sets the value before startup:

OPENCHAMBER_UI_PASSWORD="$(openssl rand -base64 24)" docker compose up -d

Volumes map the OpenChamber config, three OpenCode paths for share, state, and config, an SSH directory, and the workspaces directory into the container, and the image replaces the base bun user with an openchamber user at UID 1000 so mounted paths line up. Host files owned by a different UID surface as permission errors inside the container.

The CLI stays on localhost until you ask for --lan

Remote access is opt in. The CLI binds to localhost by default, and the guidance is to use --lan only on a trusted network and to protect browser access with --ui-password. The install example passes that password on the command line, so it lands in shell history and in process listings on the machine that ran it. The repository root also carries a Caddyfile.

Private Relay is the path that opens no ports at all: pair a device with a one time QR code, get an end to end encrypted connection, and revoke it whenever you want. Direct connections, LAN and VPN access, Cloudflare and Ngrok tunnels, and SSH are listed as the other routes, and the compose comments name the tunnel modes as quick, managed remote, and managed local, where the managed remote mode also requires a hostname and a token. The daily operations surface is small enough to read in full:

openchamber status
openchamber connect-url --qr
openchamber tunnel start --provider cloudflare --mode quick --qr
openchamber startup enable
openchamber logs
openchamber stop
openchamber update

Walkthroughs and GitHub context move review, they do not verify it

Changes Walkthrough groups related edits into steps, puts them in the order the change makes sense, and explains how the pieces fit, so a large diff becomes something you can walk through instead of scroll. The GitHub path starts a session from an issue or pull request with its context attached, sends failed checks or review comments back to the agent, and lets you update or merge the pull request from OpenChamber.

Neither path changes who signs off. A readable walkthrough is a map of the change, not evidence the change is right. If your team merges on human approval, the review surface is a real gain.

Three releases in four days, and no stated upgrade path

The release cadence is the maintenance answer. v2.5.3 landed on 2026-10-28 and v2.6.0 on 2026-11-02, alongside a canary build, and the most recent push to the default branch is dated 2026-11-02. The monorepo manifest sits at the same 2.6.0 version.

That speed cuts both ways. If you are moving an established setup onto v2, pin the version first and read the changelog before you let a scheduled task or a paired phone drive it.

Editorial conclusion

OpenChamber suits developers who already run OpenCode and want the review surface, remote access, and scheduling gathered in one place. Skip it if you were expecting a bundled coding model, because the agent comes from a separate OpenCode install, and check the OpenCode version on each surface before you trust a review to match between desktop and web.

Frequently asked questions

Official sources

1. License: MIT
2. openchamber/openchamber on GitHub
3. Project website
4. README
5. Releases