DEV Community

Cover image for I Built an IDE Where Claude Runs in Every Project Tab — Inside Hermes 1.1.5
Gabriel Anhaia
Gabriel Anhaia

Posted on

I Built an IDE Where Claude Runs in Every Project Tab — Inside Hermes 1.1.5

#ai #claude #devtools #ide

Hermes IDE 1.1.5 — an IDE where Claude lives in every project

Three days ago I had three projects open at the same time.
The marketing site needed a navbar refactor. The Tauri
desktop app I'm building needed a hotfix shipped before
the morning. And a side project — a Remotion launch video —
needed three Mermaid diagrams generated and dropped into a
scene. I had Claude Code running in three separate terminal
tabs. Every time I switched contexts, I had to remember
which directory I was in, which permission mode was active,
which model. The hotfix I shipped that day actually had to
be re-shipped because I dropped a context switch and let
Claude execute a git push against the wrong project.

I shipped Hermes IDE because I got tired of that. It is the
IDE I built for myself, and it solved every part of that
afternoon. Today, three projects open is normal. Five is
normal. Each session has its own working directory, its own
permission mode, its own model, its own MCP plugin set. No
context switch costs me anything. Versions 1.0 through 1.1.5
turned that idea into something I now reach for every day.

This post is about what shipped, what's actually unique
about the architecture, and the things I learned shipping
five releases in a week.

Why every IDE I tried felt the wrong shape

Every "AI-native IDE" I tried before building Hermes started
from the wrong place. They took a code editor and welded an
AI panel onto the side. The panel was a chat. The chat lived
in one workspace at a time. If you wanted Claude in a second
project, you opened a second window, and now you had two
copies of the editor, two indexers, two file watchers, two
copies of the LSP server, and a chat history split across
the two that you couldn't reconcile.

The TUI tools — Claude Code, Aider — sit at the other end.
They live in a single terminal tab. You can run two by
running two terminals, but everything that makes an IDE
useful (rich diff rendering, tool-call cards, MCP plugins
visible in a panel, a model picker) is missing. You're back
to copying file paths into messages by hand.

Conductor and a few of the recent agent-mode releases got
closer. Each is shaped around a single project at a time.
You can switch projects, but you can't run both at the
same time. Switching is a context flush.

The mental model I wanted was the one I have when I'm at a
real workbench. Three things in progress, three different
tools laid out, three pieces of context I'm holding in my
head at once. The IDE shouldn't make me put two of them
away to work on the third.

Native multi-session — what that actually means

The signature feature in Hermes 1.1.5 is multi-session,
multi-project, all in one window.

Multiple sessions running in parallel — each pane is its own project, its own model, its own permission mode

Three sessions, three projects, all live at once. The active pane carries a brass border; the rest keep streaming in the background.

"Native" here is doing real work, so let me unpack it.

Each session is a fully independent context:

  • Its own working directory (cwd)
  • Its own session id, its own message history, its own cost meter
  • Its own selected model (Claude Opus, Sonnet, Haiku, GPT-5, Gemini, etc.)
  • Its own permission mode (default, acceptEdits, plan, bypassPermissions, dontAsk, auto)
  • Its own thinking-effort level (low / medium / high / max)
  • Its own MCP plugin set (one session might have Linear + GitHub mounted; another might have Postgres + Sentry)
  • Its own attached project paths — yes, a single session can span multiple project directories with full file access in each. You point Claude at "the marketing site and the components library" and the agent can read and edit in either.

Sessions are processes. Not tabs in a chat history. Each
session is a real agent subprocess, talking to its own
running Claude binary, holding its own context window. When
you switch from session A to session B, nothing pauses or
unloads. A still has its history, its tool calls running, its
streaming response. You return to A and the cursor is right
where you left it.

Drag-and-drop to rearrange. Drop a folder onto a pane to
spawn a new session there. Drop an image onto a Claude pane
to attach it. The IDE doesn't really have a "project" concept
the way most tools do — it has sessions, and a session
has one or more attached project paths.

That subtle inversion is the whole game. You're not opening
a project and then deciding what to do with it. You're
starting work, and pulling whatever projects you need into
the workbench in front of you.

Claude as a first-class citizen, not a sidecar

The other thing every "AI IDE" I tried got wrong is treating
Claude as an external service. You make a request, you wait,
you get a response, you copy it into a file by hand or click
"apply." It's chatGPT-on-a-side-panel.

The agent timeline mid-conversation — tool call landed, status flipped to ✓, prose streaming

A live conversation: brass-bordered user message, agent prose streaming with the heartbeat cursor, a Read tool card that just completed (✓ 47 lines).

Hermes goes the other way. Every Claude session is a child
process running the official @anthropic-ai/claude-agent-sdk
in-process, wrapped by a thin bridge. That gives me the full
SDK surface area:

  • Tool calls as native UI, not JSON blobs in a chat. Read, Write, Edit, Bash, WebFetch, custom MCP tools — each renders as its own card with the right family color (file ops violet, exec green, search yellow, web blue, errors red).
  • canUseTool permission flow — when Claude calls a destructive tool, the bridge intercepts the call and pops a native permission prompt (allow / deny / edit input / approve-all-this-session). Your "allow" round-trips back to the SDK as the actual PermissionResult.
  • Live cost meter in the masthead, ticking up as tokens stream. Per-session, not per-IDE-launch.
  • Mid-session control — interrupt(), setModel(), setPermissionMode(), setMcpServers(). Switch your active session from Opus to Sonnet without losing conversation history.
  • In-process MCP server named hermes exposed by the bridge. Claude can call mcp__hermes__get_project_state to see what's open, mcp__hermes__open_file to focus a file in the editor, mcp__hermes__get_session_memory to read user-pinned facts. The agent has actual IDE awareness.

It's the difference between an IDE that talks to Claude and
one that's built around Claude.

Diffs, diagrams, and the rest of the rendering story

Once Claude is a first-class citizen, you can render its
output the way it deserves. Diffs are not pretty-printed
text — they're real diff cards, computed from the SDK's
tool_use payload, with a per-line green/red gutter and an
optional side-by-side view.

Diff card — syntax-highlighted, line-numbered, +6 / −2 with the changes inline

When Claude proposes an edit, you see the diff before you approve it. Per-line additions in green, removals in red, full hljs-mapped syntax tokens.

Mermaid blocks render inline. The same agent that asks for
"a diagram of the data flow" can hand you back a real SVG
inside the conversation, on the same page as the code change
it's reasoning about.

Mermaid diagram rendered inline — the same conversation thread that proposes a code change can also hand you back a real architecture sketch

Markdown, mermaid, code fences, math — all rendered inline. The conversation IS the document.

MCP plugins, treated as first-class as Claude

If Claude is the engine, the MCP plugin ecosystem is the
fuel. Every MCP server you connect — Linear, GitHub,
Postgres, Slack, Sentry, Vercel — appears in the IDE's
plugin panel with a real status (connected / needs auth /
failed), and Claude can call its tools natively from any
session.

MCP plugin panel — Linear, Slack, GitHub, Postgres, Sentry, Vercel — each with a live connection status

Plugins are per-session. The marketing-site session doesn't need Postgres mounted; the hotfix session doesn't need Slack.

A real example from this week. I was debugging a flaky test
in the Tauri agent crate. I had a Hermes session open on the
project with the GitHub MCP plugin loaded. I asked Claude to
"find every PR in the last month that touched
src-tauri/src/agent/ and summarize what changed." Claude
called the GitHub MCP plugin, pulled the PR list, fetched
the diffs, and summarized. No copy-paste of a gh CLI
output, no "what would you do if you had the data" hand-
waving. Just the answer, with file paths I could click to
open in the same IDE.

The plugin set is per-session. The marketing-site session
doesn't need the Postgres plugin loaded. The hotfix session
doesn't need Slack. You configure once and the IDE remembers
which plugins each session uses.

What's in 1.1.5

The 1.0–1.1 line was the agent-mode pivot — moving from
TUI-scraping (the way Hermes worked through 0.6.16) to
native agent SDK integration. 1.1.5 specifically is a
hotfix release that closed three regressions:

  • Agent mode crashes on installed builds (1.1.0 through 1.1.4 had a bundling-pipeline bug; the bridge runtime shipped with the installer in 1.1.3 and got fully fixed in 1.1.5)
  • Bridge prewarm — on first agent session of a fresh app launch, the runtime is warmed up in the background so the "awaiting claude" pause is mostly gone
  • Permission and abort handling — pressing stop while Claude is mid-tool-prompt no longer hangs the session

Plus the architectural plumbing: a guard test that catches
missing-resource bugs at unit-test time so this regression
class can't ship again, and a CI pipeline that stages the
bridge runtime correctly across all six platform targets.

The honest "what's not yet"

Two things I'd flag before you install:

  • Linux AppImage is paused for one release. The bundle size grew when we started shipping the SDK runtime inside the installer. linuxdeploy chokes on the file count. .deb ships fine on x86_64 and aarch64; AppImage returns in v1.2 with a tarball-extracted-on-first-launch architecture (already designed in docs/adr/002).
  • Bundle size is roughly 210 MB heavier than v1.1.2. Same cause, same fix in v1.2. If you're on a slow connection, that's the trade-off for native agent mode in 1.1.5.

For most users on macOS or a Debian-derivative Linux or
Windows, none of this matters. For the rest, v1.2 closes the
gap.

Try it

Hermes IDE is open source under a fair-source-style licence
(commercial use allowed for individuals and small teams; see
the LICENSE for thresholds). Free for what most engineers
use it for. Cross-platform: signed/notarized macOS, .deb
on Linux, NSIS + MSI on Windows, both arches each.

If you ship with Claude every day — or if you've ever
thought "I wish I could run this in three projects at once" —
give it 30 seconds. Drag a folder onto the empty workbench.
Tell Claude what to build. Drop another folder onto the
second pane. Tell Claude something different. Watch them run
in parallel.

That's the whole pitch.

Top comments (0)