OpenCove: An Electron Canvas That Puts Claude Code and Codex Sessions Side by Side
Your infinite canvas workspace for agents, tasks, knowledge, and research. An infinite canvas for Claude Code, Codex, terminals, tasks, and notes.
At a glance
- What is it?
- OpenCove is an MIT-licensed TypeScript desktop app that arranges terminals, CLI agent sessions, tasks and notes on one infinite 2D canvas. It is alpha-stage, macOS builds are unsigned, and the CLI installer path is only as reliable as the release that published it.
- Who is it for?
- Adopt OpenCove if you already run several Claude Code or Codex sessions per day and lose track of which terminal holds which task; the spatial layout and persistent workspaces address that directly. Do not adopt it if you need signed macOS binaries, a stable CLI install path, or a tool whose worker server you can expose to a network without thinking about the password flag.
- 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 last received commits 3 days ago.
- 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
The problem: agent work disappears into chat scrollback
If you run more than one CLI coding agent at a time, the bottleneck is rarely the model. It is knowing what each session is doing. The README frames this as linear amnesia: context disappears into long chat histories, tabs and split panes force constant switching, and background agent work feels like a black box. OpenCove's answer is to stop treating a session as a row in a tab strip and treat it as a rectangle on a plane. Terminals, agent sessions, task plans and notes become nodes you place, group and colour, so the state of four parallel runs is legible in one glance rather than four clicks. The target user is explicit in the README: early adopters and power users who run Claude Code, Codex, or similar terminal-native agents daily. It is not a chat client, and it does not wrap the models. It manages the surfaces you already use.
What the canvas actually holds, and what persists
The node types are terminals, notes, tasks and agent sessions, all on one pan-and-zoom surface. Around that, the README lists multi-select, label colours and smart layouts for tidying a messy board, plus pasting images onto the canvas. Persistence is the part that matters for adoption: the documentation states that viewport, layout, terminal output and agent state are restored after a restart, so closing the app is not the same as losing your arrangement. Space archives go further and let you snapshot a workspace state and return to it, which is a different operation from persistence. Persistence keeps the current board alive; an archive lets you freeze a configuration and reopen it later, for example when a project pauses and you want the old layout back without rebuilding it. Workspace isolation is handled with directories and git worktrees, so two projects do not share a node graph. Global search spans the canvas and terminal output, and a control centre lists active sessions in one place. One caveat: the README does not describe how large a canvas or how many live terminal nodes the app handles before it degrades, so treat board size as something you find out by using it.
Installing the desktop app and the opencove CLI
Stable builds from 0.3.0 onward are published on the GitHub Releases page for macOS, Windows and Linux, with nightly prereleases alongside them. The README warns that nightlies carry newer changes and may have rough edges. On macOS, current builds are not signed or notarized with an Apple Developer ID, and the documented workaround is to run xattr -dr com.apple.quarantine /Applications/OpenCove.app if Gatekeeper blocks launch. That is a real friction point, not a cosmetic one: you are clearing a quarantine flag on an unsigned binary. There are two supported ways to get the opencove CLI. From the desktop app, open Settings, then Worker, then CLI, and click Install CLI. Without the desktop app, use a release that includes standalone runtime bundles named opencove-server-* plus a release-specific installer asset such as opencove-install-v<tag>.sh or opencove-install-v<tag>.ps1. Stable releases also publish the generic aliases opencove-install.sh and opencove-install.ps1, which always target the latest stable release. The README is candid about failure here: if releases/latest/download/opencove-install.sh returns 404, the latest stable release has not published the standalone installer yet, and you should use the desktop installer or wait. The standalone installer verifies the downloaded runtime against the release's SHA256SUMS.txt before extracting it.
Running the worker as a headless server
The worker is the component that can run without the desktop shell and host a browser-accessible canvas. After installing the CLI, the README gives this command: opencove worker start --hostname 0.0.0.0 --web-ui-password 'change-me'. According to the documentation, that prints the Web UI URL and enables password login for browser access. The README adds a direct instruction: keep the password set whenever you expose the Web UI beyond localhost. The Web UI itself is labelled experimental, and it is off by default. To turn it on in the desktop app, go to Settings, then Experimental, then Worker Web UI, enable it, optionally pin a fixed port, then start the Local Worker. By default the listener is loopback-only at 127.0.0.1. The distinction between the two paths matters. In the desktop flow the app starts the worker for you on loopback; in the server flow you choose the bind address, and 0.0.0.0 plus a weak or absent password is the configuration that turns a local canvas into something reachable from your LAN.
Building from source and what the repository assumes
The source path is conventional for a pnpm monorepo. The prerequisites are Node.js >= 22.12.0 and pnpm 9.6.0, and the README recommends installing Claude Code or Codex globally to exercise the full agent workflows. The three commands are git clone https://github.com/DeadWaveWave/opencove.git, then cd opencove, then pnpm install, then pnpm dev. Packaging and build documentation is pointed at docs/runtime/RELEASING.md rather than reproduced in the README. The language is TypeScript, the desktop shell is Electron, and the UI is React, which is consistent with the repository topics and with a canvas app that has to render many live terminal surfaces. The nightly release cadence visible in the release list, with tags like v0.3.2-nightly.20260908.1 landing the day after v0.3.2, tells you something about the project's own risk posture: changes ship to nightly users within roughly a day of a stable cut. If you build from source you are on that same fast-moving main branch, and the README does not promise that a given nightly keeps the same on-disk workspace format as the stable release before it.
Where OpenCove is the wrong tool
The README labels the project alpha and recommends it for early adopters. Take that seriously. The macOS signing gap means every fresh install needs the xattr step, and anyone distributing the app inside a managed fleet will hit Gatekeeper policy before they hit the canvas. The CLI install path has a documented failure mode where the generic installer returns 404 because the stable release did not publish it, which means scripted provisioning can break on a release-by-release basis even though the project is stable-tagged. The Web UI is explicitly experimental, so browser access is not something to build a workflow on yet. There is also a category of user this is simply wrong for. If you run one agent session at a time in one repository, the canvas adds a spatial metaphor you do not need; a terminal multiplexer plus your editor's task runner covers the same ground with less surface area. OpenCove's value scales with the number of concurrent sessions, and at one session that value is close to zero.
How it differs from tmux plus a scratch file
The obvious comparison is a terminal multiplexer such as tmux or zellij, optionally with a notes file open beside it. Both approaches keep multiple shells alive and both survive a disconnect. The difference is what the layout is anchored to. In tmux, panes are arranged in a tree of splits and windows, and the arrangement is addressed by index: session 2, window 1, pane 3. In OpenCove, nodes are placed at coordinates on a plane, so position itself carries meaning, and the README's claim is that this makes parallel work visible at a glance rather than reconstructed from indices. The second difference is state scope. A multiplexer persists processes; it does not persist a viewport, a set of notes, images pasted onto a board, or a snapshot you can archive and reopen. OpenCove's persistence and space archives target exactly that layer. The trade-off is weight: tmux is a few hundred kilobytes and available over SSH on any machine, while OpenCove is an Electron desktop app with an optional worker server, and its remote story is the experimental Web UI rather than a terminal protocol.
Maintenance cost and licence terms
OpenCove is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive position and it is the same licence family as most of the tooling this app orchestrates. It says nothing about the licences of Claude Code, Codex or other agents you point it at, and nothing about the terms of the model providers behind them; those are separate relationships you already have or do not. On maintenance, the release history shows both stable tags and dated nightlies, which means the project expects users to choose a channel. The practical cost of staying on stable is waiting for fixes; the practical cost of staying on nightly is that the README itself warns of rough edges, and the desktop app, the worker and the CLI all ship from the same release train, so a version mismatch between a desktop install and a separately installed CLI is a configuration you have to keep aligned yourself. The README notes that managed SSH runtimes are kept aligned with desktop updates in 0.3.2, which is a hint that this alignment is an active maintenance concern rather than a solved one.
Editorial conclusion
Adopt OpenCove if you already run several Claude Code or Codex sessions per day and lose track of which terminal holds which task; the spatial layout and persistent workspaces address that directly. Do not adopt it if you need signed macOS binaries, a stable CLI install path, or a tool whose worker server you can expose to a network without thinking about the password flag. Before committing, verify three things against the release you download: that the tag ships opencove-server-* bundles and a versioned opencove-install-v<tag>.sh asset, that the Web UI defaults to 127.0.0.1 unless you pass --hostname and --web-ui-password, and that you are comfortable running the xattr quarantine command on /Applications/OpenCove.app.
Community notes