EmailAdapter._sender_accepted runs before any MessageEvent exists and read only EMAIL_ALLOWED_USERS. Unset, it dropped every sender unless allow-all was on; set, it dropped everyone not listed. The gateway's own handling therefore never ran for email: platforms.email.unauthorized_dm_behavior "pair" (the setup wizard's "Use DM pairing") and "decline" sent nothing, and a sender admitted by GATEWAY_ALLOWED_USERS or an approved pairing was dropped.bb304b4914turned the empty-allowlist branch into drop-all after #50568 had made "pair" email's explicit opt-in. The gate now keeps a sender listed by address in EMAIL_ALLOWED_USERS or GATEWAY_ALLOWED_USERS, a sender the registered gateway authorization check admits (that is the only reader of the pairing store), and, under an explicit pair or decline, an unknown sender the gateway will answer. The default "ignore" still drops unknown senders before a MessageEvent exists, so the mail-loop guard fromfd9c32c0f2holds. Three guards keep the wider gate from widening access, and close two forged-From: paths main already had: - A sender admitted only so the gateway can answer it (pair or decline) must authenticate its From:, open access or not: the pairing code or refusal is mailed back to that address. A granted sender still needs it short of open access, since a pairing grant keys on From: just as the allowlist does. Open access follows the gateway's own order: EMAIL_ALLOW_ALL_USERS wins over a list, while GATEWAY_ALLOW_ALL_USERS beside a list admits nobody extra, so it no longer exempts a listed address from From: authentication either (on main a forged From: of a listed address got through there). - Open access comes from the gateway's own verdict when a check is registered. GATEWAY_ALLOW_ALL_USERS beside a GATEWAY_ALLOWED_USERS list grants a stranger nothing there, so the env flag alone no longer exempts one from From: authentication (that path mailed a pairing code to a forged From: on main too). - A sender whose local part alone matches an allowlist entry is dropped. The gateway's check also matches an address by its bare local part (#119446), so without this, GATEWAY_ALLOWED_USERS=alice (a chat username) would admit or pair alice@<any domain>. The lists are parsed as the gateway parses them, JSON list literals included, or '["alice"]' would slip past this guard. _allowlist_in_effect only served the old condition and is removed. The scope tests now assert the same scoped reads through _sender_accepted, with GATEWAY_ALLOWED_USERS covered as well. Measured end to end with the real GatewayRunner callback wired (adapter -> gateway ingress): - pair, decline, GATEWAY_ALLOWED_USERS and an approved pairing each went from 0 events reaching the gateway to 1. pair mails a pairing code, decline mails one refusal. - An unauthenticated From: in pair mode, for a paired address or for a GATEWAY_ALLOWED_USERS address still reaches nothing. - A bare GATEWAY_ALLOWED_USERS=stranger entry lets nothing from stranger@<domain> through, under ignore or pair. Without the local-part guard that mail reached the gateway in both. - The same holds for a JSON-literal list, and a pair-mode stranger with a forged From: under allow-all beside an EMAIL_ or GATEWAY_ALLOWED_USERS list reaches nothing. - The default still drops.
Website
This website is built using Docusaurus, a modern static website generator.
Reading the docs on GitHub? The Markdown under
docs/is authored for the rendered site at https://hermes-agent.nousresearch.com/docs/. Cross-page links are relative Markdown paths, so they follow through on GitHub's file viewer too. Every page on the site has an Edit this page link that opens the source file here.
Authoring links in docs/
- Link to another page with a relative Markdown path, anchors included:
[Profiles](../user-guide/profiles.md),[Bundles](../user-guide/features/skills.md#skill-bundles). Docusaurus turns the file path into the page route; GitHub follows the same path. Site routes (/user-guide/profiles,/docs/user-guide/profiles) only work on the rendered site — GitHub resolves them as repository paths and 404s, and the/docs/form also emits/docs/zh-Hans/docs/...404s in the zh-Hans build becausebaseUrlis already/docs/. python3 website/scripts/check_doc_links.pyfails on any route-style link in hand-authored pages (EN and the zh-Hans mirror);--fixrewrites them. It runs in theDocs Site Checksworkflow. Generated pages (user-guide/skills/{bundled,optional},reference/*skills-catalog.md) are produced byscripts/generate-skill-docs.py, which emits the same relative form.- Pin
{#anchor}on cross-linked headings so the zh-Hans mirror keeps the same id.
Installation
yarn
Local Development
yarn start
This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
Build
yarn build
This command generates static content into the build directory and can be served using any static contents hosting service.
Deployment
Using SSH:
USE_SSH=true yarn deploy
Not using SSH:
GIT_USER=<Your GitHub username> yarn deploy
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the gh-pages branch.
Diagram Linting
CI runs ascii-guard to lint docs for ASCII box diagrams. Use Mermaid (````mermaid`) or plain lists/tables instead of ASCII boxes to avoid CI failures.