I built a VS Code extension to work with several agents

Agents write the code, but I have to see it.

I need to read it, navigate it, jump to a definition, search the project and, when needed, debug it with breakpoints. An IDE already does that, and I didn't want to give it up to have agents in parallel. This post is about why I ended up building my own tool, and how I work with it.

What I tried

I tried several tools for running agents in parallel and none fully convinced me. This is what happened to me, on my machine and with my way of working:

• Superset: on my machine it ate the memory.
• Warp: a very good terminal, but for reading and moving around the code and the documents it fell short for me.
• In general, most of them pulled me out of the editor. They give you a window with chats or terminals, and the code becomes secondary.

They are good tools. They just didn't fit the way I work: I always ended up going back to VS Code to read what the agents had written.

What I wanted

To stay in VS Code, with my navigation, my extensions, my debugger and my search, and add on top what is missing to work with several agents at once.

From the other tools, having several agents in parallel, each in its own worktree, and knowing at a glance which one needs me. From VS Code, everything else.

What Stack is

Stack is a VS Code extension, open source under the MIT license. Each task has its own git worktree, which is a working copy of the repository with its own branch, and inside it its real agent: Claude Code, Codex CLI or opencode. The agents run in tmux, so they keep working even if I reload the VS Code window.

A sidebar tells me, for each task, who is working, who needs me and what is ready for review. When an agent asks me something, its question is the line of its row. And a shortcut, Cmd+Alt+J, takes me to the task that has been waiting for me the longest.

Why inside VS Code

There are five reasons, and all five are things the editor already does.

I see and navigate the code for real. Each worktree opens as a folder in the editor. Search and Quick Open are limited to the worktree I'm in, so the work of five agents doesn't get mixed in the results.

I debug for real. Each worktree has its own debug port and its own launch.json, so I can stop at a breakpoint in one task while another keeps running. It comes set up for Node and can be changed to any debugger VS Code supports. I use it less and less, but that doesn't mean it should be left aside.

I review without leaving. There is a diff panel with per-line comments, sent straight to the agent, without going through a PR.

I run each task's environment. Each worktree can have its own docker compose, with generated ports that don't collide, and a setup script (dependencies, the .env) that runs before the agent starts.

I use the real CLIs. It's my claude or my codex, with my configuration and my subscription. It's not a reimplementation.

A normal day

1. I write the task in New task. Stack creates the branch and the worktree, prepares the environment and launches the agent.
2. While they work, I read and navigate the code in the editor. When one asks me something, I see it in its row.
3. I review the diff in the editor, comment and send it back to the agent.
4. If something doesn't add up, I debug it right there.
5. The latest thing, which I'm just starting to use: Stack includes an MCP server and I use the Claude Code panel as a manager. I type /stack-task with a ticket, it reads the ticket with the Jira MCP and sets up the task.

What you should know

• It works on macOS and Linux. It needs tmux. On Windows, only with WSL. Native notifications are macOS only.
• It's not on the VS Code Marketplace yet: you install it from the .vsix file. It's version 0.1.0.
• To show live state, Stack registers a hook in each agent. In Claude Code it writes it to your ~/.claude/settings.json, and the first time it changes a configuration file it keeps the original as a copy with the .stack-backup extension.
• With Codex there is a catch. Its hooks are experimental and disabled by default, and you have to enable them in its configuration. Until then, its sessions don't change state in the sidebar. Codex also asks you to trust the hooks before running them.

How I improved it

I've been improving it with agents in parallel: some reviewed the code by area, others fixed the bugs, each in its own worktree, and then came the redesign. Today it has 2,102 tests, with 100% coverage of the code it measures. The React views, which are the interface, are left out of that measurement.

Agents write the code, but I'm the one who has to understand it. That's why I stay in the editor.

The code is on GitHub, under the MIT license.