Building OpenVibe: an open-source desktop workbench for coding agents

When a coding agent changes a repository, I want its work to remain inspectable: which context it used, which tools it called, which files changed, which commands ran, and how to recover if the result is wrong.

That is the workflow behind OpenVibe, an open-source desktop environment for working with coding agents.

The screenshot uses a reproducible demo run inside the real OpenVibe workbench. The chat timeline, plan, tool calls, and running state are rendered by the same components used for live sessions._

What OpenVibe does

OpenVibe puts the agent and the rest of the development workspace in one application. A project has its own chats, editor state, terminals, Git state, and agent context. The model can inspect the repository, build a plan, edit files, run commands, use Git, search the web, work through MCP servers, and control an isolated browser.

The user can follow those actions in a single timeline instead of reconstructing them from several windows and logs.

The desktop application includes:

• a streaming agent chat with tool calls, todo state, token statistics, and context compaction;
• Monaco Editor with file tabs, code viewing, and diffs;
• snapshots and rollback for changes made during an agent run;
• Git status, branches, history, diffs, commits, and a commit graph;
• native PTY terminals and Language Server Protocol integration;
• built-in filesystem, shell, search, Git, web, browser, research, and todo tools;
• local MCP servers discovered at runtime;
• an isolated Chromium session controlled through the Chrome DevTools Protocol.

OpenVibe does not require a specific model vendor. It includes provider templates and an updateable model catalog, but it also accepts custom OpenAI-compatible endpoints and local runtimes such as Ollama, LM Studio, and vLLM.

The application itself runs locally. If a cloud model is selected, model requests still go to that provider; choosing a local runtime keeps inference local as well.

What happens after a prompt is sent

A typical run is a loop rather than a single completion:

1. OpenVibe builds the request from the conversation, explicit @file references, attachments, project structure, and the currently enabled tools.
2. The model response arrives through an incremental SSE pipeline. Text, provider-supported reasoning, tool arguments, usage, and cache statistics are represented as structured events.
3. A requested tool is checked against its schema, workspace scope, and permission mode before execution.
4. Tool results are appended to the run and returned to the model for the next step.
5. File changes receive before-and-after snapshots, so the user can inspect a diff, accept the result, reject it, or restore the previous state.
6. Long conversations are compacted while retaining the original task, recent work, tool state, and relevant file snapshots.

In the interface, that can look like:

read_file
  -> search_codebase
  -> update_todo
  -> edit_file
  -> run tests
  -> inspect git diff
  -> summarize the result

The exact sequence is model-driven, but the execution remains visible and interruptible.

The application boundary

OpenVibe is built with Tauri 2, Rust, React, TypeScript, and Monaco. The codebase is divided into three runtime areas:

React / TypeScript workbench
        | typed commands and events
        v
Tauri desktop host
        | service contracts
        v
Rust services
        |-- agent and LLM streaming
        |-- tools and filesystem policy
        |-- Git, search, LSP, terminal, and MCP
        |-- SQLite chat and project storage
        `-- isolated Chromium / CDP

The renderer is responsible for presentation and short-lived UI state. It does not receive unrestricted shell or filesystem access. The Tauri host exposes narrow commands and owns long-lived managers, while specialized Rust crates handle the actual capabilities.

The Rust workspace currently contains 16 crates. A few important boundaries are:

• agent-api defines shared messages, events, snapshots, tools, and executor contracts;
• llm handles provider requests, streaming, cancellation, and token accounting;
• agent owns orchestration, compaction, rollback, snapshots, and tool profiles;
• agent-tool implements the tools available to an agent;
• browser owns Chromium installation, sessions, CDP, navigation, input, snapshots, and screencasting;
• capability-specific crates handle Git, files, search, LSP, MCP, terminals, chats, configuration, and the editor.

This separation is partly architectural and partly a security boundary. Model output, tool arguments, MCP responses, file names, and web content are treated as untrusted input. Path checks, navigation policy, timeouts, result limits, and permissions are enforced by the service that owns the capability rather than by the chat UI.

The browser is a tool, not an iframe

Browser work often becomes awkward in coding-agent workflows. The agent may need a rendered page, accessibility information, authentication performed by the user, or visual confirmation that a local interface works.

OpenVibe starts a separate Chromium process and communicates with it over CDP. The browser panel provides an address bar, navigation, multiple tabs, live frames, and a visible agent pointer. Browser tools can navigate, take accessibility snapshots and screenshots, click, type, hover, scroll, and wait for page state.

The user can take manual control when private input is needed and then return control to the agent. Privileged and local URL schemes are rejected at the native boundary before Chromium receives the navigation request.

Recoverability matters more than autonomy

An agent that can edit files and start processes is useful only when its state is understandable.

OpenVibe keeps permission modes explicit, separates read and write capabilities, displays the actual command and working directory, and records successful file edits as snapshots. The todo tool is persistent, so a multi-step run can show what is pending, active, completed, or blocked without relying on a paragraph of generated status text.

The goal is not to hide the work behind an animation. It is to make each step reviewable without forcing the user to supervise every token.

Current status

OpenVibe 1.3.9 is the latest release. It includes a rebuilt workbench architecture, a reorganized Rust backend, the isolated browser runtime, new project and chat navigation, and a more resilient LLM event pipeline.

The project is licensed under GPL-3.0 and has desktop builds for Windows, macOS, and Linux.

To run it from source:

git clone https://github.com/nihmadev/OpenVibe.git
cd OpenVibe
npm install
npm run dev

The repository contains more detail about the architecture, design principles, and security model.

Feedback

OpenVibe is still a young project, and this is a good point to challenge its assumptions. I am especially interested in feedback from people who already use coding agents on real repositories:

• Which agent actions do you want to inspect every time?
• Where should the boundary between automatic execution and approval sit?
• Which provider, MCP, browser, or repository workflows should be tested next?

The code and releases are available on GitHub. Issues, architecture questions, and pull requests are welcome.