I didn't build a VSCode extension for Herdr. About 1 week after finishing the install, the idea came up on its own — and before writing a line of code, I checked whether anyone, including the maintainer, had ever planned one.
Quick answer
TL;DR: Before you build a companion extension for a CLI tool you just installed, search its own GitHub Issues, Discussions, and Releases for "extension" and "editor integration," then search the relevant extension marketplace(s) for the tool's name. If the plan doesn't exist anywhere and an equivalent capability already exists in a tool you already run, you have your answer without writing a line of code.
For Herdr specifically: no such plan existed on GitHub, an equivalent capability already existed elsewhere (Claude Code's own VSCode extension, Cursor's Cloud Agents), and building one would have pointed Herdr's value in the opposite direction from the reason I installed it. The verdict was SKIP — and I wrote down why, so I don't re-litigate the same question in three months.
What I already had running
Herdr (github.com/ogulcancelik/herdr), an open-source (OSS) Rust CLI built by developer ogulcancelik, multiplexes AI coding agents — Claude Code, Codex, and others — the way tmux, a terminal multiplexer, multiplexes shells, except it also knows what state each agent is in. A background server keeps agents alive after you detach; process-name matching plus output heuristics detect whether an agent is working, finished, or waiting on you; a socket API and remote mode let external scripts read and drive that state. As of this writing it lists 21 supported agent runners, and most of them need zero configuration — you start the agent in a pane and Herdr picks it up.
I installed it through Homebrew's stable channel rather than building from source — new tools go into my daily workflow only after the stable release has had time to prove itself, not the dev branch. I confirmed the Claude Code and Codex integrations, placed the official Skill, and ran an independent check rather than trusting "it looks like it's working" — the check came back PASS, not a guess. Then I collapsed the daily startup ritual — attach to a session, split panes, start each agent by hand — into a single command that boots the workspace and the first agent in one action. Small thing, but it's a command I run many times a day, so the saved motion is real.
The natural next question: build a VSCode extension?
Once Herdr was running, the obvious next idea showed up: most of my actual coding happens inside an editor, so wouldn't it be nice to see Herdr's per-agent state in a sidebar instead of a terminal?
That's not a bad instinct. Wanting to use a new tool harder is usually how you find its real edges. But a VSCode extension isn't a weekend artifact — Herdr is young and its interfaces are still moving, so an extension built against it today inherits an open-ended maintenance obligation: track every upstream change, forever, for a convenience I hadn't yet confirmed I needed. "This would be nice to have" is not the same claim as "this is worth an ongoing maintenance commitment," and I wanted to check the first claim against reality before accepting the second one.
What checking the primary sources actually showed
I checked four independent surfaces before designing anything: Herdr's own GitHub Issues, Discussions, Releases, and the extension marketplaces a VSCode-compatible editor would actually use.
| source | what I searched for | result |
|---|---|---|
| GitHub Issues (74 total) | "vscode", "vscode extension", "editor extension" | Not a single Issue, open or closed, discusses a Herdr-authored editor extension — every hit was about a supported agent named similarly, unrelated to Herdr's own tooling |
| GitHub Discussions (459 total) | GraphQL search: "vscode extension", "editor integration" | 0 and 2 hits; the 2 were about Neovim integration and Windows support, not a VSCode plan |
| Releases (72 releases) | full-text grep of every release body for vscode / editor-integration terms | 0 mentions across the entire release history |
| VSCode Marketplace + Open VSX Registry | extension name search: "herdr" | 0 name-matching extensions on either registry |
Here's the actual shape of the check, generalized so you can run it against any repo before you build on top of it:
# 1. Has the maintainer ever discussed building this?
gh issue list -R <owner>/<repo> --state all --search "vscode extension"
gh issue list -R <owner>/<repo> --state all --search "editor integration"
# 2. Discussions catch roadmap chatter that never became an issue
gh api graphql -f query='{
search(query: "repo:<owner>/<repo> vscode extension", type: DISCUSSION, first: 20) {
discussionCount
nodes { ... on Discussion { title url } }
}
}'
# 3. Releases tell you what actually shipped, not what was proposed
gh release list -R <owner>/<repo> --limit 200 --json tagName -q '.[].tagName' | \
while read -r tag; do
gh release view "$tag" -R <owner>/<repo> --json body -q '.body'
done | grep -iE "vscode|vs code|editor extension|editor integration"
# example output shape from step 3, run against Herdr's actual release history
# (72 releases scanned, 0 matches)
The marketplace search wasn't a pure zero, though — and the "zero on name, non-zero on function" split is worth separating out. No extension is named after Herdr, but a handful of extensions solve an adjacent problem: they hook into agent lifecycle events to show session state in a VSCode sidebar. None of them run a persistent background process — close the editor, and tracking stops with it. That's a materially different capability from what Herdr's background server does, so "a Marketplace search turned up nothing" would have been the wrong headline; "nothing that replicates the one thing that makes Herdr worth using" is the accurate one.
Why doesn't an empty issue tracker prove there's no demand?
Reading "the maintainer hasn't built X" as "nobody wants X" is a shortcut, and it's wrong often enough to be dangerous on a young project — most people don't file an issue for a feature they haven't consciously wished for yet. An empty tracker on its own tells you the maintainer hasn't prioritized it. It doesn't tell you whether the community has.
That's exactly why the marketplace search matters as a second, independent source rather than a formality. If several unofficial extensions had been racing to cover Herdr's core capability, that combination — official silence plus visible unofficial demand — would have meant "wanted, but nobody officially owns it," and building one would have been a reasonable bet. What I actually found was the other combination: official silence and marketplace silence on the one capability that matters (the persistent background server), pointing the same direction from two sources that don't depend on each other. That agreement is what turned a hunch into a decision I was willing to write down.
The real deciding factor: not feasibility, but design intent
Absence of a plan doesn't automatically mean "don't build it" — it just removes one bad reason to build it ("someone official is already doing this"). The actual decision came from design philosophy, not feasibility: not can I build this, but what direction of investment does this tool exist to serve.
A VSCode extension is, structurally, a visualization panel — a way to pull an agent's state, progress, and logs into a human's field of view. That's a legitimate kind of value; Claude Code's own official extension is built on exactly that premise. But the reason I installed Herdr in the first place was the opposite direction: to hand the facilitation — the coordination between Claude Code and Codex, two agents with genuinely different behavior — to something other than me, so I'd stop manually deciding which terminal needed my attention next.
Those two goals point at each other. Building the extension would have been investing in "let the human see more," on top of a tool I'd installed specifically to need to see less. Neither direction is wrong in isolation — visibility has real value, automation has real value — but stacking both on the same tool, without deciding which one it's for, is how a tool quietly turns into two incompatible tools wearing one name.
Testing the "but CLI feels limiting" itch the same way
One nagging doubt survived the decision not to build: "wouldn't a VSCode extension make juggling sessions less awkward than a bare terminal?" That's a real feeling, not a rhetorical one, so I tested it the same way — against primary sources, not against my own hunch.
Claude Code's official VSCode extension already runs multiple independent tabbed sessions in parallel, each with its own history, while file changes, project settings, and CLAUDE.md rules stay shared across every tab. A background dot on a hidden tab tells you when that agent finished — a detail I'd have wanted to build myself. Cursor's Cloud Agents goes further: up to 8 agents run in parallel on independent remote VMs, so you can hand off "implement this feature" and "fix this bug" separately and check results whenever you're ready, without your laptop needing to stay online. That's strikingly close to what Herdr's background server is trying to do, in a different tool entirely.
In other words, the itch wasn't evidence that Herdr was missing something — it was evidence that I was asking Herdr to re-solve a problem two tools I already use had already solved. Skipping the extension meant I didn't rebuild, inside Herdr, a worse copy of a feature that already shipped one tab over.
Where Herdr actually earns its place
Solo work — one person switching between sessions — is already covered end to end by Claude Code's tabs and Cursor's Cloud Agents. Adding a Herdr-specific panel on top of that wouldn't add a capability; it would add a second, weaker version of one that already exists.
Where Herdr earns its keep is the one thing neither of those single-vendor IDE extensions does: cross-tool coordination, so Claude Code and Codex can hand work to each other, or defer to each other when stuck, without a human relaying the message every time. Claude Code's extension is scoped to Claude Code. Cursor's Cloud Agents are scoped to Cursor. Cross-tool handoff between genuinely different agents is a gap only Herdr currently fills.
That produced three working rules: run solo sessions through whichever editor's own tabs or cloud agents already cover it; open Herdr only when the task genuinely needs two different agents to hand off work between each other; build no dedicated UI for it, because the visualization value already lives somewhere else. I watch this fork — visualize more, or automate more — every time a new AI tool clicks into a workflow, and it's tempting to reach for "add a panel" before checking whether the panel's value already exists somewhere in the stack. Since narrowing Herdr's scope to that one job, I open it noticeably less often, and every open now means something specific — it's not the default way to start a session anymore, it's a deliberate choice for a cross-agent handoff.
Copy-paste checklist: run this before you build a companion extension
The next time a new CLI tool clicks and "should I build a UI for this" comes up, run these checks before opening an editor to start scaffolding:
| step | question | where to look |
|---|---|---|
| 1 | Has the maintainer discussed this, anywhere? | Issues, Discussions, Releases (full-text, not just titles) |
| 2 | Does an unofficial version already exist? | The relevant extension marketplace(s), searched by name and by function |
| 3 | If it exists, does it replicate the tool's actual differentiator, or just its surface? | Read what the alternative does, not just that it exists |
| 4 | Does an equivalent capability already exist in a tool you already run daily? | Check your existing editor/IDE features before assuming a gap |
| 5 | Which direction does this tool exist to serve — more visibility, or less need to watch? | State it in one sentence before adding a feature that pulls the other way |
Any single "yes" against steps 1, 2 (with real functional overlap), or 4 is a strong signal to stop before you design anything. Step 5 is the one that decided this particular case even after 1-4 came back clear.
FAQ
Does "no GitHub issues asking for X" mean there's no demand for X?
No, and treating it that way is the mistake this whole approach is designed to avoid. An empty tracker means the maintainer hasn't prioritized it — it says nothing about whether anyone else wants it. That's exactly why it needs a second, independent source (a marketplace search, a competing implementation) before you can read it as evidence either way. Two independent silences pointing the same direction is a real signal; one silence alone is not.
What if the marketplace search turns up something with a similar name but different features?
Read what it actually does before treating "an extension exists" as "the gap is filled." In this case, several marketplace extensions solved an adjacent problem — surfacing agent session state in a sidebar — without replicating the one capability that made the underlying tool worth using (a background process that survives detach). "Something exists" and "the differentiator exists" are different questions; only the second one should change your decision.
Isn't this just YAGNI applied to tooling instead of code?
Close, but not identical. YAGNI says don't build a feature until you need it. This adds a specific pre-check for tooling decisions: before you build anything companion to a tool you didn't write, confirm the gap is real (nobody else has filled it) and confirm which direction the underlying tool is trying to invest in (so your addition doesn't quietly pull it the other way). YAGNI alone would have let me build a technically-justified extension that still worked against Herdr's own reason for existing.
Further reading
Herdr (official site): https://herdr.dev
Using Claude Code in VS Code (official docs): https://code.claude.com/docs/ja/vs-code
Cursor Cloud Agents (official): https://cursor.com/cloud
Sho Naka (nomurasan). I write down the decisions I make about AI coding tools, including the ones where the interesting result was not building something. The install, the searches, and the numbers above are from my own setup, checked again on 2026-07-17.
This is an adapted English version of an essay I first wrote in Japanese. I worked with AI to shape and adapt the piece for a dev.to audience; the tool, the searches, and the decision are my own firsthand account.
Top comments (0)