Jonathon's AI Wiki

rabbitOS 2.3 — Hermes Agent on R1 and the rabbit-agent Node Bridge

7 min read

Source: rabbitOS updates — 2.3 + 2.2 changelog capture, rabbit support — third-party agents on r1, first-hand field notes — self-hosted Hermes bridge, verified 2026-07-11

The 2026-07-10 rabbitOS 2.3 OTA put Hermes Agent (Nous Research) on the Rabbit R1 as a native, first-class voice backend — completing a three-release arc (2.2: Claude Code, 2.3: Hermes + OpenClaw v4) that turns the R1 into a multi-agent hardware console: pick your agent per page, bring your own keys, run the agent on hardware you control. The transport for all of it is the rabbit-agent node bridge, which replaces the January 2026 QR-pairing flow documented in OpenClaw on Rabbit R1. This article covers what shipped, how the bridge actually works (observed, not just documented), and a verified same-day setup of a self-hosted Hermes fork running headless in a cloud container — including the two failure modes anyone repeating it will hit.

What shipped in 2.3

  • hermes agent on r1 — the full open-source Hermes Agent framework, not a branded wrapper. No Hermes-side release changes were needed (nothing rabbit-related appears in Hermes v0.16–v0.18.2); the integration is entirely rabbit-side.
  • openclaw protocol v4, “rebuilt through rabbit agent” — OpenClaw moves onto the same node bridge and now works outside the home network (earlier pairing was LAN-bound).
  • DLAM goes BYOK — bring your own Anthropic or OpenAI key, pick provider and model in DLAM settings; billing routes to your own account instead of Rabbit’s pool (see DLAM).
  • Creations Gallery 1.5, proactive rabbit (triple-tap home-screen messages), and an on-device “what’s new?” card.
  • Context: rabbitOS 2.2 (Jun 18) had already shipped Claude Code on r1 (“start, read, and continue sessions from computers running the rabbit agent”) plus the return of terminal mode — 2.3 generalizes that architecture.

The rabbit-agent node bridge

R1 ↔ rabbit cloud ↔ rabbit-agent daemon (your computer) ↔ persistent `<agent> acp` subprocess ↔ agent
  • You register a computer as a node from the rabbithole portal (hole.rabbit.tech → settings → nodes → register node → paste a one-time-token install command in a terminal). The daemon keeps an outbound control WebSocket to rabbit’s cloud — no inbound ports, no QR scan.
  • One node advertises three backend slots — openclaw-session, claude-session, hermes-session — and spawns the matching local CLI as a persistent subprocess speaking ACP (Agent Client Protocol), JSON-RPC over stdio: hermes acp for Hermes. Session jobs are recorded under ~/.rabbit-agent/jobs/ with payload/stdout/stderr/exit files — the debug surface when things fail.
  • Registration state persists in ~/.rabbit-agent/: connection.json appears only on confirmed cloud registration, while private.key is written even for a rejected token — automation must gate on connection.json. Tokens are one-time-use and fail silently when reused.
  • Rabbit supports none of the agent side: the agent CLI must already work in a terminal on the node machine, with your own keys.

Self-hosted / headless container setup (verified)

The official flow assumes a desktop OS, but the bridge runs cleanly inside a headless cloud container (verified on Railway against a production Hermes fork, v0.18.0 base) ^[the container pattern is first-hand field experience, not rabbit-documented]:

  • Setup: run the installer from the container entrypoint as the runtime user with HOME on the persistent volume (state survives redeploys); register with the token only when connection.json is absent, resume otherwise; re-run the idempotent installer every ~10 minutes to replace its crontab-based self-healing; ship a no-op crontab stub so install.sh survives set -euo pipefail in cron-less containers; make everything non-fatal so rabbit outages can’t block service boot.
  • The PATH trap (exit 127): rabbit-agent’s job runner spawns stdbuf … hermes acp under a reset login-shell PATH — a venv-only hermes is invisible and every session dies instantly with stdbuf: failed to run command 'hermes'. Fix: a shim at /usr/local/bin/hermes that execs the real CLI and defaults HERMES_HOME to the production home, so even a fully stripped job environment lands in the right brain. (This is also why OpenClaw setups “just work” when the CLI lives at /usr/local/bin/openclaw.)
  • The wrong-node trap: every node advertises all three backends whether or not the agent is installed there. With multiple nodes registered, the R1’s Hermes page can target a node with no Hermes — sessions hang at “starting hermes” forever while the real node sits idle. Select the right computer per agent page. Node labels are container hostnames and change every redeploy; node identity persists.
  • Verified end state: persistent hermes acp process bound to the production HERMES_HOME; gateway (Telegram webhook) healthy during active R1 sessions; ACP sessions keep their own transcripts while sharing long-term memory, config, and skills with every other surface — the standard Hermes per-surface-transcript, shared-brain split (see Architecture Explained).

Key Takeaways

  • The R1 is now a voice remote for any of three agent ecosystems you self-host — DLAM (first-party) plus Claude Code, Hermes, and OpenClaw over one node daemon. Rabbit’s pitch is explicitly “plug the open agent ecosystem into pocket hardware.”
  • ACP is the integration surface. Rabbit didn’t build a Hermes integration; it built an ACP client and spawns <agent> acp. Any agent that speaks ACP over stdio is a candidate backend — the same protocol editors (Zed, JetBrains) use.
  • Self-hosted needs no subscription and no Hermes changes — a stock hermes acp (v0.16+ ships the ACP adapter; hermes acp --check verifies) on any machine the daemon runs on, including headless containers.
  • Voice still transits rabbit’s cloud — transcription happens on rabbit’s stack before reaching your agent, and session traffic rides their relay; a rabbit outage takes the bridge down even with your agent healthy (unchanged from the QR era).
  • Security posture: an R1 session gets whatever the local agent CLI can do — for a production Hermes home that includes terminal tools. Same trust tier as any full-power surface; revoke via rabbithole node removal, and consider a locked-down profile for the device.

Try It

  1. Update the R1 to rabbitOS 2.3 (check the “what’s new?” card), and have Hermes working in a terminal on the target machine (hermes acp --check → “Hermes ACP check OK”).
  2. hole.rabbit.tech → settings → nodes → register node → run the copied command on that machine (fresh token; they’re one-time-use).
  3. On the R1: swipe left to the Hermes page → “click to refresh” → select the right computer → hold PTT and talk. Session history lives behind the notebook icon.
  4. If it hangs or retries: read the newest ~/.rabbit-agent/jobs/hermes-session-*/stderr — exit 127 means a PATH problem (put hermes on the default system PATH); no jobs at all means the R1 is targeting a different node.
  5. Container deployments: follow the headless pattern above, and re-select the node on the device after each redeploy if the hostname label changed.

Open Questions

  • Friendly node names — partially resolved 2026-07-12: the label is a cloud-side displayName refreshed from the hostname in the daemon’s environment report (confirmed by watching labels track container hostnames across redeploys). rabbit-agent 0.1.2 has no rename API (surface: get_node + post_registerNode) and no naming env var; the portal’s token-mint schema carries an unexposed optional displayName. Working approach on hosts where the hostname can’t be controlled (e.g. Railway blocks sethostname/unshare --uts): the daemon is a dynamically linked Bun binary, so a scoped LD_PRELOAD shim interposing gethostname()/uname() makes it report a chosen name (RABBIT_NODE_NAME) — shipped to both self-hosted containers; final on-device confirmation pending (also proves Bun’s os.hostname() uses libc, not raw syscalls).
  • Multi-R1 → one node, and per-agent-page node stickiness semantics, remain undocumented (carried forward from the QR era’s open questions).
  • Whether rabbit-agent probes agent CLIs beyond PATH + the official install layouts (~/.hermes/hermes-agent/venv/bin/hermes, ~/.local/bin/claude) is unconfirmed — PATH placement is the reliable contract. ^[inferred]
  • DLAM BYOK’s rate-limit behavior post-2.3 (early community reports of throttling on the legacy pooled path).

Graph View

Backlinks