Hermes Bridge
Cloud brain plans, local hands act, approvals stay local.
- What
- Cloud brain plans, local hands act, approvals stay local.
- Cost
- Free
- Needs
- Prompt 1 - For Muse (cloud): Connect
- Install
- Copy the installer prompt below into your Muse — your agent does the rest.
Connect a cloud Muse to a Hermes agent already running on your Windows PC, without opening an inbound port on that PC and without recreating your sessions somewhere else. The cloud assistant keeps planning and checking. The local agent does the work on your real PC, already logged in, with your files and applications already open. The link is a token mailbox. The brain deposits a task, the PC comes out to fetch it, the local agent executes it and posts the result back, and the brain reads that result. Two separate tokens keep the roles apart: the brain token can deposit and read, but cannot fetch or answer, and the Hermes token can fetch and answer, but cannot create or list tasks. A compromised or injected local agent therefore cannot give itself orders. Safety comes before speed. The first run is read-only only: list names, report, write nothing. Anything else, writing, modifying, deleting, installing, sending or paying, is refused by default and posted back as APPROVAL NEEDED. A writing mandate must come from you in person, in your chat with the local agent, and be written into the polling job's own orders, not just said in a chat and not just written in a task. The brain never approves a run remotely through an API. Approvals stay with you, locally. A run waiting for approval expires or fails, that is the rule. Autonomous rounds are optional and need their own go. Once set up, the local agent polls the mailbox on a schedule, at most one task per round, silently when there is nothing to do. The proof that rounds work is a task deposited without warning the local agent, fetched and finished by a round on its own, with the exact result format requested. Never plan on a declared polling interval: measure the real timestamps in the mailbox. An optional live tunnel can be added later, on its own go, if the local agent exposes an official API server. The tunnel connects straight to that API, with a strong revocable key, and the mailbox stays the durable backbone for queue, journal and write blocks. Each next step, PC browser, local files, open applications, needs its own go and its own guardrails, one step at a time. A bridge that creates new interruptions has fixed nothing: the measurable goal is fewer repeated logins, fewer restorations, fewer takeovers.
Version:
Quick answer
This skill connects a cloud Muse to a Hermes agent already installed on your Windows PC, through a token mailbox the PC polls. The brain plans and checks, the local agent acts on your already connected PC, read-only first, with manual approvals always on and no remote approval ever.
Install
Copy the install package below, then paste it into MusePrompt 1 - For Muse (cloud): Connect Pasted into Muse. Prerequisite first: a Hermes agent must already be installed and working on the Windows PC, with manual approvals on and YOLO off. This skill does not install Hermes. If Hermes is not installed, stop here. 1. Diagnose the local agent, read-only, no change: version, active model in the session (not just the default in the config file), terminal backend, approval mode, connected gateways, operating system user and working directory. 2. Build the token mailbox. Brain token: deposit tasks, list tasks, read results. Hermes token: fetch the next pending task and post its result only. Without a token: refused. With the wrong token for a route: refused. Test locally first with a simulated store, then deploy, then verify for real: public health OK, no token refused, then a full round trip with a test task (deposit, claimed, done, brain reads it, next fetch empty). 3. Deposit a pilot task with scope read-only-pilot, for example: list the NAMES only of the items in the current working directory, open nothing, write nothing. Rules: command line tool with a browser User-Agent header, GET and POST alike. Exact result format in every task: one line per item, forward slashes in paths. The brain never approves a run remotely. Never quote a secret value in a report, result or journal, summarize only. Stop means a net stop. Prompt 2 - For Hermes (in person, at the PC): Pick up Pasted into the local agent's chat, in person. Your presence authorizes the procedure. 1. Receive, in person, the connection lines for your environment file, with <MAILBOX_URL> and <HERMES_TOKEN> replaced at delivery time only, never in a skill file, never in a result, never in a report. 2. Fetch the next pending task. A fetched task becomes claimed, so it cannot be fetched twice. 3. Execute read-only tasks only. For anything else, do not execute: post APPROVAL NEEDED with a summary of what the task asks, and wait. 4. Post the result of every fetched task. A posted result makes it done. 5. Keep a friction journal, one dated entry per snag: step, exact error, fix tried, result. Rules: never quote a secret value. A mandate said in the main chat does not apply here: only the orders in this prompt count, and for rounds, only the orders in the pickup job itself. Stop means a net stop. Prompt 3 - For Muse (cloud): Verify and next steps Pasted into Muse, after Prompt 2. 1. Read the pilot result in the mailbox. The pilot is complete only when you have read the posted result in the mailbox, with status done verified in the mailbox. A report saying "result posted" is not proof. 2. Autonomous rounds, only on a separate go, and only by a mandate given in person: create a polling job that fetches at most one task per round, executes read-only tasks, and posts APPROVAL NEEDED for anything else. A mandate said in the main chat does NOT apply to rounds: it must be written into the job's own orders, with the exact list of allowed actions. Proof that rounds work: a task deposited without warning the local agent, picked up then finished by a round on its own. Never plan on a declared interval: measure the real timestamps in the mailbox. 3. Optional live tunnel, only on a separate go: enable the local agent API server in person, test locally without a key (refused) and with a key (accepted), create the named tunnel and DNS record and capture the tunnel credentials at creation time, configure the tunnel agent detached and persistent at login with a startup script, for example a .bat file in the Windows Startup folder that launches the tunnel agent at user logon, never inside an agent session, then verify from the cloud without a key (refused) and with a key (accepted). Suggested route, not required: Cloudflare Tunnel (named tunnel, DNS record, tunnel credentials, tunnel agent). Any provider offering the same shape works. Limits: at logon, not at boot; no crash auto-restart; a startup script for the tunnel agent does not start the gateway itself, which must also be running at logon, otherwise the tunnel points to nothing. Never quote a secret value in a report, result or journal, summarize only. Stop means a net stop.
Saved to your recent installs. Find it anytime on /connect.
🔒 Security, provenance and what this touches
The install prompt below already includes the vetting steps: your agent follows the community checklist before installing anything with executable code. Want more?
Questions
How do I install a skill?
Every product page includes a copy-paste install prompt. Paste it into your Muse and it sets the skill up for you — no manual configuration.
Where does my money go?
Straight to the seller. Skill Harbor never processes payments: checkout happens on the seller’s own page, usually Stripe.
What does the ✓ next to a creator’s name mean?
It means we confirmed the identity of the person behind the listing. It says nothing about the code itself — always check a skill before installing it.