Skip to content
/
Tier A A12 UI passthrough

Hermes IDE

hermes-ide · hermes-hq/hermes-ide

Primitive shape
No installable primitives
00

Summary

Hermes IDE — Summary

Hermes IDE is an AI-native desktop terminal emulator built with Tauri 2 + React + Rust, designed as "agent-native for Claude, terminal-faithful for everything else." Starting from v1.0.0, it runs Claude sessions in a structured Agent mode where Claude communicates via claude --print --output-format stream-json --input-format stream-json — a proper JSON protocol rather than a TTY puppet show. For all other tools (Codex, Gemini, Aider, plain shells), it provides a polished xterm terminal with WebGL rendering, git panel, execution timeline, and split panes. Key differentiators: ghost-text command suggestions from history and project context, automatic project scanning (language/framework/architecture detection), error pattern matching with auto-resolution, cost dashboard, session memory/context pins, and a Prompt Composer for natural language task delegation to Claude.

Compared to seeds: closest to kiro (Archetype 5 — closed IDE with proprietary primitives) but Hermes is NOT a VS Code fork and targets terminal-first developers rather than full IDE users. Unlike kiro, Hermes uses Claude's existing CLI auth and structured JSON protocol rather than building its own agent runtime. The defining delta: Hermes treats different AI providers differently by design — Claude gets Agent mode (rich UI), others get Terminal mode (plain TTY).

01

Overview

Hermes IDE — Overview

Origin

Created by hermes-hq. Repository: hermes-hq/hermes-ide. Business Source License 1.1 (BSL — converts to Apache 2.0 three years after each release). ~257 GitHub stars. Active (last push: 2026-05-25).

Philosophy

From DESIGN_PRINCIPLES.md:

"Principle 0: Agent-native for Claude, terminal-faithful for everything else."

"Starting with v1.0.0, Hermes IDE is an agent-native surface for Claude Code: we talk to Claude through its structured stream-json protocol, render real messages and tool calls as first-class UI, and stop pretending a terminal is a chat."

"We ask: 'Are we faking chat by typing into a TTY?' If yes, the right answer is Agent mode, not a cleverer puppet show."

Design principles (ordered by priority): 0. Agent-native for Claude / terminal-faithful for others

  1. Focused, not full-featured
  2. Fast by default
  3. Opinionated over configurable
  4. Core vs. Extension (feature subsets go in extensions)
  5. Stable over novel
  6. Saying "no" is a feature

Technical Architecture (from CLAUDE.md)

"Each session has a mode of either 'agent' or 'terminal'" "Agent mode (Claude only) — claude --print --output-format stream-json --input-format stream-json runs as a per-session subprocess." "Terminal mode (any provider, any shell) — classic PTY + xterm."

License

BSL 1.1 — source available but not truly open source. Converts to Apache 2.0 three years after each release date.

Distribution

  • Pre-built installers via hermes-ide.com/download: macOS (Apple Silicon + Intel), Windows, Linux (.deb, .AppImage, .rpm)
  • Build from source: requires Node.js 18+, Rust 1.70+, Tauri CLI
02

Architecture

Hermes IDE — Architecture

Distribution & Install

  • Pre-built desktop app: hermes-ide.com/download (macOS, Windows, Linux)
  • Build from source: Tauri 2 + React + Vite + Rust

Required Runtime

  • Tauri 2 desktop app (ships its own runtime)
  • Node.js 18+ (build only)
  • Rust 1.70+ (build only)
  • claude CLI installed + authenticated (for Agent mode)

Technology Stack

Layer Technology
Desktop runtime Tauri 2 (Rust + WebView)
Frontend React 18 + TypeScript
Build Vite
Terminal emulation xterm.js with WebGL
Backend Rust (src-tauri/)
Testing Playwright (E2E)

Two Session Modes (from CLAUDE.md)

Agent mode (Claude only):
  claude --print --output-format stream-json --input-format stream-json
    → per-session subprocess
    → Hermes reads structured JSON events
    → renders: messages, thinking blocks, tool call cards, diff previews
    → user writes to composer (JSON user events → subprocess stdin)

Terminal mode (everything else):
  PTY + xterm.js
    → standard terminal emulation
    → no AI integration at the terminal level
    → Aider, Codex, Gemini, shells all work unchanged

Directory Structure

hermes-hq/hermes-ide/
├── src/                   # React frontend
│   ├── agent/             # Agent mode: event stream reducer, message rendering
│   ├── components/
│   │   ├── SessionComposer.tsx  # Prompt input for Agent mode
│   │   └── TerminalPane.tsx     # Terminal mode
│   ├── state/             # Session context, mode management
│   └── ...
├── src-tauri/             # Rust backend
│   ├── agent/             # Agent mode subprocess management
│   └── pty/               # Terminal PTY management
├── packages/              # Monorepo packages
├── docs/
│   └── adr/
│       └── 001-agent-mode.md  # Architecture Decision Record for Agent mode
├── e2e/                   # Playwright E2E tests
├── DESIGN_PRINCIPLES.md
└── CLAUDE.md
03

Components

Hermes IDE — Components

Session Modes

Mode Provider Interface How Claude is invoked
Agent mode Claude only React chat UI claude --print --output-format stream-json --input-format stream-json subprocess
Terminal mode Any (Aider, Codex, Gemini, shells) xterm.js PTY Standard terminal

Agent Mode Features

Feature Description
Thinking blocks Claude's thinking rendered as first-class UI
Tool call cards Tool invocations shown as structured UI cards
Diff previews Code changes shown as inline diffs
Persistent conversations Claude sessions resume across app restarts
Image support Paste/drop images directly into composer
BYOA auth Uses existing claude CLI auth (Pro, Max, API key)

Terminal Features

Feature Description
Multi-session management Parallel sessions, switching
Split panes Horizontal + vertical splits with drag-and-drop
WebGL rendering Fast terminal with web links
Execution timeline Visual history: commands + exit codes + durations
Git panel Stage/unstage/commit/push/pull from sidebar
Inline diff viewer Syntax-highlighted file diffs

AI Intelligence Features

Feature Description
Ghost-text suggestions Real-time command completions from history + project context
Prompt Composer Natural-language task delegation to Claude in Agent mode
Error pattern matching Learns error fingerprints, auto-applies known resolutions
Stuck detection Monitors for hanging processes, offers interrupts
Project scanning Detects languages, frameworks, architecture, conventions
Context injection Attaches project knowledge to AI sessions via token budget
Multi-project Attach multiple project contexts to one session

Productivity Features

Feature Description
Command Palette Fuzzy search for any action
Cost Dashboard Token usage + estimated costs per model/session
Memory & context pins Persist facts, files, patterns across sessions
System notifications Long-running command completion alerts
05

Prompts

Hermes IDE — Prompts

Design Principle as Prompt Philosophy

Hermes IDE does not ship prompt templates or system prompts for the agent. The prompting is entirely delegated to the claude CLI subprocess. Hermes is a rendering and routing layer, not a prompt layer.

CLAUDE.md (project context file — verbatim excerpt)

File: CLAUDE.md (partial)

# Hermes IDE

## Architecture (1.0.0)

Each session has a `mode` of either `"agent"` or `"terminal"`:

- **Agent mode** (Claude only) — `claude --print --output-format stream-json --input-format stream-json` runs as a per-session subprocess. The pane renders messages, thinking, tool calls, and diffs as React components driven by an event-stream reducer.
- **Terminal mode** (any provider, any shell) — classic PTY + xterm. No composer.

`SplitPane.tsx` routes between the two based on `session.mode`. New Claude sessions default to Agent mode; everything else defaults to Terminal mode.

This file is a developer guide, not an agent system prompt. It tells the Claude Code agent (used for developing Hermes IDE itself) how to understand the codebase.

DESIGN_PRINCIPLES.md (verbatim excerpt)

## 0. Agent-native for Claude, terminal-faithful for everything else

We ask: "Are we faking chat by typing into a TTY?" If yes, the right answer is Agent mode, not a cleverer puppet show.

## 1. Focused, not full-featured

We ask: "Does removing this make the product worse for 80%+ of users?" If no, it doesn't belong in core.

## 6. Saying "no" is a feature

Every feature we reject makes the features we accept better. Focus is an ongoing, active effort.

These principles function as meta-prompts — they shape what Hermes builds and what it refuses to build. The "80%+ rule" and "no is a feature" pattern are anti-feature selection criteria baked into the team's design process.

09

Uniqueness

Hermes IDE — Uniqueness & Differentiation

Core Differentiator

Hermes IDE's defining characteristic is the stream-json protocol bridge: it is the only tool in this batch that uses Claude's native structured event stream (--output-format stream-json) as the primary UI data source rather than parsing terminal output or wrapping a chat API.

This means thinking blocks, tool call cards, and diffs are not scraped from text — they are first-class typed events that drive React components directly.

Differs From Seeds

Seed framework How Hermes differs
superpowers Superpowers adds skills/hooks to Claude CLI; Hermes wraps Claude CLI in a desktop GUI and never modifies the agent layer
claude-flow claude-flow orchestrates multi-agent task graphs; Hermes delegates all orchestration to the Claude subprocess
openspec openspec is a spec-scaffold workflow; Hermes is a session renderer with no spec concept
kiro Kiro is a VS Code extension with spec/hook/steering files; Hermes is a standalone Tauri desktop app
agent-os agent-os is a prompt-only behavioral framework with no runtime; Hermes is a full runtime with no prompt layer

Differs From Batch Peers

Framework How Hermes differs
codex-cli codex-cli is a Rust terminal binary with sandboxed execution and skill files; Hermes is a desktop GUI with no sandboxing and no skill system
gemini-cli gemini-cli is a TypeScript terminal binary for Gemini; Hermes is Claude-only and GUI-native
pi-coding-agent pi is a four-tool minimal agent with a pi binary; Hermes has no CLI, a richer terminal + agent GUI, and is Claude-only
tmuxai tmuxai reads tmux screen content and is terminal-native; Hermes renders Claude's structured events in a GUI and uses PTY only for non-Claude sessions
mini-swe-agent mini-swe-agent is a research-grade headless agent; Hermes is a product-grade GUI
micro-agent micro-agent is a TDD loop in ~200 lines; Hermes is a desktop IDE with full terminal emulation

Unique Design Decisions

  1. Explicit mode split by provider: Claude → agent mode (structured events); everything else → terminal mode (PTY). No ambiguity, no feature parity pressure.

  2. No prompt layer: Hermes does not ship system prompts. Prompting is entirely delegated to the claude subprocess. This is described as a deliberate design principle.

  3. BSL 1.1 licensing with conversion: Source is available but not open. Converts to Apache 2.0 three years after each release — unusual in the agent tool space.

  4. "No is a feature" as anti-roadmap: The team's documented Principle 6 ("Saying no is a feature") and the "80%+ rule" are explicit anti-feature selection criteria, distinguishing Hermes from tools that accumulate features.

  5. BYOA auth: Users supply their own Claude CLI auth. No separate Hermes account, no API key management in the app.

  6. Dual-runtime Tauri app: The Rust backend (src-tauri/) manages subprocess spawning and PTY; the React frontend handles all rendering. This gives native-grade process management with web-grade UI.

What Hermes Explicitly Does Not Do

  • Does not define skills, hooks, or prompt templates
  • Does not orchestrate multi-agent task graphs
  • Does not add approval gates beyond Claude's own
  • Does not ship a CLI binary
  • Does not support providers other than Claude in Agent mode
  • Does not implement its own LLM calls (all AI goes through the claude subprocess)

Positioning

Hermes is best understood as a first-class desktop shell for Claude Code, analogous to how iTerm2 is a first-class shell for bash — it improves the rendering and session management surface without changing what runs inside it.

04

Workflow

Hermes IDE — Workflow

Agent Mode Workflow (Claude)

User opens Hermes IDE → creates new Claude session
  → Session defaults to Agent mode
  → Hermes spawns: claude --print --output-format stream-json --input-format stream-json
  → SessionComposer.tsx accepts user natural-language input
  → Hermes writes JSON user event to subprocess stdin
  → Claude responds with structured stream-json events
  → Hermes event-stream reducer:
      → renders messages as React components
      → renders thinking blocks
      → renders tool calls as cards
      → renders diffs inline
  → User can paste/drop images into composer
  → Session persists across app restarts

Terminal Mode Workflow (Everything Else)

User opens session for Aider/Codex/Gemini/shell
  → Session defaults to Terminal mode
  → Hermes creates PTY + xterm.js
  → Standard terminal interaction
  → Ghost-text suggestions from history appear
  → Error pattern matching runs in background

Project Scanning

On session attach to project:
  → Hermes scans project: languages, frameworks, architecture, conventions
  → Builds project context (within token budget)
  → Context injected into AI agent sessions

Phases & Artifacts

Phase Action Artifact
Session create Mode detection (Claude → agent, other → terminal) Session object with mode
Project scan Automatic scanning for context Project context
Agent interaction JSON event stream to/from claude subprocess Rendered chat UI
Terminal interaction PTY + xterm Terminal output
Git panel Stage/commit/push via sidebar Git operations
Session resume Persistent sessions across restarts Resumed conversation

Approval Gates

Agent mode relies on Claude's own approval flow (tool call confirmations in the stream-json protocol). No additional Hermes-level approval gates documented.

06

Memory Context

Hermes IDE — Memory & Context

Session Persistence

Claude Agent mode sessions persist across app restarts. Hermes stores the full conversation history so that re-opening the app resumes the prior session without replay.

Store Mechanism Scope
Session history Persisted locally (Tauri app storage) Per session
Context pins User-defined memory facts/files/patterns Cross-session
Project context Scanned on attach, rebuilt on demand Per project

Context Pins

Users can pin:

  • Facts — freeform text that gets injected into future sessions
  • Files — specific source files to always include
  • Patterns — recurring conventions (code style, naming, architecture)

Pins survive session close and are re-injected when a new session is opened for the same project.

Project Scanning

On attaching to a project directory Hermes performs an automated scan:

Scan → detect languages, frameworks, architecture, conventions
     → build project context (within token budget)
     → inject into new Claude Agent mode sessions

The scan is bounded by a token budget to avoid overflowing the Claude context window. Results are cached between sessions and refreshed on demand.

Multi-Project Context

A single Agent mode session can attach context from multiple projects simultaneously, enabling cross-repo tasks.

Cost Dashboard

Hermes tracks token usage and estimated cost per model and per session. This is surfaced as a productivity dashboard, not as a context-management gate — there is no auto-truncation or summarization described in public materials.

No LLM-side Memory

Hermes does not use Claude's in-context summarization, vector stores, or external memory APIs. Memory is local-first: the Tauri app owns persistence; Claude itself is stateless across subprocess invocations.

Token Budget Enforcement

Project context injection respects a configurable token budget. When the scanned context exceeds the budget, Hermes trims it (strategy not publicly documented) before writing to the subprocess stdin.

07

Orchestration

Hermes IDE — Orchestration

Orchestration Pattern: Passthrough / Rendering Layer

Hermes IDE is explicitly not an orchestrator. It is a rendering and routing layer. The orchestration is fully delegated to the claude CLI subprocess.

Hermes role:
  1. Route session to Agent mode or Terminal mode (SplitPane.tsx)
  2. Spawn claude subprocess for Agent mode sessions
  3. Write user JSON events → subprocess stdin
  4. Read structured stream-json events ← subprocess stdout
  5. Render events as React components
  6. Persist the session history locally

Claude's own agent loop (tool approval, multi-step planning, sub-tool calls) runs entirely inside the subprocess. Hermes never inspects or intercepts tool calls beyond rendering them.

Event Stream Reducer

The frontend's src/agent/ directory implements an event-stream reducer that consumes stream-json events from the claude subprocess and drives the React UI:

Event type Rendered as
Message Chat bubble
Thinking block Collapsible "thinking" panel
Tool call Structured tool card
Diff Inline diff viewer

No Hermes-level Task Decomposition

Hermes has no concept of sub-tasks, parallel fan-out, or plan execution. Multi-step work happens inside the Claude subprocess using Claude's built-in agent capabilities (task tool, sub-agent spawning if the model supports it).

Approval Gates

Tool call approval is handled by Claude's own stream-json confirmation flow. Hermes renders the confirmation UI from the event stream but does not add extra gates.

Terminal Mode: No Orchestration

Terminal mode is a raw PTY. There is no AI integration at the terminal level — no command interception, no tool calls, no orchestration. The PTY is a faithful terminal.

Session Routing Logic

SplitPane.tsx reads session.mode and renders either SessionComposer.tsx (Agent) or TerminalPane.tsx (Terminal). New Claude sessions default to Agent mode; all other providers default to Terminal mode.

Subprocess Lifecycle

Each Agent mode session has exactly one claude subprocess. The subprocess is spawned at session creation and persists for the session lifetime. On app restart the session is resumed by re-attaching to (or replaying into) the stored history.

08

Ui Cli Surface

Hermes IDE — UI & CLI Surface

Distribution

Hermes IDE is a Tauri 2 desktop application. There is no CLI binary.

  • Download: hermes-ide.com/download
  • Platforms: macOS (Apple Silicon + Intel), Windows, Linux (.deb, .AppImage, .rpm)
  • Build from source: Node.js 18+, Rust 1.70+, Tauri CLI

Primary UI: Session Pane

The top-level layout is split by SplitPane.tsx into Agent mode panes or Terminal mode panes. Users can create multiple sessions in parallel and switch between them.

Agent Mode UI

Element Description
SessionComposer.tsx Natural-language prompt input; supports paste/drop of images
Message thread Streaming chat bubbles as Claude responds
Thinking panel Collapsible view of Claude's <thinking> blocks
Tool call cards Structured display of each tool invocation and result
Inline diff viewer Code changes rendered as syntax-highlighted diffs in context
Approval prompts Rendered from Claude's stream-json confirmation events

Terminal Mode UI

Element Description
xterm.js pane (WebGL) Full-featured terminal emulator with web link support
Execution timeline Visual history: commands + exit codes + durations
Ghost-text overlay Real-time command completions from shell history + project context
Error overlay Error pattern matches shown inline
Stuck detector Badges/alerts for hanging processes

Sidebar Panels

Panel Description
Git panel Stage/unstage/commit/push/pull — all via GUI, no terminal required
Cost Dashboard Token usage + estimated cost per model and session
Project context Attach/detach project directories; view scanned context
Memory & context pins Add/remove/view persistent facts, files, patterns

Global Controls

Control Description
Command Palette Fuzzy search for any app action (keyboard-first)
Session switcher Create, close, rename sessions; switch between parallel sessions
Split pane controls Horizontal + vertical splits; drag-and-drop reordering
System notifications Desktop alerts for long-running command completion

Authentication

Hermes uses the existing claude CLI authentication (Pro, Max, or API key). No separate Hermes account is required — BYOA (Bring Your Own Auth).

No Scripting API

There is no public programmatic API, plugin system, or CLI interface exposed by Hermes. Extensions are not mentioned in public documentation.

Window Layout Summary

┌─────────────────────────────────────────┐
│  [Command Palette]   [Session tabs]     │
├──────────┬──────────────────────────────┤
│  Sidebar │  SplitPane                   │
│  - Git   │  ┌──────────┬──────────────┐ │
│  - Cost  │  │ Agent    │ Terminal     │ │
│  - Pins  │  │ (Claude) │ (PTY/xterm)  │ │
│          │  └──────────┴──────────────┘ │
└──────────┴──────────────────────────────┘

Related frameworks

same archetype · same primary tool · same memory type

Goose (Block/AAIF) ★ 46k
A12 UI passthrough

General-purpose AI agent (not just code) with security-first tool inspection, recipe-based shareable configurations, and 15+ LLM…

Vibe Kanban ★ 27k
A12 UI passthrough

Eliminate the overhead of planning, switching between agent terminals, and reviewing diffs by providing a single web dashboard…

1Code ★ 5.5k
A12 UI passthrough

Cursor-like desktop experience for Claude Code and Codex with cloud background agents, event-driven automations, and a full…

Crystal (stravu) ★ 3.1k
A12 UI passthrough

Manage multiple parallel AI coding sessions in isolated git worktrees from a single desktop GUI.

Maestro (RunMaestro) ★ 3.0k
A12 UI passthrough

Orchestrate unlimited parallel AI agent sessions with a keyboard-first desktop app including Group Chat coordination and Auto Run…

AgentsMesh ★ 2.1k
A12 UI passthrough

Multi-tenant workforce platform that gives every team member a squad of AI coding agents coordinated through channels, pod…