Problem or Use Case
I work across multiple machines: a personal desktop and a work MacBook. Hermes currently runs on a remote server, which means it can't interact with my local environment the way I need it to.
The core limitation shows up in development workflows. For example: I'm working on a project on my MacBook. The code is there, the local development database is running there, everything is local. A workflow I rely on heavily is telling an agent (like OpenCode) to fix a bug and keep running tests until they pass. Hermes can't do this today because:
- Pasting code into Discord means it can't run tests. It has no access to the project
- Hermes on the server can attempt to run a snippet, but it doesn't have the full project context, the local DB, or the local toolchain
The external gateways also feel limiting compared to the TUI, which is another reason I want to use the TUI while keeping the same instance available across machines.
Proposed Solution
Allow Hermes to run as a local agent (similar to e.g. OpenCode) while proxying to a remote Hermes server instance.
Specifically:
- Local TUI as a proxy: The Hermes TUI should be able to run locally on a machine and proxy agent operations back to the server — so you get the full TUI experience while the agent has access to the local filesystem, processes, and tools.
- Remote tool execution: When connecting from a client machine, Hermes should ideally default to treating that machine as the backend (via proxying tool execution to the client's TUI instance), rather than running everything server-side. This way,
hermes on my MacBook means the agent can run commands, read files, and execute tests on my MacBook.
- Or, SSH into the connected machine and use it as a SSH backend
- Same instance, multiple machines: The underlying Hermes instance (context, memory, config) remains shared/server-side — only the execution environment changes based on where you're connecting from.
Alternatives Considered
- Paste code into Discord / external gateway: Loses project context entirely — no way to run tests or interact with the local dev environment.
- Run a separate local Hermes instance: Loses the shared state and continuity of the server instance.
- OpenCode instead of Hermes for local tasks: Works, but means context-switching between tools and losing Hermes' broader capabilities.
The proposed approach is better because it keeps a single Hermes instance while making the execution environment flexible and local-aware.
Feature Type
Gateway / messaging improvement
Scope
Large (new module or significant refactor)
Contribution
Debug Report (optional)
Problem or Use Case
I work across multiple machines: a personal desktop and a work MacBook. Hermes currently runs on a remote server, which means it can't interact with my local environment the way I need it to.
The core limitation shows up in development workflows. For example: I'm working on a project on my MacBook. The code is there, the local development database is running there, everything is local. A workflow I rely on heavily is telling an agent (like OpenCode) to fix a bug and keep running tests until they pass. Hermes can't do this today because:
The external gateways also feel limiting compared to the TUI, which is another reason I want to use the TUI while keeping the same instance available across machines.
Proposed Solution
Allow Hermes to run as a local agent (similar to e.g. OpenCode) while proxying to a remote Hermes server instance.
Specifically:
hermeson my MacBook means the agent can run commands, read files, and execute tests on my MacBook.Alternatives Considered
The proposed approach is better because it keeps a single Hermes instance while making the execution environment flexible and local-aware.
Feature Type
Gateway / messaging improvement
Scope
Large (new module or significant refactor)
Contribution
Debug Report (optional)