Features

What MultiChamber does today. It's in active development, so this page describes the current beta work, not a finished product.

Sessions across harnesses

One session list for every harness on the project, with a harness badge on each session and search by title, harness, session ID, project or date.
Start, resume and stop sessions through whichever harness owns them.
Lazy start, idle stop. A harness starts only when you first create or resume a session that needs it, never at app launch, and stops after it has been idle for a while (10 minutes by default, adjustable in Settings). It is never stopped in the middle of a run.
Hands off what isn’t yours. MultiChamber only stops processes it started itself. If you connect it to an OpenCode server you run yourself, it doesn’t change or stop that server.

Continue in the other harness

Take a conversation from one harness to the other. MultiChamber creates a new session in the other enabled harness with an editable, size-limited draft of the transcript and file changes. You review the draft and send it yourself; the original session is left as it was. (Not yet available from sandboxed sessions.)

Models: local first, cloud by choice

Local or Remote, always visible. The selected model is labelled Local (on this device or your local network) or Remote. A configuration can mark a server Remote, but it can’t make a public address count as Local.
Only the servers you configure. MultiChamber can detect Ollama and LM Studio running on your computer and offer to add them, but nothing is added without your click. There is no silent fallback to a cloud provider.
Keys stay out of config files. The configuration names the environment variable that holds an API key, never the key itself.
Remembers your model per project and restores it when you reopen the project, if it’s still available.

Permissions you can see

The prompt area always shows the active harness’s permission posture.

Managed OpenCode asks before shell commands, access outside the project, and web fetch or search. You answer Allow once, Allow always or Reject. You can switch a session to Allow all if you want to, and set the default in Settings.
Pi has no per-call permission prompts. On Windows it uses native PowerShell with an explicit tool allowlist, no Bash or WSL needed, and MultiChamber shows the exact tool set.
An OpenCode server you connect yourself keeps its own permission settings, and the badge says so.

The Changes panel above a session transcript, listing a modified script with its diff, a modified README, an added test file and a deleted script. — The Changes panel shows what the harness changed, file by file.

Runs that keep going

In the opt-in background mode, a per-user background service keeps runs alive when you close the window. For now it’s an advanced option, turned on with an environment variable rather than in Settings. Reopen MultiChamber, reconnect to the same session, and answer any permission or question prompt that came up while you were away. Prompts wait for you; nothing is approved on your behalf. A tray icon shows the mode and offers Open and Quit.

Everyday session tools

Streaming chat with tool calls shown as they run.
File changes and diffs, when the harness reports them.
Token usage as reported by the harness. Missing numbers are left blank, not estimated.
Behavior presets (Off, Lite, Full, Ultra) for new sessions, remembered per project.
Rename, and export a session to Markdown.
The project’s current Git branch and whether it has uncommitted changes (read-only).
Keyboard shortcuts: Ctrl+N for a new session, Enter to send (Shift+Enter for a new line), Alt+Up and Alt+Down to move through the session list.

Private, pinned runtimes

The installers carry their own copies of OpenCode, Node.js and Pi, plus the fd and ripgrep helpers Pi’s optional find and grep tools use. Each is pinned to an exact version and checked by hash when the build is made. Nothing is installed globally and nothing is downloaded on first use; managed Pi runs with its offline switches on.

Before a release, the build runs automated checks on these runtimes: a dependency vulnerability scan (partial coverage for now), their published checksums and signatures, and a license allowlist. These checks are not yet a full release review.

Sandboxed sessions (preview)

You can run a new OpenCode session inside a disposable Linux container on Docker or Podman (5.0 or newer) on your own machine:

The agent works on a copy of your project: tracked files plus untracked files Git doesn’t ignore. Your real project folder and its .git folder are never mounted.
The container has no network except one path, through MultiChamber, to the model servers you configured. Model API keys stay on your machine and never enter the container. This also means package installs such as npm install don’t work inside the sandbox for now.
Changes come back as a patch that you review and then apply, save or discard.
If the container engine isn’t available, the session tells you so. It never falls back to running on your machine.

A sandboxed session's Changes panel with Apply to project, Save patch, Discard and Re-check buttons above the list of changed files and a diff. — A sandboxed session's changes wait for review before they reach your project.

Before the first sandboxed session, run Prepare in Settings → Sandbox. It downloads a pinned, hash-checked Linux runtime and builds the container images on your machine; an offline pack also works. The preview is tested with local model servers.

This is a strong guard against agent mistakes and injected instructions, not against a container or kernel escape. Anything in the project copy can still reach the model you chose. Sandboxing is off by default and is for OpenCode only for now.

Docker Desktop is free for personal use, education, non-commercial open source and small businesses; larger organizations need a paid Docker subscription. Podman is free for all use. Check the current terms before you choose an engine.

For IT: one machine-wide config file

Organizations can set defaults and lock settings with one file, %ProgramData%\MultiChamber\config.json. It uses the same format as the user’s own settings, so Group Policy, Intune or any other tool can copy it into place. The file and its folder must be writable only by SYSTEM and Administrators.

A setting in the company file replaces the user’s value and shows as locked in Settings.
If the company file is invalid or non-administrators can change it, MultiChamber refuses to load its configuration and says why.
Update checks, model servers, harnesses, permission modes and sandboxing can all be locked.

This is enforced by MultiChamber, not by Windows: a user can still run their own build, or run OpenCode or Pi outside MultiChamber.

Platform

Windows 10 or 11, x64. Built with Tauri 2 and Rust. Linux and macOS are planned after the Windows beta.