Mission Control source note: lotsoftick/hermes_client

Reviewed: 2026-05-22 13:10 SAST Source: https://github.com/lotsoftick/hermes_client Local inspection clone: /tmp/hermes_client_review at bc5a2e4 (fixed gateway status on linux)

Lucienne view

This is very relevant to Mission Control, but not as a drop-in replacement.

It validates several product/architecture decisions we have been circling around for Mission Control:

1. A chat-first web cockpit can sit over Hermes without needing a heavyweight always-on Hermes API gateway.
2. Hermes profiles map naturally to UI-visible "agents"/runtimes.
3. CLI invocation plus SSE streaming is a pragmatic runtime adapter pattern.
4. Session JSON files can be treated as durable truth and reconciled into a UI database.
5. Skills, plugins, cron jobs, profiles, model setup, and chat belong in one coherent operator shell.
6. A PTY-backed setup drawer is useful for preserving real CLI setup flows rather than re-implementing every wizard.

Mission Control should borrow the patterns, not import the app wholesale.

What the repo appears to be

Hermes Client is a public MIT-licensed Node/React app:

• API: Express + TypeORM + SQLite + JWT auth.
• Client: React + MUI + Redux Toolkit + Vite PWA.
• Runtime: invokes hermes CLI via execFileSync / spawn.
• Chat streaming: hermes chat -Q --source <source> -q <message> over Server-Sent Events.
• Profiles: UI agents map 1:1 to hermes -p <profile> profiles.
• Sessions: reads Hermes session JSON files and reconciles them into its local DB.
• Cron: reads Hermes cron jobs.json directly across profiles and invokes CLI for mutations.
• Setup: uses an xterm.js terminal connected to a small Python PTY bridge.
• Distribution: deploys to ~/.hermes_client, starts client/API on localhost ports, can install as PWA.

Best ideas to pull into Mission Control

1. Runtime adapter by CLI, not gateway

Relevant file: api/src/services/hermes/chat.ts and api/src/services/hermes/cli.ts.

Pattern:

• Construct argv as data, not shell strings.
• Spawn Hermes as child process.
• Stream stdout to browser via SSE.
• Capture stderr/session id separately.
• Kill child process if client disconnects.

Mission Control implication:

• The MC runtime contract should allow cli_process runtimes as first-class WAT executors.
• This is a clean fit for Claude Code / Codex / Kimi / Hermes profiles where the adapter can be a local command, not a network service.

2. Profiles as UI agents/runtimes

Relevant file: api/src/services/hermes/profiles.ts.

Pattern:

• List profiles through hermes profile list.
• Create/rename/delete profiles via Hermes CLI.
• Keep each profile's home/session/config state separate.

Mission Control implication:

• MC should distinguish three things clearly:
• Persona/role: Luci, Lucienne, Atlas, Tessa, etc.
• Runtime adapter: Claude Code, Codex, Hermes profile, Kimi, script, cron.
• Execution slot: current invocation with pid/session/stdout/status.
• Hermes profiles are a strong primitive for runtime isolation, but not the whole MC role model.

3. Session file reconciliation

Relevant file: api/src/services/hermes/sync.ts.

Pattern:

• Hermes session JSON remains the source of truth.
• UI DB mirrors sessions/messages for fast display.
• Sync handles race windows, unique constraints, soft-deleted messages, and terminal-originated sessions.

Mission Control implication:

• This is directly relevant to MC's thread/ticket model.
• MC should not make the browser DB the only truth for agent work.
• External runtime transcripts should be reconciled back into MC threads/tickets after the fact.

4. Cron surface across profiles

Relevant file: api/src/services/hermes/cron.ts.

Pattern:

• Reads profile-level cron files directly for listing/history because CLI output is human-oriented and profile-scoped.
• Uses Hermes CLI for mutating operations.
• Discovers cron run sessions by filename pattern.

Mission Control implication:

• MC scheduled work should be visible as first-class work, not hidden daemon state.
• Listing can read canonical on-disk state; mutation should go through official runtime commands.
• Scheduled runs should become ticket/thread events with provenance.

5. PTY setup drawer

Relevant files: api/pty-bridge.py, client/src/features/agent/setup/*.

Pattern:

• Use xterm.js to run real interactive setup commands like hermes -p <profile> model.
• Avoid re-implementing provider/model setup flows in React forms.

Mission Control implication:

• The Workbench should probably have a safe PTY/terminal card for runtime setup and diagnostics.
• It must be access-controlled and local-only unless hardened.

Cautions / things not to import blindly

1. Default admin credentials are insecure for anything exposed beyond localhost:
2. admin@admin.com / 123456 seeded on first run.

3. Fine for a local toy; not acceptable for MC without forced first-login rotation or generated one-time secret.

4. CORS defaults are permissive:

5. README says allow-all unless HERMES_STRICT_CORS=1.

6. MC should default closed, especially over Tailscale/LAN.

7. The app is single-Hermes oriented:

8. It manages Hermes profiles well, but MC must orchestrate multiple runtime types and ticket workflows.

9. Direct on-disk schema reads are powerful but version-coupled:

10. Good for speed and fidelity.

11. MC should wrap these in explicit adapter contracts with schema version checks.

12. This is not a governance layer:

13. No ticket lifecycle, approval gates, send-back review loop, WAT controls, or multi-agent assignment model.

Recommendation

Use hermes_client as a reference implementation for the "Hermes profile cockpit" slice inside Mission Control.

Do not fork it into MC wholesale. Instead create an MC runtime adapter note/issue with these borrowed patterns:

• HermesProfileRuntimeAdapter
• CliProcessInvocation
• SseTurnStream
• SessionFileReconciler
• CronStateMirror
• PtySetupWorkbenchCard

Acceptance criteria for integrating these ideas into MC:

• Every child process invocation records argv, profile/runtime, cwd, env redaction policy, pid, exit code, and transcript path.
• Browser disconnect kills or detaches according to explicit policy, never by accident.
• Session/transcript files are reconciled into MC tickets/threads with provenance.
• UI labels separate role/persona from runtime/profile.
• Any PTY/setup surface is local/trusted by default and separately gated for remote access.
• Security defaults are closed: no hardcoded admin password, no open CORS, no unauthenticated PTY.

Bottom line

This repo is probably the best concrete reference so far for the Hermes-specific part of Mission Control. It gives us validated patterns for profiles, streaming, setup, cron, and session reconciliation. The MC redesign should explicitly cite it as inspiration for the runtime adapter layer while preserving MC's broader governance/ticket/cockpit model.