hermes-agent/website/docs/user-guide/git-worktrees.md
Teknium 2d099fed1e
docs: deep audit — registry drift, stale claims, 2-week PR coverage, dashboard screenshot (#40952)
Full-corpus correctness audit of the hand-written docs against the codebase,
plus a 2-week merged-PR coverage sweep and one live dashboard screenshot.

Correctness (verified against COMMAND_REGISTRY / PROVIDER_REGISTRY / TOOLSETS /
tools.registry / DEFAULT_CONFIG / source):
- reference: add /version slash command, context_engine toolset, openai-api +
  novita-ai to --provider; fix tool count 64->71; model_catalog ttl 24->1;
  add profile describe to summary table; add real provider env vars
  (LM_API_KEY/LM_BASE_URL, KIMI_CODING_API_KEY, ALIBABA_CODING_PLAN_*,
  ANTHROPIC_BASE_URL, COPILOT_API_BASE_URL); fix faq "Windows: not natively".
- user-guide: fix broken `hermes -w -q` (->-z) and `hermes logs --tail` (->-f);
  language list 8->16; aux slots 8->11; docker separate-dashboard claim;
  _SECURITY_ARGS -> _BASE_SECURITY_ARGS.
- features: curator prune_builtins truth + missing CLI verbs; codex-runtime aux
  keys (context_compression->compression, vision_detect->vision); kanban
  terminate endpoint + promote/reassign/schedule/diagnostics/edit + per-profile
  cap; mcp mTLS (client_cert/client_key); built-in-plugins nemo_relay +
  teams_pipeline; api-server run approval endpoint; computer-use frontmatter.
- features N-Z + integrations: StepFun step-3-mini->step-3.5-flash; web-search
  backends 4->8; tool-gateway image-model IDs; voice-mode STT/TTS enums; remove
  phantom `rl` toolset; nous-portal status subcommand.
- messaging: WeCom typing/streaming cols; telegram transport default edit->auto;
  sms host default; simplex/ntfy `gateway setup` + pairing approve; line
  smart-chunking; matrix MATRIX_DM_AUTO_THREAD.
- developer-guide: build-a-plugin code examples (register_command signature,
  ContextEngine/ImageGenProvider/MemoryProvider ABCs); model-provider-plugin
  entry-point group hermes.plugins->hermes_agent.plugins; PLUGIN.yaml->plugin.yaml;
  agent-loop stale LOC; web-search-provider phantom crawl().

PR coverage (2-week window, 149 feat PRs):
- desktop.md refreshed for ~15 shipped features (zh-Hans switcher, rebindable
  shortcuts + zoom + Cmd+K, status-bar model picker + YOLO toggle, session-by-id
  + archive, multi-profile concurrent + cross-profile @session, composer history,
  Providers pane, per-profile remote hosts, Grok OAuth, aux-pin warning).
- configuration.md gateway-streaming default corrected to per-platform.
- tool-gateway.md free tool pool entitlement note.

Media:
- New /img/dashboard/admin-config.png — live dashboard Config admin page
  (captured from a clean profile, no secrets/personalization).
2026-06-07 01:39:06 -07:00

5.4 KiB
Raw Blame History

sidebar_position sidebar_label title description
3 Git Worktrees Git Worktrees Run multiple Hermes agents safely on the same repository using git worktrees and isolated checkouts

Git Worktrees

Hermes Agent is often used on large, longlived repositories. When you want to:

  • Run multiple agents in parallel on the same project, or
  • Keep experimental refactors isolated from your main branch,

Git worktrees are the safest way to give each agent its own checkout without duplicating the entire repository.

This page shows how to combine worktrees with Hermes so each session has a clean, isolated working directory.

Why Use Worktrees with Hermes?

Hermes treats the current working directory as the project root:

  • CLI: the directory where you run hermes or hermes chat
  • Messaging gateways: the directory set by terminal.cwd in ~/.hermes/config.yaml

If you run multiple agents in the same checkout, their changes can interfere with each other:

  • One agent may delete or rewrite files the other is using.
  • It becomes harder to understand which changes belong to which experiment.

With worktrees, each agent gets:

  • Its own branch and working directory
  • Its own Checkpoint Manager history for /rollback

See also: Checkpoints and /rollback.

Quick Start: Creating a Worktree

From your main repository (containing .git/), create a new worktree for a feature branch:

# From the main repo root
cd /path/to/your/repo

# Create a new branch and worktree in ../repo-feature
git worktree add ../repo-feature feature/hermes-experiment

This creates:

  • A new directory: ../repo-feature
  • A new branch: feature/hermes-experiment checked out in that directory

Now you can cd into the new worktree and run Hermes there:

cd ../repo-feature

# Start Hermes in the worktree
hermes

Hermes will:

  • See ../repo-feature as the project root.
  • Use that directory for context files, code edits, and tools.
  • Use a separate checkpoint history for /rollback scoped to this worktree.

Running Multiple Agents in Parallel

You can create multiple worktrees, each with its own branch:

cd /path/to/your/repo

git worktree add ../repo-experiment-a feature/hermes-a
git worktree add ../repo-experiment-b feature/hermes-b

In separate terminals:

# Terminal 1
cd ../repo-experiment-a
hermes

# Terminal 2
cd ../repo-experiment-b
hermes

Each Hermes process:

  • Works on its own branch (feature/hermes-a vs feature/hermes-b).
  • Writes checkpoints under a different shadow repo hash (derived from the worktree path).
  • Can use /rollback independently without affecting the other.

This is especially useful when:

  • Running batch refactors.
  • Trying different approaches to the same task.
  • Pairing CLI + gateway sessions against the same upstream repo.

Cleaning Up Worktrees Safely

When you are done with an experiment:

  1. Decide whether to keep or discard the work.
  2. If you want to keep it:
    • Merge the branch into your main branch as usual.
  3. Remove the worktree:
cd /path/to/your/repo

# Remove the worktree directory and its reference
git worktree remove ../repo-feature

Notes:

  • git worktree remove will refuse to remove a worktree with uncommitted changes unless you force it.
  • Removing a worktree does not automatically delete the branch; you can delete or keep the branch using normal git branch commands.
  • Hermes checkpoint data under ~/.hermes/checkpoints/ is not automatically pruned when you remove a worktree, but it is usually very small.

Best Practices

  • One worktree per Hermes experiment
    • Create a dedicated branch/worktree for each substantial change.
    • This keeps diffs focused and PRs small and reviewable.
  • Name branches after the experiment
    • e.g. feature/hermes-checkpoints-docs, feature/hermes-refactor-tests.
  • Commit frequently
    • Use git commits for highlevel milestones.
    • Use checkpoints and /rollback as a safety net for tooldriven edits in between.
  • Avoid running Hermes from the bare repo root when using worktrees
    • Prefer the worktree directories instead, so each agent has a clear scope.

Using hermes -w (Automatic Worktree Mode)

Hermes has a builtin -w flag that automatically creates a disposable git worktree with its own branch. You don't need to set up worktrees manually — just cd into your repo and run:

cd /path/to/your/repo
hermes -w

Hermes will:

  • Create a temporary worktree under .worktrees/ inside your repo.
  • Check out an isolated branch (e.g. hermes/hermes-<hash>).
  • Run the full CLI session inside that worktree.

This is the easiest way to get worktree isolation. You can also combine it with a single query:

hermes -w -z "Fix issue #123"

For parallel agents, open multiple terminals and run hermes -w in each — every invocation gets its own worktree and branch automatically.

Putting It All Together

  • Use git worktrees to give each Hermes session its own clean checkout.
  • Use branches to capture the highlevel history of your experiments.
  • Use checkpoints + /rollback to recover from mistakes inside each worktree.

This combination gives you:

  • Strong guarantees that different agents and experiments do not step on each other.
  • Fast iteration cycles with easy recovery from bad edits.
  • Clean, reviewable pull requests.