NeuroSquad blog

Nineteen agent CLIs, one depth of integration

Sat, 26 Sep 2026 14:31:27 GMT

NeuroSquad 0.1.137 adds nine agent CLIs — Gemini CLI, GitHub Copilot CLI, Amp, Factory Droid, aider, Goose, Kimi Code, Cline and Auggie — and brings Cursor CLI and Crush up to the same level as everyone else. That makes nineteen, and for the first time “supported” means the same thing for all of them.

Three days ago it did not. The first release ran ten CLIs in cards, but only Claude Code was integrated deeply: its statuses came from its own hooks, its session resumed after a restart, it got tools over arrows. The others ran in a terminal and were mostly watched by a heuristic. This post is about closing that gap, in three releases within a day.

Which CLIs had the full integration, release by release. Move through the steps. Live replica — try it

What “the same depth” means

We wrote down everything the app does for Claude Code as a checklist of about forty capabilities, and every CLI gets its own document that goes through that list row by row. Each row is one of three things: native (the CLI has it and the app uses it), emulated (built from another mechanism of that CLI, and how), or impossible — with the proof, usually a line of the CLI’s own source.

The rows that matter most to someone using the canvas:

Session resume: restart the app or the card, and the agent continues the same conversation.
Precise statuses: working, needs you, finished — from the CLI’s own events, with the text of what it is asking.
Tools over arrows: the app’s MCP tools, plus connected MCP servers and skills.
Canvas mode: the agent works through cards (a terminal for commands, a browser for the web) instead of its own built-in tools, and that holds even in dangerous mode.
Safe interruption by the budget brake, without losing the session.
Usage and model per card, the context meter and compaction, auto-continue after a rate limit.

Every CLI needs a different way in

The checklist is the same; the mechanism almost never is. For Claude Code, the app passes a settings file on top of yours, and its hooks report every state change with one curl line. Here is how some of the others got there.

OpenCode gets a plugin — one file for all cards — that reports its session status and permission requests. Its config goes through one environment variable, chosen by elimination: the variable for inline JSON was already carrying OpenRouter attribution headers, and two writers of one variable overwrite each other; the variable for a config directory would have hidden your global instructions file. Interrupting it needed care too: Ctrl+C in OpenCode with an empty input closes the app, and the budget brake used to send exactly that. It now presses Escape twice.

Hermes Agent reads an administrator-level config layer, which the app points at a file of its own per card, merged over yours leaf by leaf. A live test found that its interactive mode connects MCP servers only if they are in your raw config — so the card types /reload-mcp itself once the prompt is ready, and the first prompt waits for “Agent updated” before it is inserted. Another finding: when the model provider fails, Hermes never sends its end-of-session event, and the card sat on “working” forever; while a turn is open, the app now also watches the terminal for the provider errors Hermes prints.

Gemini CLI has a system settings path, like its fork Qwen Code, but it only loads that file if it is owned by the administrators and not writable by users. A file in the app’s folder is skipped with a security warning. What Gemini does honour is a home folder override, so every Gemini card runs with a home of its own, holding its settings layer — and everything else from your real ~/.gemini, sessions and login included, linked in with junctions. A card’s session is your session: gemini --resume works from a plain terminal and back.

aider has no MCP client, no hooks and no plugin API. It is a Python program, though, and Python imports a sitecustomize module from the path before anything else. An aider card starts with one folder first on PYTHONPATH whose module patches six aider modules as they load — each patch guarded, so if a later aider renames a method only that one feature switches off — and then removes its own variables, so nothing aider starts inherits them.

Kilo Code by default attaches to a running Kilo daemon instead of starting its own worker, and the daemon has its own environment — so a card would silently lose its config, its tools and its MCP token. Every Kilo card now starts with the switch that turns attaching off. Codex CLI used to survive stopping its card: the npm shim died and codex.exe lived on. The card now starts the real executable directly.

Pick the CLI, the provider and the model when you create an agent. Installed CLIs are found on this computer’s current PATH.

“Impossible” is an answer too

Some rows cannot be filled, and saying so is part of the work. Several CLIs — Auggie, Droid, Goose, Kimi — do not let the caller choose a session id; the app captures the id they mint and resumes by it instead. Auggie has no compact command, because it summarizes history on its own when the window fills; its card simply has no Compact button. Cline reads a server’s tool list once, when its session starts, and nothing refreshes it — so an arrow drawn mid-session takes effect at the next start, and the docs say so.

Kimi Code has the same limitation, and there it is emulated: a Kimi card is offered every built-in tool group from the start, and the arrows decide at call time whether a call is allowed. A note card spawned in the middle of a session was written to in that same session.

Amp is the most honest case. Its agent loop — model calls included — runs on Amp’s servers; the local CLI only executes tools. So OpenRouter and its attribution are impossible for Amp, and everything the app does around it was verified against a local fake of Amp’s server.

Found live: a line broken by the terminal When a Goose session is deleted, Goose prints “no such session exists”, and the app is supposed to recover with a fresh one. The first version missed it: the Windows console had wrapped the line as “no suc / h session exists”. Recovery markers are now matched with all whitespace removed.

How it was tested

Every CLI was installed into a scratch folder, never globally, and run by a separate build of the app with its own profile and a scratch home folder, so no real config of anyone’s was read or written. Most were pointed at a small scripted model server on the loopback interface — one that answers “PING”, calls tools, stalls for fifteen seconds, returns 429 — so rate limits, stalls and permission prompts could be produced on demand instead of waited for.

The same server recorded request headers, which is how OpenRouter attribution was checked: every CLI that talks to OpenRouter now sends NeuroSquad’s headers, including cards on the CLI’s own OpenRouter login, and each one was measured on an intercepting server, not taken from documentation.

The add-card menu lists agents first; the ones installed on this computer are marked.

Two smaller fixes rode along the way: Kilo Code cards no longer lose their settings to a shared daemon, and Qwen Code’s token for the app’s MCP server is no longer written to disk. The full lists are in the changelog for 0.1.128, 0.1.133 and 0.1.137.

Community cards, MCP servers and skills — all connected by an arrow

Fri, 25 Sep 2026 10:25:35 GMT

Until this week every card on a NeuroSquad canvas was ours. 0.1.123 changed that in three ways at once: community cards that anyone can build and publish on GitHub, MCP servers from the official MCP Registry, and skills from skills.sh — each one given to a specific agent by drawing an arrow. An hour and a half later 0.1.125 added verified cards: a reviewed list with a badge that means something precise.

The canvas has one rule that makes it readable: an agent can use exactly what its arrows point to. Opening it to other people’s code was only worth doing if that rule survived. Most of the work in these releases is about making sure it does.

First, make a card cheap to add

The first cards were wired into the app by hand: a card type in a union, a branch in the canvas, labels, icons, an entry in the MCP server’s tables, a step in the removal cascade — about a dozen places per card. Tolerable one at a time, and a guaranteed conflict when several are built in parallel.

So built-in cards became plugins first: one folder in the page, one module in the main process, IPC channels under a common prefix, MCP tools registered by the card itself, strings in their own file. The canvas, the sidebar, the arrows and removal handle every plugin card the same way. Once a card is a plugin, letting someone else write one is a question of isolation, not of wiring.

Community cards: a sandbox that cannot leave the card

A community card is a small web app. It could run in a separate native web view, but that is an OS-level overlay: it would sit on top of the canvas instead of inside it, and would not zoom or clip with it. It runs instead in a sandboxed iframe with an opaque origin, served through the app’s own protocol. Before building on that, we checked what such a frame can and cannot do in this exact version of Electron:

It runs in a separate OS process. A card spinning in a busy loop for four seconds did not freeze the canvas: the host’s timer kept ticking, with a largest gap of 63 ms.
window.api, Node and require are simply not there, and touching the parent page throws a security error.
localStorage and IndexedDB are unavailable (hence a storage API of its own), and outside requests are blocked by the frame’s content security policy.
It cannot open windows, go fullscreen, read the clipboard or turn on the microphone.

Two checks failed, and those are the valuable ones. WebRTC ignores content security policy entirely: a peer connection reached a TCP listener on the local machine. The fix is blunt — the card’s boot script removes the WebRTC constructor before any card code runs. The second was in the app, not the frame: its permission handler granted the microphone to whoever asked. It now grants it only to the app’s own top-level page; that is the “Microphone access is granted only to the app itself” line in the changelog.

A card never talks to the page it is drawn on. It gets a message port to the main process, bound to that one card instance, and every request is checked there against the permissions the package declared and you granted at install. Anything that reaches another card or an agent — sending data through a port, prompting an agent, typing into a terminal — needs both the permission and an arrow between the two cards. The arrow is the consent for that particular flow of data.

Installing is by GitHub address, pinned to a commit and checked against the hash of the package’s file tree. Updates happen only when you click, and show you what changed in the permissions first. More on building one on the Card SDK page.

Verified cards: a badge that means one thing

An install-by-address model has an obvious gap: how do you find a card worth installing? 0.1.125 adds a catalog of cards reviewed by the NeuroSquad team, kept in a public repository and updated by pull request. You can search it in the “Custom card…” picker or in Settings.

Verified cards in the picker. The shield says this exact code was reviewed — not that it can never do harm.

The badge is decided by the main process and means exactly this: the installed card comes from the reviewed repository, at the reviewed commit, and the hash of its files computed at install time equals the hash in the catalog. A local development folder, another commit or different files — no badge.

Installing from the catalog goes one step further: if the name, version or hash does not match the catalog entry, the install is refused. The choice here was between “install it without the badge” and “do not install it”, and a substituted package is not something to install quietly. A newer reviewed version is offered as an update with the usual permission diff, never applied by itself; a card that leaves the list loses its badge, and nothing is removed from your canvas.

MCP servers and skills, by arrow

The catalog in the app searches the official MCP Registry (about 35 thousand servers) and skills.sh (the 20 thousand most-installed skills). Search is local, in the app, over snapshots that ship with it and update incrementally — so it works offline and is instant.

Search the MCP Registry right in the app. Installing shows what will run, and asks once.

The obvious way to give an agent an MCP server is to write it into the agent CLI’s config. We deliberately did not. NeuroSquad is itself the MCP client of every server you install, and re-exposes that server’s tools through its own MCP server, as <alias>__<tool>, only to agents with an arrow to the server’s card, only while the arrow exists. Nothing is written to your CLI’s config folders, and a server’s secrets never leave the main process. Claude Code picks up a new arrow without a restart; other CLIs see it at their next start.

A replica: an installed MCP server, two agents, and the arrow that gives the server to exactly one of them. Live replica — try it

Skills work the same way, through one tool, skill_load, whose description lists the skills connected to that agent and when to use each. One flag made the difference between a feature and a demo: agents hide MCP tools behind a tool search, and in a live test a fresh agent never once loaded a matching skill. Marked “always load”, it loaded the right one on its own.

The same for a skill: connected by an arrow, loaded when the task calls for it. Live replica — try it

What a security review changed

Both releases went through a security review before shipping, and three results are worth describing:

Every agent has its own token for the app’s MCP server, derived from a per-launch secret and the agent’s id. Before, one agent could in principle act as another; now another agent’s path answers 401.
Third-party tools live on a second MCP server, which is not in the CLI’s list of pre-approved tools. So the CLI asks you before every call to a tool from someone else’s server — and the tool list is fingerprinted at install, so a server that changes its tools later waits for you to accept the changes.
A skill is taken whole, from one commit. skills.sh’s own content hash could not be reproduced from the files it serves, so the app pins its own SHA-256 of the exact files you previewed, and installs exactly those.

Not everything fits. Figma’s official remote server answers 403 to dynamic client registration — it accepts only approved clients — so the catalog points to a community server that works with a personal token instead. Packages that need a local HTTP server are not supported yet. Both are written down rather than worked around.

More on the MCP servers and skills pages, and the full list in the changelog for 0.1.123 and 0.1.125.

Fifty cards, one canvas: where the CPU was going, and the Squad card

Thu, 24 Sep 2026 19:07:33 GMT

NeuroSquad 0.1.117 is a release you mostly notice by what stopped happening: the fan spinning up while nothing is going on, a stutter when you drag a frame full of cards, a hitch every time you zoom out past the point where cards turn into tiles. It also adds the Squad card — the one board that tells you what every agent in the workspace is doing.

The goal for the canvas has been the same since the first weeks: up to fifty live cards — terminals, browsers, agents — with smooth pan, zoom, drag and resize. The rule for getting there has been the same too: measure first. Every number in this post comes from a separate instance of the app on a fresh profile, driven by real input events over the DevTools protocol.

Round one: fifty terminals

The first pass happened before the public release, on a workspace of fifty cards with twelve terminals printing as fast as they could. Zooming was slow for a reason that is easy to miss: the header of every card keeps a constant size on screen, and it did that with width and margin. Those are layout properties. Every frame of a zoom resized every header, which resized every card body, which fired every terminal’s resize observer — fifty terminal refits, fifty messages to the main process, fifty console resizes. Per frame.

The fix was to commit the zoom value once per gesture instead of every frame, resize terminals only when their grid of columns and rows actually changes, and swap live terminal grids for a static placeholder while the zoom is moving. Then the terminals moved from the DOM renderer to xterm’s WebGL renderer, which is where most of the time went: zoom median from 18.2 to 6.1 ms, p95 from 133 to 12 ms.

Chromium keeps exactly 16 WebGL contexts per process We measured it rather than assumed it. With WebGL on all fifty terminals, the result was “live: 16, lost: 34” within a second — and the sixteen survivors were the first to mount, not the ones you were looking at. So terminals get contexts from a pool of fifteen, handed to the ones on screen and taken back from the ones that leave it.

One measurement from that round decided a rule that is still in the code. Hiding terminals behind placeholders made zooming twice as fast (6.1 against 12.0 ms median) and panning slower (19.8 against 16.3 ms average): a pan just moves layers that are already painted, and swapping fifty grids out and back costs more than it saves. So placeholders appear only when a gesture actually changes the zoom.

Round two: the idle canvas

The second round started from a stranger complaint: the canvas was heavy while nothing was happening. Four parallel reviews of the code and one live profiling session on the “Launch day” workspace found not one cause but a pile of small constant costs. The largest one was a cartoon.

AI agent cards have a small mascot that shows the agent’s state. Its idle animations were infinite CSS animations on SVG children — and on those, the browser repaints on the main thread, every frame, forever. With three Claude Code cards on a canvas at 60% zoom, the renderer process used 98–104% of a core and the GPU 32–36%, doing nothing. Now only the “working” state loops, and it moves the HTML wrapper, which the compositor handles alone; every other state plays a few times and stops in a pose that already says what it means.

~100% → 15% — renderer CPU, idle canvas with three agent cards
~34% → 3% — GPU on the same canvas
180 → 66 — compositor layers after one CSS rule

The rest was a list of things that each cost a little and all ran constantly:

**Selectors with and :has() under the canvas.* Toggling a class on the canvas pane cost 25–34 ms of style recalculation each time, because rules like “every descendant of a gesture” had to be re-matched against every node of every card. Listing the elements that actually animate brought it to about 1.5 ms.
A CSS variable on the pane. The zoom level lived in a custom property on the element that contains every card, and changing it invalidated the style of the whole subtree, terminals included — 22–34 ms per commit. It is now one rule in a <style> tag that targets only the elements that read it.
Buttons with their own layers. The component library gives buttons a GPU layer. Inside a canvas that meant dozens of extra layers; one override outside the pressed state took the count from 180 to 66.
Timers in cards. Cards that poll — ports, budget, stand-up, the page watch — now tick only while their workspace is open and the window is visible, and they share one clock per period instead of one interval each.
A browser card nobody was looking at kept streaming frames. Now frames flow only while some window shows the card: 0 in the overview and in hidden workspaces, back on return.

Long tasks during gestures disappeared from dragging a frame, marquee selection, zooming across the overview threshold and panning in the overview. Panning and dragging need about half the renderer CPU they did; style and layout time in a pan trace fell from 311 to 53 ms and from 378 to 28 ms.

When cards are too small to read

Zoom far enough out and a terminal is a grey rectangle. Below 55% (you can change the threshold in Settings), every card shows a tile instead: its icon, its name and one fact that matters for its kind — an agent’s status, 3/11 on a to-do list, the columns of a board, the first line of a note.

The card body stays mounted underneath, in its own size — the terminal is not killed, not even refitted. The tile is drawn in screen pixels, so it stays legible at any zoom. Crossing the threshold re-renders zero card bodies and each tile once; panning renders nothing at all.

“Launch day”, zoomed out: every card turns into a tile with its main fact, while the terminals keep running underneath.

There is one subtle part. A terminal behind a tile is invisible but not paused — the terminal library’s own visibility check does not see CSS visibility — so it would keep rendering output nobody sees. Instead, the card collects the output and writes it in one go when you zoom back in. Except for one kind of chunk: a question the program asks the terminal (“what are you?”, “where is the cursor?”) is part of a conversation and must be answered now. A delayed answer showed up in a bash prompt as literal 1;2c — found live, and fixed.

The Squad card

With many agents on a canvas, “who needs me?” should not require a tour of the canvas. The Squad card answers it on one board: every AI agent in the workspace, grouped into needs you, working, finished and idle, with its CLI, its model and how long the current turn has been running. Click a tile to filter; click a row and the camera flies to that card.

A replica of the Squad card with the app’s own strings. The clocks run; click a tile, then a row. Live replica — try it

The model column is more careful than it looks. It shows the model of the agent’s last request as recorded in its own session log; failing that, the model set on the card; failing that, the default from the CLI’s own config file. When none of those exist it says “Default model” — not a guess.

The real card. Its row turns amber once when an agent stops to ask you something.

Squad is added to every workspace once, to the left of the leftmost card. If you delete it, it stays deleted — you can add it back from the menu. Getting “once” right took one more fix: the first version placed the card before the workspace’s saved layout had loaded, and the canvas then laid out every card from scratch. Opening an existing workspace for the first time could pile all its cards up in one corner. That is the bug listed under “Fixed” in this release.

The add-card menu changed too: agents come first, the ones installed on this computer are marked, there is a search box, and an empty canvas opens with big agent tiles. Full list in the changelog for 0.1.117.

We wrote our own installer, and NeuroSquad now updates itself

Thu, 24 Sep 2026 06:17:11 GMT

NeuroSquad 0.1.100 is the first version that keeps itself up to date. Getting here took three releases in less than a day, and the most useful lesson of the week: an installer is part of the product. It is the first window people see, and when it fails it fails in the worst place — between an old version that is gone and a new one that is not there yet.

From 550 MB to 96 MB

The first public installer weighed 550 MB. Most of it was the dictation model: about 640 MB unpacked, bundled so that voice input would work the moment the app opened. But dictation is optional, and making everyone download it to try a canvas of agents was the wrong trade.

0.1.92 stopped bundling it. The model is now downloaded when you ask for it — at the Dictation step of the setup wizard or later in Settings — and dictation turns itself on as soon as the download completes, without a restart. Until then the status bar says “Dictation: download the model” instead of showing an error. The installer dropped to about 110 MB.

The rest came from a less glamorous place: what gets packed. The packager copies every production dependency of the app in full, and the desktop app listed the whole UI stack there — component libraries, icon sets, the accessibility toolkit — even though the bundler already compiles all of that into the page. Moving everything only the page needs out of the runtime dependencies saved about 70 MB of files that nothing ever loaded. 0.1.94 shipped at 96 MB.

550 MB — first public installer, 0.1.91
110 MB — without the dictation model, 0.1.92
96 MB — only what the app loads at runtime, 0.1.94

The 1.7 GB detour One experiment made the installer 1.7 GB. A file list declared for Windows only does not add to the general list — it replaces it — so the build packed everything in the folder. It is now a written rule of the build.

Why the generated installer had to go

The first installers were generated by the packaging tool, and two bugs in them were bad enough to justify writing our own.

The first: it refused to install with “NeuroSquad cannot be closed” while NeuroSquad was already closed. Its check was “is any process running from the install folder”, with no names. What was running was the console host of the terminals from agent cards, left behind after the app exited. You could not see them, the message did not name them, and there was nothing to click.

The second was worse: an interrupted install could leave a half-written app behind. One report was an neurosquad.exe of 8 MB instead of 200, and no entry in Windows’ list of apps to uninstall it with.

The new installer

It is a small WPF program for the .NET Framework 4.8 that is already part of Windows 10 and 11, so it needs nothing installed first. The executable itself is about 240 KB; the app is appended to it as an LZMA payload, cut into 32 MB blocks that are packed and unpacked in parallel, with a CRC-32 for every file. The build downloads its C# compiler once and checks it against a pinned SHA-256; no SDK is required on the build machine either.

Pick the folder — the default one needs no administrator rights — and whether you want a desktop shortcut. The installer speaks English, Russian and Chinese.

What it does differently is mostly about telling you the truth:

A live log of every step, in the window and in a file in %TEMP%, so a failure has a line you can point at.
Processes in the way are listed by name and PID, and ended only when you press the button. No guessing, no silent kills.
Updates never overwrite in place. The new version is unpacked next to the old one, verified, and the two folders are swapped only when everything is there. A failure or a cancel leaves the old version exactly as it was.
Uninstall removes what was installed — the files listed at install time, the shortcuts and the Apps entry. Your data is removed only if you tick the box.

What holds the folder, by name and PID — the app and the terminals of its cards — ended only when you press the button.

When a file still cannot be replaced, the install stops with its log open, and the version you had stays as it was.

One detail is invisible and essential: the Start menu shortcut must carry the app’s AppUserModelID. Without it, Windows does not deliver the app’s toast notifications — and “your agent needs you” is the notification the whole product is built around.

Testing an installer on the machine you develop on is risky, so it has two switches for that. --snapshot renders every page to a PNG, in any of the three languages. --sandbox puts the shortcuts and the Apps entry into a folder instead of the Start menu and the registry, so install, update and uninstall can be run end to end without touching the system.

Updates that install themselves

With an installer that can replace a running copy safely, automatic updates became possible. NeuroSquad checks for a new release at every start and once an hour, downloads it in the background, and verifies its SHA-256 against the checksum the release itself publishes. No checksum, no install.

Updates are not optional; what you choose is when. A ring in the title bar shows the download; then an icon with a dot lets you update at any moment, and a dialog asks once per version: now, or on the next start. “Now” closes the app, hands over to the installer, which waits for the app to exit, installs over it and starts the new version. The next start installs a known newer version before the app opens at all — and if you are offline, the app gives up after three attempts and opens the version you have.

A replica of the title bar and the update dialog, with the app’s own strings. Pick “Update now” or “On next start”. Live replica — try it

The bug the update test found

The update path was tested for real: two builds, a local release feed, an update at start, an update while the app was working, and an offline start with an update already downloaded. With “Update now”, the new version was on screen about ten seconds later.

Before that, the first run failed — at the folder swap. Something still held the install folder, and it was not the app. It was the same orphaned console host that had confused the old installer: a child process of a card’s terminal, whose working directory was the install folder, because that is where the app itself was started from. A process holding a folder as its current directory is enough to stop Windows from renaming it.

The fix is one line at the very top of the app’s startup: change the working directory to the home folder. Children inherit it, and the install folder is no longer anybody’s current directory. 0.1.108 closed the other half: when updating from an older version whose leftover terminals still hold the folder, the installer now lists them with the other processes, and if something it cannot identify still holds a file — an Explorer window, say — it replaces the files one by one instead of giving up, and puts everything back if any step fails.

An installer is the one part of an app that cannot be fixed by the next update. It has to be right while nothing else is running.

If you are on 0.1.94 or older, run the new installer once over it; from then on updates arrive by themselves. Everything that changed is in the changelog for 0.1.100.

Why NeuroSquad: agents on a canvas, not in a row of tabs

Wed, 23 Sep 2026 15:33:19 GMT

Today NeuroSquad 0.1.91 went public — a Windows installer, ten agent CLIs, and a canvas. The first commit was on September 3rd, and along the way agents running in NeuroSquad’s own cards have helped build it. This post is about why it looks the way it does.

The problem: a row of tabs you have to babysit

Agent CLIs got good enough that one of them is no longer the bottleneck. You start a second one on the tests, a third on the docs, maybe a fourth on another repository. And then the work turns into watching: which tab has finished, which one has been sitting for ten minutes on a question like “may I run this command?”, which one is still going.

Tabs are the wrong shape for this. They hide everything except the one in front of you, they say nothing about state, and they know nothing about each other. An agent in tab three cannot look at the browser in tab five, even when that is exactly what it needs.

So NeuroSquad makes three bets. Every agent is a card with its real terminal on a canvas you can see all at once. The app tells you when an agent finishes a turn or needs you, so you stop polling. And an arrow between two cards lets the agent use what the arrow points to.

The workspace every new install opens with: a real Claude Code card, a real shell, a note, a to-do list and a board. The arrows are the agent’s tools.

A card is a real terminal, and it must never die

A card is not a chat window pretending to be an agent. It is the CLI you already use — Claude Code, Codex CLI, OpenCode, Qwen Code and six more — running in a real pseudo-terminal, with its own interface, its own keys and its own quirks. If the CLI updates tomorrow, the card has the update tomorrow.

That choice set the first invariant of the whole codebase: the terminal component may never unmount while its agent is alive, because unmounting it kills the process. It sounds obvious. It turned out to shape almost every canvas feature:

Switching workspaces does not replace the canvas. Every workspace opened in a session keeps its own canvas mounted, and the inactive ones are only hidden.
Zooming into a group of cards is a camera move to the group’s frame, not a filter — filtering would unmount the cards outside it.
Expanding a card to full screen is a 1:1 viewport plus a saved geometry, not a different component.
The canvas library deletes a selected node on the Delete key. Here that would mean killing a session with one keystroke, so nodes are not deletable by the library at all: our own listener collects the selection and asks once, in a dialog.

A lot of Windows plumbing sits under the same bet. The CLI is resolved to an absolute path through the system’s own lookup, because a desktop app does not see the same PATH as your terminal. Paths are passed with forward slashes, because the pseudo-terminal library mangles backslashes — except for cmd.exe, which reads C:/… as a list of switches. Variables a parent agent leaves in the environment are stripped before a child agent starts, or the child quietly stops saving its transcript. None of this is visible, and all of it had to be found by running the real thing.

“Finished” and “needs you” are different events

The whole point of the canvas is that you look away. So the app has to know when to call you back — and there are two very different reasons. Finished means the agent completed its turn and you can read the answer whenever you like. Needs you means the agent is blocked, right now, until you approve something.

The first version could not tell them apart. It watched the terminal: when the window title stopped changing for 1.2 seconds and the output went quiet for 2.5 seconds, the turn was over. That is a fair guess for “finished”, and it is exactly the same silence as an agent waiting on a permission prompt.

The answer was to ask the agent itself. Claude Code has lifecycle hooks, so each card starts it with a small settings file on top of your own: when you submit a prompt it reports working, when it raises a notification it reports needs you, when it stops it reports finished. Each hook is a single curl line to a server the app runs on the loopback interface, with the card’s token inside the URL rather than in a header — so the command survives whatever shell it runs in.

Two small rules that matter A “needs you” notification carries the agent’s own words — “Claude needs your permission to use Bash” — because a toast that cannot tell a question about rm -rf from a question about reading a file is noise. And it never times out: a blocked agent does not unblock itself after five seconds.

Agents that report through hooks switch the old guessing detector off for themselves, or you would get two alerts and the guessed “finished” would overwrite the real “needs you”. CLIs without hooks still get the heuristic. Clicking a notification flies the canvas camera to the card, which flashes green long enough to still be flashing when the camera arrives.

Arrows are tools

The third bet is the one people ask about most. NeuroSquad runs its own MCP server on 127.0.0.1, and every agent that speaks MCP gets a session on it. What that session contains is decided by the arrows on the canvas.

An arrow to a browser card gives the agent browser_* tools: a real Chrome, visible in the card, that the agent clicks and types into while you watch.
An arrow to a terminal card gives it terminal_: run a command in that* shell and read its screen.
An arrow to a note gives it note_, to a to-do list todo_.
An arrow to another agent gives it agent_* — and that arrow has a direction. It points from the lead to the helper; the helper cannot send work back up.

The arrow is the permission. No arrow, no tool — which makes the canvas an honest picture of what every agent is allowed to reach. And every call is drawn on its arrow as it happens, so you can see the lead handing a task to a helper instead of reading about it in a log.

A replica of the canvas, running on this page: a lead agent sends tasks to three helpers along its arrows, and each helper moves its own card on the board. Live replica — try it

The same wiring in the real app. Each arrow is a set of tools the agent has; the rest of the canvas is out of its reach.

Local by default

There is no account and no server of ours in the loop. Workspaces, cards and arrows are JSON files in the app’s data folder. Dictation is recognized on your computer, with Parakeet or Whisper. The Usage section reads tokens and cost from the agents’ own logs rather than from a proxy in front of them. Deleting a card never touches your project folder.

The release has more than this post can cover: remote access that runs the whole app in a phone’s browser, isolated git worktrees per agent, and a budget brake that interrupts every agent in a workspace when a spending limit is reached — with Ctrl+C, not a kill, so no session is lost.

What is next

The first build ships as a 550 MB installer, and most of it is a speech model that only people who dictate will ever load. That is the first thing to fix. After that: an installer that tells you exactly what is in its way, and updates that install themselves.

The full list of what is in 0.1.91 is in the changelog.