Vibeyard: an Electron workspace that wraps Claude Code, Codex CLI and Gemini CLI in one shell

The problem is orchestration, not code generation

Vibeyard does not contain a model. It is a desktop shell around CLIs you install separately: Claude Code, OpenAI Codex CLI, or Gemini CLI. The README states the requirement plainly ("Requires at least one supported CLI installed and authenticated"), which means the project's entire value sits in the layer above the agent. That layer is where the friction lives once you are past the demo stage. A bare terminal gives you one session per window, no persistent record of what each session cost, no way to see which of five tabs is waiting on input, and no way to hand a live session to a colleague without screen sharing your whole desktop.

Vibeyard's answer is to make the session a first-class object. Each session gets its own PTY, its own status indicator, its own cost and token counters, and its own place in a per-project dashboard. The README frames the target user as someone running agents across projects rather than someone trying an agent for the first time. If you have one repository and one agent tab, the product's main features have nothing to attach to.

The kanban board is the clearest expression of this. Cards are not just notes; the README says each card "can spawn or resume a CLI session in one click, and tasks auto-move to Done when their session completes." That couples planning state to process state, which is a different design choice from a board that merely links out to a terminal.

How the pieces fit: PTYs, profiles and a per-project dashboard

The architecture visible in the README is a multi-process host. Vibeyard is an Electron app, and each agent session runs in its own PTY, which is the same primitive a terminal emulator uses. Swarm mode is described as a grid view of all sessions at once, with `Cmd+\` to spin up a new one. Because sessions are PTYs rather than API calls, the agent's own interactive behaviour is preserved: permission prompts, streaming output, and whatever TUI the CLI ships.

The multiple Claude profiles feature is the most interesting mechanism in the repository. The README says you can run separate Claude Code logins side by side, with "each session backed by its own isolated config directory so credentials, settings, and history never mix." It also says a profile can be picked per session or set as a per-project or global default. This is an environment-variable trick at heart, not a custom auth system, and that is the right call: it means the CLIs keep managing their own credentials and Vibeyard never holds a token.

Above the PTY layer sits the project dashboard, which the README describes as drag-and-drop with widgets for AI Readiness, Kanban, Team, Sessions, Provider Tools, and live GitHub PRs and Issues. Two widgets deserve scrutiny. The AI Readiness Score is described as showing "how well-prepared your project is for AI-assisted coding, with one-click fixes," but the README does not say what it measures or what those fixes change on disk. The embedded browser tab is more concrete: open a URL such as `localhost:3000` in a session tab, toggle element inspection, click a DOM element, and the exact selector, text content and page URL are sent to the agent as context.

Installing it, and what the npm wrapper actually does

Packaging is handled through GitHub Releases for all three desktop platforms. On macOS the README points at the `.dmg`, noting it is signed and notarized by Apple. On Linux there are `.deb` and `.AppImage` builds, with the install commands given as `sudo dpkg -i vibeyard_*.deb` and, for the AppImage, `chmod +x Vibeyard-*.AppImage` followed by `./Vibeyard-*.AppImage`. On Windows there is an NSIS Setup `.exe` and a portable `.exe`.

The npm route is the one worth reading twice. The README gives `npm i -g vibeyard` followed by `vibeyard`, and states that on first run "the app is automatically downloaded and launched." So the npm package is a launcher and updater, not a bundled application. That has a practical consequence: the installed binary and the npm package can drift, and the download step needs network access the first time. It also means uninstalling the package does not necessarily remove the downloaded app.

Building from source follows the usual Electron shape: `git clone https://github.com/elirantutia/vibeyard.git`, then `cd vibeyard`, then `npm install && npm start`. The README pins the toolchain at Node v24 or later and points at `.nvmrc` for the exact version. Node 24 is a recent runtime requirement, so check your version before cloning rather than after a failed install.

Where the design gets thin: the readiness score and the desktop-only model

Two limitations stand out from the material itself. The first is the AI Readiness Score. The README promises one-click fixes but never enumerates the checks or the resulting file changes. For a tool that will modify a repository, that is the weakest-documented feature in the list, and it is the one I would exercise on a scratch branch first. An undocumented write path into a project is a different risk class from a dashboard widget.

The second is the delivery model. Vibeyard is an Electron desktop application distributed as `.dmg`, `.deb`, `.AppImage` and `.exe`. There is no documented headless mode, no server build, and no SSH story. If your agents run on a remote box, or if your team works through a browser on managed hardware, Vibeyard's session management does not reach you. The P2P sharing feature narrows that gap but does not close it: the README describes WebRTC connections with read-only or read-write modes and PIN-based authentication, which shares a session from a running desktop app rather than hosting one.

A third constraint is implicit in the provider list. The README says "More AI CLI providers coming soon," which is a statement about today's coverage: three CLIs, all of which must be installed and authenticated by you before Vibeyard is useful. There is no fallback provider and no built-in model access.

The alternative is not another IDE, it is tmux plus the CLI's own resume

The honest comparison for Vibeyard is not a competing AI editor. It is the setup most heavy CLI users already have: a terminal multiplexer such as tmux or Zellij, one window per project, one pane per session, plus the resume flag that each CLI ships. That stack is free, scriptable, works over SSH, and adds no Electron process to your machine. It also has no cost dashboard, no kanban board, and no status dots telling you which pane is blocked on a prompt.

That difference is the whole argument. tmux gives you persistence and layout; it does not give you telemetry. Vibeyard's Session Inspector, opened with `Cmd+Shift+I`, is described as real-time session telemetry with a timeline, cost breakdown, tool usage stats and context window monitoring. A multiplexer cannot produce any of that, because it does not parse what flows through the pane. Whether that telemetry is worth a desktop app depends on whether you are accountable for agent spend, which is usually a team question rather than an individual one.

The other alternative is the vendor's own interface. Anthropic, OpenAI and Google all ship first-party ways to run their agents, and those will always be the first to support new model features. Vibeyard's bet is that cross-provider session management is more valuable than tight single-vendor integration. That bet is reasonable for anyone running two or three providers at once, and it is a liability for anyone standardized on one.

Maintenance cost, release cadence and the MIT licence

The release history shows a fast cadence: v0.3.6 on 2026-08-24, v0.3.7 on 2026-08-31, and v0.3.8 on 2026-09-03. That is a patch roughly every week, and the version numbers are still in the 0.3 range, which tells you the project is pre-1.0 and treating its own interfaces as movable. For a desktop app you install and use, that is manageable. For anything you would script against, it is not yet a stable target.

The maintenance burden Vibeyard imposes is mostly external. Because it wraps three CLIs that change on their own schedules, a meaningful share of its work is chasing upstream output formats, flags and config locations. The multiple-profiles feature is the clearest example: it depends on each CLI continuing to honour a configurable config directory. If a provider changes that behaviour, the feature breaks in a way Vibeyard cannot fix on its own.

The licence is MIT, which is permissive and places few obligations on you beyond retaining the copyright notice and permission text. It also means there is no support contract, no warranty, and no contributor licence agreement shaping the project's direction. Nothing in the README suggests a commercial tier or a hosted component, so the project's continuity depends on the maintainer. I am not in a position to assess that from the repository metadata alone, and you should treat it as a question to answer yourself before making it the only place your session history lives.

Editorial conclusion

Adopt Vibeyard if you already run Claude Code, Codex CLI or Gemini CLI and your problem is orchestration rather than capability: several projects, several sessions, several logins, and no single place to see spend or state. Do not adopt it if you want a single integrated agent, or if you work on one repository with one session, where a terminal multiplexer plus the CLI's own resume flag covers the same ground with less surface area. Before installing, confirm three things: that at least one supported CLI is installed and authenticated, since Vibeyard ships no model access of its own; that your machine runs Node v24 or later if you intend to build from source; and that you are comfortable with the README's own caveat that the project is independent and not affiliated with or endorsed by Anthropic. The last item matters more than it reads: your credentials stay in CLI-managed config directories that Vibeyard points at but does not own.

Official sources

1. elirantutia/vibeyard on GitHub
2. Issues
3. License: MIT
4. README
5. Releases