OpenCode Web — the browser console for reviewers and auditors.

What OpenCode Web is, in one line.

OpenCode Web is a read-only browser console for the OpenCode agent. It is deliberately less powerful than the CLI, because its job is review, not editing.

Every session that runs in the CLI or the desktop app emits a structured transcript — plans, tool calls, diffs, approvals, reverts — as a stream of JSON events. OpenCode Web renders that stream in real time and stores a replayable copy for audit. The browser surface never touches a working tree, never runs a shell command, and never opens a model endpoint. If a reviewer approves a patch in OpenCode Web, the approval is a signed token handed back to the CLI; the CLI is what actually writes the patch.

Why the web console is read-only.

Read-only is a design decision, not a limitation. It is how OpenCode Web can live inside a locked-down browser on a sandboxed workstation without expanding the attack surface.

Many organizations run developer work on one laptop, review on another, and audit on a third locked-down device. A reviewer laptop may have no ability to install binaries, no shell access, and no network path to the model provider — but it has a browser and it has SSO. OpenCode Web is written for that device. It loads a transcript, renders a diff view, lets the reviewer approve or reject, and returns a signed token. Nothing in that loop requires write access to the repository or access to a model endpoint.

When to use OpenCode Web versus the CLI.

Use the CLI for active editing. Use OpenCode Web for review and audit. Both surfaces share a transcript format so the same session is visible in either place.

A typical flow starts on a developer laptop: the CLI plans a patch, runs tests, and writes the diff. The developer either commits locally or queues the patch for team review. A team lead opens OpenCode Web in a browser, sees the queued patch, replays the agent transcript, and either approves the patch as-is or asks for a revision. The approval token is signed by the lead's SSO identity, the CLI picks up the token on the developer's next run, and the patch is applied to the working tree. None of that flow requires a second binary on the reviewer's device.

Audit and incident replay.

OpenCode Web is also the right surface for incident response and audit. A stored transcript is a full reconstruction of an agent session.

Security teams responding to an incident can replay a session step by step: the prompts the developer issued, the tool calls the agent made, the diffs it produced, the approvals that unlocked each step. The replay is deterministic because the transcript is what actually happened — not a reconstruction. Storage is pluggable; teams point the self-hosted image at S3, MinIO, or Azure Blob Storage. Retention and redaction policies are configured per-tenant.

SSO, SCIM, and session tokens in OpenCode Web.

OpenCode Web authenticates through SAML 2.0 and OIDC identity providers. Okta, Azure AD, Google Workspace, and in-house IdPs are supported out of the box.

SCIM 2.0 provisions groups from the identity provider so a reviewer role in Okta maps to an approval permission in OpenCode Web. Session tokens are short-lived and bound to the browser fingerprint; a stolen cookie does not survive a device change. Admins can pin maximum session length, require re-authentication before approval, and export audit logs in a structured format suitable for a SIEM. Control mappings align to NIST SSDF 1.1 and to the posture documented on the trust and safety page.

Browser support.

OpenCode Web targets current evergreen browsers. Every stable OpenCode release is tested against the current major and the prior major of Chrome, Edge, Firefox, and Safari.

Mobile and tablet browsers — Safari on iPadOS, Chrome and Samsung Internet on Android — render the approval queue and transcript replay with the same layout as desktop. Older browsers that cannot run the evergreen build fall back to a degraded read-only view with transcript text and diff rendering, but no streaming. Enterprise browsers that lock down service workers fall into the same degraded mode automatically. This posture keeps OpenCode Web accessible on locked-down devices without forcing a browser upgrade.

Self-hosting OpenCode Web.

OpenCode Web is available as a signed container image. Teams that need to keep agent transcripts inside a private network deploy the image behind their usual reverse proxy.

The image terminates SSO, reads agent transcripts from a pinned object store, and speaks the same wire protocol as the CLI. Configuration is a single TOML file with the SSO provider, the object store credentials, and the retention policy. The image is signed with the release key, published with a CycloneDX SBOM and an SLSA level 3 build attestation, and runs on any Kubernetes 1.27+ cluster. Teams running in regulated environments cite code.gov referrals and the SSDF 1.1 mapping when presenting OpenCode Web to a security architect.

Offline posture.

A self-hosted OpenCode Web instance does not need outbound internet access. It reads transcripts from the object store you already trust.

That matters for air-gapped environments, regulated data zones, and test clusters. The self-hosted image never phones home, never fetches updates automatically, and never exfiltrates session content. Updates are explicit: download the next signed image, verify its signature with cosign, and roll the deployment through your normal change window. The audit trail on the deployment side is identical to any other internal service.