Code mode

Real terminals in split layouts, one per agent or shell.

Code mode is a grid of real PTY terminals. Each pane runs an agent CLI or a shell exactly as it would in your own terminal, so full-screen programs such as vim and htop work as usual.

Panes. Split right with Mod+D (on Linux, Ctrl+Shift+E while a terminal has focus) and down with Mod+Shift+D. Drag a pane to move it, swap two panes, or maximize one.
Launching. The launch grid lists the engines Vibezeo found. The launch sheet keeps saved presets and lineups of several agents.
Status. Each pane shows whether its agent is working, waiting for you, finished or failed. The Dashboard lists every live agent across workspaces.
Review queue. Agents that finish with changes wait in one list, across every engine, with what they touched. See Review queue below.
Worktrees. Run a task in its own git worktree, under <repo>/.tandem/worktrees/<name> on a tandem/<name> branch, then merge it back or clean it up. See Worktrees below.
Handoff. Hand a session to another engine with a written summary, in a pane beside it or as a thread.
Find work. Find work… in the command palette (Mod+K) finds work by what it's about. Describe it, such as "the login tests", and it lists open panes, threads and teammates, best first; choose one to go to it, and a pane flashes. It reads each pane's name, title, engine, folder and last 20 lines of output, each thread's title and last message, and each teammate's name, the first line of its brief and its last message, with anything that looks like a key or password removed first. It ranks them on your computer. Ranking them with Vibezeo's AI: Comes with Vibezeo accounts. It uses Vibezeo's servers and switches on when Vibezeo accounts open.
Around the terminals. A Files tab with a code editor, a git panel, a browser and a Scratchpad sit in the sidebar. Paths and URLs a program prints open with Mod+Click.
Checkpoints and more. Vibezeo saves a folder's files before agents change them, so you can rewind; it also recalls commands you ran, lists the ports your panes' servers use, runs Best of N and keeps a prompt library. See Checkpoints and workflow tools.
Restore. After a crash or relaunch, layouts come back and agents return paused, ready to resume their session.

There's no limit on live panes or workspaces; Vibezeo is free (see Accounts and limits).

Review queue

The Dashboard panel has two views: Agents and Review, the review queue. Open review queue in the command palette opens it. A terminal agent or thread that finishes with changes in its folder or worktree joins the queue within a second. For a worktree, the changes are its diff since it started, uncommitted work included. For a plain git folder, they're its diff against the last commit. An agent that finishes with no changes doesn't join. Neither does one in a folder that isn't a git repository, or one on an SSH host or in WSL.

Each item shows:

who did the work, on which engine and branch, and when;
its last words: a thread's last reply, or the last lines on a terminal's screen;
how many files changed;
what it touches.

What it touches comes from fixed rules on this computer, with no AI involved: 20 or more files, migrations, CI files, lockfiles, .env files, paths with auth, login, password, secret, crypto or permission in them, your public API paths, and deleted tests. Hover a label for the files it matched. The labels say what changed, not whether it's safe. Risk sorting puts the items that touch the most of these first; Finish time sorts oldest first.

Approve remembers exactly what you approved. If the agent changes anything after that, the item comes back marked Changed since you approved.
Open diff shows everything; Last turn shows what changed since the agent's last checkpoint.
On a worktree, Send back opens its diff with review comments, Second opinion asks another engine, and Merge opens the merge confirm with its forecast.
Snooze 1 h hides an item until the hour is up or the agent finishes again. Jump to agent opens its pane or thread.

Repository checks… sets a check command for the repository, such as pnpm test, and its public API paths. Both are kept in Vibezeo's settings on this computer, never in the repository. The check runs in the agent's folder each time an item joins, for up to 10 minutes, and shows Passed, or Failed with its exit code and the last 200 lines. Run check runs it again. The queue starts empty each time Vibezeo opens, apart from threads that had already finished.

Worktrees

New worktree… in a repository's menu in the rail (right-click it) makes a worktree from the repository's current commit; the launch sheet makes one per agent when you run several. Each worktree is listed under its repository, and its ⋯ menu has Open diff, Open in Files, Merge into…, Create pull request, Check overlap…, Ask for a second opinion…, Worktree setup… and Discard worktree…. Worktrees need a local git repository with at least one commit.

Setup for new worktrees

A new worktree has only the files git tracks: no .env, no local config, no installed dependencies. Worktree setup… describes what each new worktree of the repository gets, and saves it as .vibezeo/worktree.json in the repository, so you can commit it and share it. Vibezeo never commits it for you.

Copy into each new worktree. One pattern per line, written as in .gitignore, such as .env* or config/local.yml (a ! line excludes). Matching files are copied from your main checkout into every new worktree, however it was made. A file the worktree already has is never overwritten, symbolic links are skipped, and folders git ignores, such as node_modules, are only searched when a pattern names a path inside them. The copy stops at 2,000 files or 512 MB. On filesystems with copy-on-write, such as btrfs and XFS, files are cloned rather than copied, so even a large node_modules or a dev database file arrives almost at once and takes no extra space until one side changes; the message after the worktree is made says how many were cloned.
Setup command. Runs in a new terminal in the worktree, such as pnpm install, so you can watch it and stop it. It runs for worktrees you make with New worktree… or the launch sheet; worktrees made for Best of N, task runs and handoff get the copy only.
Teardown command. Runs in the worktree when you choose Discard worktree…, before its folder is deleted, such as docker compose down; the worktrees Best of N removes don't run it. It gets 2 minutes. If it fails or times out the worktree is still discarded, and the message says what happened.
Trust. Commands from the file run only once you've trusted them on this computer. Saving in Worktree setup… trusts them. If the file arrives or changes some other way, for example in a pull, the next new worktree shows Review worktree setup with the commands as written, and nothing runs until you choose Trust and run. Not now still gives you the worktree, with the copied files.

Ports and environment per worktree

Five worktrees running the same app would all want port 3000 and the same database. Two more fields in Worktree setup… give each worktree its own, saved in the same .vibezeo/worktree.json:

Ports per worktree. Each worktree gets a block of that many ports (1 to 100) from 41000–48999, which no other worktree on this computer has, and keeps it until you discard the worktree, across restarts too. Its terminals and agents see the first one as VIBEZEO_PORT and the block as VIBEZEO_PORTS, such as 41010-41019. If a port in the next free block is already in use when the worktree is made, it gets the following block and Vibezeo says so.
Environment. One NAME=value per line, for every terminal and agent opened in the worktree. {{slug}} (the worktree's name), {{index}} (1, 2, 3… in the repository), {{repo}}, {{port}} and {{port+1}}, {{port+2}}… are filled in, so DATABASE_URL=postgres://localhost/app_{{slug}} gives each worktree its own database. Variables that would change how shells start (such as PATH or LD_PRELOAD) or where agents sign in or send their requests (their config folders such as CLAUDE_CONFIG_DIR and XDG_CONFIG_HOME, *_BASE_URL, proxies and certificate settings) aren't allowed, and nothing here can replace what Vibezeo sets for an agent. A value that looks like a password or key gets a warning, because this file is meant to be committed.
Compose. With either field set, each worktree also gets COMPOSE_PROJECT_NAME=<repo>-<worktree>, so docker compose up in two worktrees starts two separate stacks, and the teardown's docker compose down stops the right one.
Trust. The environment is trusted together with the setup and teardown commands: until you trust them on this computer, terminals get only Vibezeo's own variables (VIBEZEO_PORT, VIBEZEO_PORTS, VIBEZEO_WORKTREE, VIBEZEO_SLUG, VIBEZEO_INDEX and COMPOSE_PROJECT_NAME). Terminals opened after you trust get the rest.
The setup command, the teardown and Best of N's check command see the same variables. A worktree's tooltip in the rail shows its ports.
The Ports tab lists a worktree's servers under its branch. Open loads them at http://<worktree>.localhost:<port> when your computer resolves names under .localhost (most current Linux systems do), so each worktree's cookies and logins stay separate; otherwise at http://localhost:<port>.

Previews per worktree

A preview runs your app's dev server in each worktree, on the worktree's own port, so you can try each agent's version without stopping one server to start another. Add a preview to .vibezeo/worktree.json (it needs Ports per worktree):

{ "ports": 10, "preview": { "command": "pnpm dev --port {{port}}", "port": 0, "path": "/" } }

command is filled in like the environment, so {{port}} is the worktree's first port. port says which port of the block the server answers on (0 is the first) and path what to open.
The preview command is trusted with the setup and teardown commands and the environment: until you trust them on this computer, it never runs, and Start preview shows the review first.
Start preview in a worktree's ⋯ menu runs it in a terminal named Preview in the worktree, where you can watch it and stop it. A new worktree with a trusted setup runs the setup and then the preview in the same terminal; with no setup, the preview starts on its own.
Once something answers on the preview's port, the worktree's row in the rail shows Preview, which opens it in a browser tab in the sidebar, at <worktree>.localhost where your computer resolves it. Vibezeo checks every 2 seconds by connecting to the port on your own computer; it sends nothing.
In Best of N's Compare, Previews starts every lane's preview and opens a browser tab for each one as it comes up.
To see two versions side by side, choose Compare previews… in a worktree's ⋯ menu (or Side by side… in Best of N's Compare) and tick the other worktree. Vibezeo starts any preview that isn't running, waits up to a minute for both to answer, then opens a new tab in the repository with two browser panes, each named after its worktree's branch.

Land worktrees

Land worktrees… in a repository's menu (or any of its worktrees' menus) merges finished worktrees into the repository's current branch, one after another, without a pull request for each. It lists the worktrees with commits the branch doesn't have, safest first: those the overlap forecast expects to merge cleanly, then those with the fewest conflicting files. Tick the ones to land, and give a Check command (your tests, for example); Vibezeo remembers the last one for the repository.

For each worktree in turn, Vibezeo:

merges the current branch into the worktree, so the check runs against everything landed before it;
runs the check in the worktree, with the worktree's ports and environment;
merges the worktree into the branch with a merge commit (--no-ff).

What lands is exactly what was checked. The queue stops, says why, and leaves the worktrees after it alone when:

a merge conflicts (it's aborted, so nothing is left half-merged);
a check fails: it shows the end of the output with Send failure to agent, which types it into the agent running in that worktree; nothing is sent until you click;
the branch moved during the landing (you switched branches or committed in the main folder);
the worktree changed during its check (a new commit, another branch, or a check that edited files);
a merge would replace a file that's on disk but not committed there, such as an ignored .env. Move it aside, then land again.

Stop kills the check that's running and stops before the next step. Quitting Vibezeo stops a landing the same way; if it quit in the middle of a merge, the next time you open Land worktrees… for that repository, Vibezeo aborts that merge and says so.

Landing never pushes or fetches. Until you push, Undo landing moves the branch back to where it was before the landing, after you confirm. It refuses once the landing has been pushed to any remote, or when the branch has commits that aren't from the landing. The worktrees keep the branch merged into them, so each keeps the changes of those landed before it.

CI results and review comments

Vibezeo can show a worktree's pull request checks and bring CI failures and review comments to its agent. It reads them through your own GitHub CLI (gh), which signs itself in: Vibezeo never sees or stores a token. It asks first: choose Check pull request in a worktree's ⋯ menu and allow it for the repository. Until you do, Vibezeo doesn't run gh for that repository; Stop checking pull requests in the same menu forgets it again.

Once allowed, a worktree with an open pull request shows its checks on its rail row: running, passed, or "1 check failed: test". Vibezeo reads them every 2 minutes while the window is focused while checks are running, every 15 minutes otherwise, and whenever you choose Refresh checks in the worktree's menu.
Click the checks to see each one. On a failed check, Send failure to agent types the check's name, link and the end of the failing job's log (for GitHub Actions jobs) into the agent running in that worktree. With no agent there, Copy failure copies it instead.
In Open diff, Import review comments adds the pull request's line comments to the review bar, on their files and lines with their authors, next to your own. Send them to the agent as one review. Comments on lines that no longer exist are left out, one import brings up to 40 comments, and importing again only adds comments you haven't imported before. Resolved threads are imported too.
CI logs and review comments are other people's text, so they reach the agent marked as data, not instructions, and only when you click.
GitLab merge requests aren't read yet: their worktrees show no checks.

Review comments to the agent

In Open diff, hover a line and choose the comment button to leave a comment on it; removed lines can be commented on too. The comments collect at the bottom of the diff, where you can edit or remove them. Send to agent types them into the agent running in that worktree's pane as one message, with each file, line and the line's text, then clears them; with several agents there, choose which one. If no agent is running there, Copy review puts the same text on the clipboard. Comments stay until you send them or quit Vibezeo.

Second opinion

Ask for a second opinion…, in a worktree's ⋯ menu and at the top of Open diff, has another engine read the worktree's changes and leave line comments. Pick the reviewer and, if it has several, the account. The sheet says whose plan the review uses. You can also say what the task was. Only Thread engines (Claude Code, Codex and ACP engines) can review, because they can run read-only; terminal-only engines are listed but can't be picked. The default is an engine that no agent in the worktree is running.

The reviewer runs as a Read only thread in the worktree, named after its branch (Second opinion: tandem/fix-auth). You can open it from the review bar while it works. Any edit it tries is denied. It gets the branch, your task and the diff, up to 150,000 characters. It runs on your own engine and account, the same as any thread, and nothing else is sent anywhere.

When it finishes, each finding on a line the diff shows becomes a comment on that line. Everything else it said, including findings on lines the diff doesn't show, goes into one General comment at the top. Nothing is dropped. Edit or remove them like your own comments, then Send to agent. One review runs per worktree at a time.

Overlap check and merge forecast

Check overlap… lists the other worktrees of the same repository that changed any of the same files, uncommitted changes included, and forecasts what merging into the repository's current branch would do: No conflicts expected, or the files that would conflict. The forecast merges in memory with your own git (version 2.38 or later), so your checkout, its branch and its files aren't touched. It covers committed work only, and says how many uncommitted changes it left out. Merge into… shows the same forecast before you confirm.

Intent radar

Git only notices two agents' changes clashing when they touch the same lines. The intent radar looks at the code itself: for each worktree, Vibezeo reads the TypeScript, Rust and Python files it changed and notes which functions, methods, classes, structs and other definitions it added, changed or removed, and which names its new lines use. It updates after each agent turn (when a checkpoint is saved) and whenever you open Check overlap…. It only reads files; nothing in the worktree changes.

Two worktrees of the same repository share a symbol when both changed it, or when one renamed, removed or changed something the other's new code uses. One agent renames Session while another adds a call to Session.refresh, for example.

Check overlap… lists the shared symbols next to the shared files, with what each side did: "renamed or removed here, used there".
A worktree that shares symbols shows Shares Session (or how many) on its rail row; click it to check the overlap.
When an agent's turn makes two worktrees share something new, a notice names both branches and the symbols. Warn both agents types a short note into each worktree's agent, naming what the other worktree did. Nothing is typed until you click.

Files in other languages, files over 512 KB, and anything past a worktree's first 300 changed files aren't checked, and Check overlap… says how many. Short names (under three letters) aren't matched.

Multi-repo workspaces

Add a folder that holds several repositories side by side, such as shop/ with api/ and web/, and Vibezeo treats them as one workspace. Its rail row says how many repositories it holds ("2 repositories"). Only repositories directly inside the folder count, and a repository's extra checkouts (its own worktrees beside it) count once. A folder with more than 12 isn't treated as multi-repo: add the repositories you work in on their own. The folder itself mustn't be inside a repository.

New worktree… and the launch sheet's worktrees work across all of them. Each worktree is a folder shop/.tandem/worktrees/<name>/ holding a worktree of every repository, all on the same branch tandem/<name>, so one agent started there can change both the API and the web app together. If one repository can't get a worktree (it has no commits yet, for example), none is made and Vibezeo says which.

Open diff shows each repository's share of the changes, then the files under each repository's name. Comments for the agent work as for any worktree.
Create pull requests asks first, then in each repository with new commits pushes the branch and opens a pull request with your own git and GitHub CLI (gh). Each pull request's description then links the others. Repositories without new commits, and GitLab ones for now, are skipped and listed.
Discard worktree… removes every repository's worktree and the folder holding them. The branches stay.

Merge into…, Land worktrees, Check overlap, pull request checks, previews, worktree setup, second opinion and the intent radar don't work for multi-repo worktrees yet; their menu entries say so.

Merge requests on GitLab

When a worktree's origin remote is on a host whose name contains gitlab, Create pull request becomes Create merge request and runs glab mr create in a terminal in the worktree; it needs the GitLab CLI (glab) installed and signed in. Other remotes use gh pr create, which needs the GitHub CLI (gh).

Not available everywhere

Worktrees aren't available in WSL folders yet. In folders on SSH hosts, worktrees don't have setup, ports and environment, previews, the overlap check or merge forecast, landing, pull request checks, the intent radar, or merge requests: Create pull request runs the host's own gh.