OpenCode Manager: a mobile PWA that puts OpenCode agents behind a web login

The problem: OpenCode runs in a terminal, and your phone is not one

OpenCode is a command-line agent. That is fine at a desk and awkward everywhere else. If you want to check a running session, answer an agent question, or look at a diff while away from the machine, the terminal is the wrong surface. OpenCode Manager addresses that gap by putting a web interface in front of OpenCode and running the agent on a host that stays online. The README frames it as managing, controlling and coding with multiple OpenCode agents from any device: phone, tablet or desktop. The audience is therefore narrow but specific. It is for people who already use OpenCode and want remote access to the same repositories, not for people shopping for a hosted coding assistant. Nothing in the material suggests it bundles a model or an inference service. It is a control plane for an agent you supply.

Architecture: three TypeScript packages, one OpenCode server, SSE in the middle

The repository is a pnpm workspace with three packages. The backend is a Bun and Hono API server that handles Better Auth, SQLite migrations, OpenCode process management, server-sent events, schedules and push notifications. The frontend is a React and Vite single-page app using React Router, TanStack Query, Radix UI with Tailwind, a service worker and mobile-first navigation. The shared package holds Zod schemas, config helpers, types and utilities consumed by both sides. Chat updates reach the browser over SSE rather than polling, which is what makes the streaming chat view workable on a phone. The ocm CLI is a separate piece: it attaches a local OpenCode TUI to a repository hosted on the Manager through the /api/opencode-proxy endpoint, so prompts execute on the Manager filesystem against a single shared OpenCode server. That detail matters more than it looks. The agent does not run on your laptop when you use ocm. It runs where the Manager runs, and your local TUI is a remote control.

Docker in four commands, and the environment variables that decide exposure

The README quick start is short: clone the repository, copy .env.example to .env, append an AUTH_SECRET generated with openssl rand -base64 32, then run docker-compose up -d and open http://localhost:5003. On first launch the interface prompts you to create an admin account. For a preconfigured admin, the configuration section lists ADMIN_EMAIL and ADMIN_PASSWORD. Two variables govern whether the deployment is safe outside localhost. AUTH_TRUSTED_ORIGINS takes a comma-separated list such as http://localhost:5003,https://yourl33tdomain.com, and AUTH_SECURE_COOKIES should be set to true when serving over HTTPS. The README notes that OAuth, passkeys, VAPID push notifications and other options live in the Configuration Guide rather than the main file. Local development follows the workspace scripts: pnpm install, then pnpm dev, with pnpm lint, pnpm typecheck and pnpm test available. The ocm CLI supports ocm push and ocm pull to sync the working tree, using a git bundle plus working-tree patch by default, with --full for what the README calls the legacy tarball mirror.

Where it stops being the right tool

The features list is broad, and breadth is exactly where to look for friction. Repositories and Git covers multi-repo management, local discovery, SSH auth, worktrees, unified diffs, branch and commit management. Files covers a directory browser with tree view, syntax highlighting, create, rename, delete and ZIP download. Chat covers slash commands, @file mentions, Plan and Build modes and Mermaid rendering. Schedules run recurring repo jobs with reusable prompts and run history. MCP servers can be added, configured, authenticated and managed with OAuth. AI configuration covers model and provider setup, API keys, OAuth for Anthropic and GitHub Copilot, and custom agent definitions. Each of those is a surface that needs to keep working. The documentation set is a MkDocs Material site with guides, feature docs, configuration and troubleshooting, which suggests the maintainer knows the surface area is large. The practical limitation is that OpenCode Manager is not a sandbox. It manages repositories and holds provider credentials, so the trust boundary is the host and the login you configure. If you cannot terminate TLS in front of it, or you cannot keep AUTH_SECRET out of version control, the remote-access feature becomes the risk. Separately, the ocm proxy model means your local machine is not the execution environment. If your workflow depends on local toolchains, environment variables or files the Manager host does not have, prompts routed through /api/opencode-proxy will not see them. The material does not describe per-user isolation or repository-level access control, so multi-tenant use is not something the README supports.

Compared with running OpenCode over SSH or in a browser terminal

The obvious alternative is not another agent manager. It is SSH plus tmux, or a browser terminal such as ttyd, pointed at the same machine. Both give you remote access to OpenCode, and both require roughly the same network setup. The difference is what sits in the middle. A terminal session gives you a shell, which is more capable and more dangerous. OpenCode Manager gives you a scoped interface: repositories, diffs, file operations, chat sessions, schedules, notifications. The agent question prompts arrive as UI elements you can answer from a phone, and push notifications exist for session events, questions, errors and completions. A terminal multiplexer sends nothing to your lock screen. The cost of that scoping is that you can only do what the interface exposes. If you need to install a package on the host, fix a path, or inspect a process, you are back in SSH. OpenCode Manager is a better phone experience and a worse general-purpose remote shell. Choosing it means accepting that boundary.

Maintenance, releases and what MIT means here

The project is active. The most recent push and the v0.17.5 release both fall on 2026-09-09, with v0.17.2 and v0.17.1 in the preceding two weeks. The version numbering sits below 1.0, so expect configuration and API details to move between releases, and read the release notes before upgrading a deployment you depend on. The upgrade path is the Docker image plus SQLite migrations handled by the backend, which is the low-effort part. The high-effort part is the integration surface: MCP servers, OAuth providers, push notification keys and the ocm CLI all sit outside the container and can drift. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. It does not grant trademark rights, and it provides the software without warranty. That is not legal advice; check with counsel if you plan to redistribute a modified build. One more constraint worth naming: the README lists an external homepage and a separate documentation site, so the repository, the docs and the hosted app are three places to watch. Pin a release tag in your compose file rather than tracking latest, and keep the .env out of the image.

Editorial conclusion

Adopt OpenCode Manager if you already run OpenCode and want to reach the same repos from a phone without exposing a shell, and if you are comfortable putting repositories, AUTH_SECRET and agent credentials on one host. Do not adopt it if you only need a terminal-based agent loop on your laptop, or if you cannot front the container with TLS, since AUTH_SECURE_COOKIES and AUTH_TRUSTED_ORIGINS have to be set correctly for anything beyond localhost. Before committing, read docs/ocm-cli.md and the Configuration Guide, then confirm how ocm push and ocm pull handle uncommitted changes in your working tree.

Official sources

1. chriswritescode-dev/opencode-manager on GitHub
2. License: MIT
3. Project website
4. README
5. Releases