OpenYak: A Local Desktop Workspace for Codex and Claude Code
One chat. Every agent. A universal interface for AI agents running on your computer.
At a glance
- What is it?
- OpenYak puts Codex and Claude Code inside an Electron workbench with file tabs, a shared Playwright browser, and a Rust core that keeps transcripts in local SQLite. It is alpha software on main, and the README is unusually frank about what is not finished.
- Who is it for?
- Adopt OpenYak if you already hold a Codex or Claude Code sign-in and want transcripts, file tabs and a shared browser in one desktop window instead of a terminal scrollback. Do not adopt it if you need packaged installers, validated Linux or Windows GUI builds, or a complete orchestration view of subagents; the README lists all three as unfinished, and the project is v2 alpha on main with v1 preserved on legacy/v1.
- Can I use it commercially?
- Yes. Apache-2.0 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 11 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 terminal scrollback problem OpenYak is aimed at
Coding agents produce more than text. They emit file references, structured artifacts, subagent reports and browser actions, and a terminal renders all of it as a stream you scroll back through. OpenYak's premise, stated in its README as "Your agents. Your conversation. One desktop workspace," is that the conversation should sit beside the things it produces rather than above them. The target user is someone who already runs Codex or Claude Code and has a working sign-in, but wants persistent file tabs, a rendered Markdown or HTML view, and a browser window the agent can also drive. It is not a hosted service and it does not supply model access. The README is explicit: "OpenYak does not supply model access." You bring your own authentication, and the app wraps the runtime you already pay for. That framing also sets the ceiling. If your work is a single script edit followed by a commit, a terminal is faster to start and has no Electron process to manage.
Two runtimes, two transports, and what ACP costs you
The provider table in the README lists Codex with a native App Server over stdio as the default integration and a Codex ACP adapter as an optional compatibility path. Claude Code is driven by the Claude Agent SDK over its CLI, again with a Claude ACP adapter as the alternative. Native runtimes are the default; ACP is opt-in through the environment variable OPENYAK_AGENT_TRANSPORT=acp. The README attaches a concrete penalty to that switch: native host integrations such as the shared browser are not automatically available on the ACP path. So the compatibility route is not a free fallback. It buys you a transport you may already have tooling for and costs you the browser panel and anything else wired into the native host. The README also notes that OpenYak "does not reproduce every private feature of Codex Desktop or Claude Desktop," which matters if you are switching from one of those and expecting parity. Model availability, usage limits and provider features depend on your account and installed runtime versions, so the surface you get is partly determined by software outside this repository.
How the Electron app and Rust core divide the work
The repository layout is two directories with a clear split. app/ holds the Electron and React layer: chat, the file workbench, native workers and host integrations. core/ is Rust with SQLite, owning projects, tasks, transcripts and normalized runtime events. The normalization step is the load-bearing part. According to the README, "the runtime boundary normalizes supported structured artifact and file outputs; the frontend does not need to guess tool names or turn arbitrary code blocks into artifacts." That is a deliberate refusal to pattern-match on tool names in the UI, which is the usual way these wrappers break when a provider renames something. Ordinary file references travel a separate path from structured artifacts, so opening a referenced file is not the same code path as rendering a report. Projects, tasks and transcripts stay in local SQLite. The README qualifies what local means: "OpenYak stores its conversation data locally. That does not mean offline inference: provider requests and browser navigation can use the network." Nothing here claims your prompts stay on the machine.
Getting it running, and the two environment variables that matter
Prerequisites are Node 26 and Rust 1.90, with mise install available to install the pinned toolchains, plus an existing Codex or Claude Code sign-in. Google Chrome is required for the shared browser. The README gives this sequence: git clone https://github.com/openyak/openyak.git, then cd openyak, npm install, npm run dev. That last command builds the Rust core and launches Electron with hot reload. Agent dependencies are pinned in the app while authentication stays yours. Two variables select local CLI binaries: OPENYAK_CODEX_BIN and OPENYAK_CLAUDE_BIN, documented in docs/native-agent-runtime.md. A third, OPENYAK_DATA_DIR, points at a new empty directory if you want an isolated test instance rather than your real transcript store. For contributors, npm run check and npm run build are the verification pair, and the v2 CI workflow is described as checking runtime contracts, production builds and real desktop and browser regressions without paid model calls. Documentation-only changes skip the heavy checks, which is a sensible cost decision for a project whose CI otherwise exercises a browser.
The shared browser is a remote view, not an embedded Chrome
The shared-browser panel uses Playwright MCP against a dedicated Chrome session, so the agent and the user operate the same page rather than two copies. Taking control blocks new agent browser actions and waits for in-flight work; resuming returns browser access without sending another chat prompt. That last detail is the interesting design choice. Control handoff is a state change, not a message in the conversation, which keeps the transcript free of coordination noise. The README is careful about what the panel is: it uses lossless HiDPI frames and is "a shared remote view, not an embedded native browser or a promise of 60 fps." Anyone expecting to interact with a local browser at native latency should read that sentence twice. The README also states that the pictured flow was exercised through Codex in the real GUI, and that Claude integration exists but the browser screenshots validate Codex, not a Claude browser acceptance run. External computer-use tools and native desktop control are separate capabilities, and the screenshot does not certify them.
Alpha boundaries you should read before cloning
The README carries an explicit alpha boundaries list, and it is longer than most projects volunteer. Packaged installers are still work in progress, so there is no download-and-run artefact described here; you build from source. Broader agent support is unfinished, meaning the two providers in the table are the supported set. Linux and Windows GUI validation are also incomplete, which makes macOS the only platform the documentation implies has been exercised. Runtime-reported subagents are not a complete workflow-orchestration UI, so if you want to supervise a tree of agents you are looking at a status feed, not a control plane. Private Desktop-only tools and full computer-use parity are not guaranteed. The status badge reads v2 alpha, the current branch is main, and the original v1 is preserved on legacy/v1 and in the v1.5.0 release. A project that keeps its predecessor branch alive and labels the current one alpha is telling you something about the upgrade path: expect to rebuild from source rather than update in place.
Where a plain terminal or Aider fits better
The honest alternative for many readers is the terminal you already have. Codex and Claude Code both run as CLIs, and if your workflow is edit, run tests, commit, then OpenYak adds an Electron process, a Rust core and a SQLite store between you and the same agent loop. Aider takes a different approach again: it is a terminal pair-programming tool that edits files in your working tree and leans on git commits as its review mechanism. The difference is not cosmetic. OpenYak keeps a persistent local transcript and a file workbench, and it can hand the same browser page back and forth with the agent. Aider keeps the conversation in the terminal and the history in git. If your review process is already git diff, Aider's model matches it and OpenYak's file tabs duplicate it. If your work involves reading generated reports, previewing sandboxed HTML or watching an agent navigate a page, the terminal gives you nothing comparable.
Licence, maintenance and what to check first
OpenYak is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive licence, and it is worth noting that the README does not describe any separate terms for the hosted homepage at open-yak.com or for provider credentials, which remain governed by your agreements with those providers. Nothing here is legal advice; read LICENSE and your provider terms yourself. Maintenance cost is dominated by the toolchain, not the licence. Node 26 and Rust 1.90 are pinned, mise install manages them, and npm run dev rebuilds the Rust core, so a contributor machine needs both toolchains current. Because the project is alpha on main with installers unfinished, upgrades are source pulls rather than application updates, and v1 lives on a separate branch rather than in an in-app migration path. The release cadence visible in the supplied material runs from v1.4.0 in late July 2026 through two v1.5.0 release candidates in early August, with the repository's last push in early September. Before committing, run npm run check and npm run build on your own machine, set OPENYAK_DATA_DIR to an empty directory for a first session, and confirm that your Codex or Claude Code sign-in works through the native transport before you try OPENYAK_AGENT_TRANSPORT=acp and lose the browser panel.
Editorial conclusion
Adopt OpenYak if you already hold a Codex or Claude Code sign-in and want transcripts, file tabs and a shared browser in one desktop window instead of a terminal scrollback. Do not adopt it if you need packaged installers, validated Linux or Windows GUI builds, or a complete orchestration view of subagents; the README lists all three as unfinished, and the project is v2 alpha on main with v1 preserved on legacy/v1. Verify first that Node 26 and Rust 1.90 are available to you, that npm run dev builds the Rust core and launches Electron on your machine, and that your existing provider authentication works through the native App Server or Agent SDK path before you invest in the ACP compatibility route.
Community notes