Engines and platforms

The coding agent CLIs Vibezeo runs, their instructions files, and the platforms it runs on.

Engines

Vibezeo detects these coding agent CLIs on your login shell's PATH and shows how to install the missing ones. Each runs on your own subscription and signs in by itself. This table is generated from the app's engine registry.

Antigravity CLI runs in terminal panes only, as Google ships it. Kiro CLI runs in terminal panes and, through its Agent Client Protocol mode, in Thread mode. Kiro CLI can have several accounts, each in its own home; Antigravity CLI keeps one account per computer, because it stores its sign-in in the system keyring. Gemini CLI is still listed: Google serves it to paid API keys and Gemini Code Assist Standard or Enterprise, and personal Google accounts use Antigravity CLI.

Any ACP agent in Thread mode

Agents that speak the Agent Client Protocol (ACP) can run threads. Cursor Agent, Gemini CLI, Grok, Kiro CLI and OpenCode do out of the box. Gemini CLI runs as gemini --acp, or gemini --experimental-acp on older releases. To add another, open Settings › Engines › ACP agents and choose Add an ACP agent…:

• Name, Command (a command on your PATH, or its full path), Arguments and Environment variables. Goose fills in goose acp.
• Test starts the command, asks it to introduce itself, waits up to 10 seconds and stops it. You see its name, version and how it signs in. If it doesn't answer as an ACP agent, it says "Not an ACP agent" and why, and nothing is saved. Add runs the same test before saving.
• The agent then appears in the Thread engine picker as "via ACP". Threads run the command at the path saved when you added it, never another program of the same name. Agents you add run on this computer only, not in SSH or WSL folders, and only in Thread mode.
• Remove stops the agent's threads. They stay readable but won't run again: an agent you add later, even with the same name, is a new engine.
• The agent signs in its own way. Vibezeo never sees or keeps its keys: a variable whose value looks like a key or token is refused, and so are variables that change which home an engine uses or what a program loads. When it asks for a sign-in, the thread names the methods it offers: sign in with the agent's own command in a terminal, then try again.

Vibezeo shows what each agent reports over ACP: messages, tool calls, approvals and models. Usage and status beyond that depend on the agent. When an agent asks for approval without offering a one-time allow, Allow once declines the request rather than allowing it for good.

One instructions file for every engine

Each engine reads its own instructions file, so a repository's rules can drift apart or reach only one engine. Instructions… in a local folder's menu in the rail shows which file each installed engine reads, whether git tracks or ignores each file, and how each one differs from AGENTS.md.

Checked against each vendor's documentation on 15 October 2026. Any other engine shows as Unknown, and Vibezeo writes nothing for it.

Use one file for all makes AGENTS.md the source. If there's no AGENTS.md, you pick the file it starts from. Each engine that needs one then gets a one-line file holding @AGENTS.md: CLAUDE.md for Claude Code, and GEMINI.md for Gemini CLI. Engines that read AGENTS.md themselves get nothing.

• You see every file it would create or replace before anything is written. A file whose text isn't already in AGENTS.md is marked.
• A copy of each replaced file is kept on this computer, and Undo puts every file back as it was.
• Vibezeo never commits these files and never edits .gitignore.
• Symbolic links, files over 1 MB and anything outside the folder are listed, and never read or written.

A personal file that git ignores, such as CLAUDE.local.md, doesn't reach new worktrees on its own. The panel marks it Not in new worktrees, and Copy into worktrees adds it to the folder's worktree setup (.vibezeo/worktree.json). That changes only the list of copied files; any setup commands keep the trust they had.

Versions and updates

Settings › Engines shows each installed engine's version and how it was installed: npm, Homebrew, its own installer, or another way. Vibezeo works this out from where the engine's command leads on disk. Claude Code updates itself when it was installed with npm or its own installer, and its row says Updates itself.

• Check for updates in an engine's details asks npm for the newest version, only when you click it, and only for an engine installed with npm. Vibezeo never checks in the background. For other install methods it shows the command that updates the engine.
• Pin this version starts new panes of the engine with the engine's own documented switch: DISABLE_AUTOUPDATER=1 for Claude Code, and -c check_for_update_on_startup=false for Codex. Panes that are already open don't change. Engines without a documented switch don't offer Pin.
• Vibezeo remembers the versions it has seen and the last one that finished a Thread turn without an error. If an engine updates and Thread turns on this computer then fail because the engine itself broke (it won't start, or it crashes mid-turn; not an error it reports, such as being offline or signed out), the Engines page and the thread say so, for example "Codex updated from 1.2.0 to 1.3.0, and threads have failed since."
• Roll back to 1.2.0… shows the command that installs that version the same way, such as npm install -g @openai/codex@1.2.0, before anything runs. You can run it in a terminal pane on this computer you can watch, or copy it. Homebrew installs and other methods don't offer a rollback.

Running in the background lists your own processes of an installed engine that have no terminal and weren't started by Vibezeo, such as a daemon left behind. It shows the engine's name, and its subcommand when it's a known one, never the rest of its command line. A process in a terminal, Vibezeo's or yours, and other users' processes are never listed. Stop asks first, then asks the process to end, if it's still the same process. This list is available on macOS and Linux.

Platforms

Generated from the release on the download page.

Sandbox agent panes (Linux)

Settings › Engines › Sandbox agent panes › Workspace runs each new agent pane's engine in a sandbox, whichever engine it is:

• It writes only to the pane's folder, its repository's git data (so commits work), the engine's own home in Vibezeo and /tmp. Everything else on the computer is read-only.
• It can't read the files in ~/.ssh, ~/.aws, ~/.gnupg, ~/.config/gh, ~/.docker, ~/.kube, ~/.netrc or ~/.local/share/keyrings, Vibezeo's own data (its database of every project's threads, your other engine accounts, your teammates) or the repository's other worktrees: those folders read as empty.
• Git's hooks folder and .git/config stay read-only, so an agent can't plant a hook that runs later outside the sandbox. That's the repository's .git/hooks (for a worktree too, whose hooks live in the main checkout's .git), even when it doesn't exist yet, and the folder core.hooksPath names.
• It keeps the network, which engines need to reach their models.

What it doesn't cover:

• Programs already running for you that answer over a socket: a running ssh-agent or gpg-agent, and your desktop keyring while it's unlocked. An agent can't read your key files, but it can ask these to use them, as any program you run can.
• Scripts a hook calls from elsewhere in the folder, as some hook managers do: they're ordinary files in the folder, so an agent can change them, and the change shows in your diff.

The engine signs in by itself as always; the sandbox only narrows what it can reach, and Vibezeo never reads the engine's credentials. A pane that runs sandboxed shows Sandboxed in its header. A write the sandbox refuses reaches the engine as a "Read-only file system" error.

It uses bubblewrap (the bwrap command), which Vibezeo never installs: install it with your package manager (sudo apt install bubblewrap, sudo dnf install bubblewrap). Without it, or where it can't run, the setting says why and Workspace can't be chosen. If it stops working after you turned it on, agent panes start without it: their header says Not sandboxed with the reason, and you get one notification.

Claude Code, Codex and OpenCode run sandboxed. Engines that keep their sign-in in your own home folder (Cursor Agent, Gemini CLI, Copilot CLI and the rest) start outside the sandbox for now, with Not sandboxed saying why: inside it, your home is read-only, so their sign-in would fail. The pane's shell stays outside the sandbox. Panes on SSH hosts and in WSL aren't sandboxed, and macOS and Windows don't have it yet.

Resource governor (Linux)

The Ports tab's Panes section lists each pane running on this computer with its CPU ("CPU 120%" is 1.2 cores busy) and memory, grouped by worktree like the ports. Each agent's Dashboard card shows the same. They refresh every 2 seconds while you're looking, and never while hidden.

• Freeze (in the pane's menu, or its row) stops every process in the pane, so it uses no CPU; Thaw picks up where it left off. A frozen pane shows Frozen in its header.
• Settings › Engines › Memory cap per agent (Off, 512 MB up to 16 GB) caps each new agent pane. When a process in it goes over, the system ends that process; the pane and its shell keep running, and its header says Stopped: memory cap 512 MB. With systemd older than 253, the whole pane ends instead. Caps need a systemd user session (most Linux desktops have one); without one the setting says why and stays Off. Each agent pane then runs in its own systemd user scope, vibezeo-pane-….
• Settings › Engines › One check at a time runs check commands (Best of N's Run check, the review queue's checks and the check Land worktrees runs) one after another instead of all at once. A lane waiting its turn shows Queued.

On macOS and Windows you get the usage; Freeze and the memory cap are Linux only for now. Nothing here leaves your computer or is saved to disk.