Conversation
The saveMessages knob has been parsed by HonchoClientConfig since its introduction but was never consumed: sync_turn, on_memory_write and on_session_end persisted to Honcho regardless. With saveMessages=false the provider now never writes automatically (raw turns, memory-write conclusion mirroring, session-end flush) while read/tools paths stay fully functional. Guard uses getattr with a True default so legacy/injected configs keep the old behavior. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018giroL5zeMPnPxERxAxXHY
Salvages NousResearch#67559 — original gated sync_turn/on_memory_write/on_session_end but missed shutdown(), whose flush_all() still persisted on exit. hermes-sweeper review (salvageability=high) flagged this as the one gap. Guard sits after the worker-thread joins, not at the top: cleanup is independent of persistence, and a top-of-method return would leak _prefetch_thread/_sync_thread. Adds TestShutdown and clarifies the saveMessages=false README row. Credit @Matroskin86 (original PR author).
The containment commit skipped the whole turn when either side was empty, which would drop a real user message on interrupted or tool-only turns. Keep the guard for fully-empty turns only and skip empty sides individually inside the sync loop.
…er shutdown Provider shutdown() only called manager.flush_all(), which drains the queue but never joins the async-writer thread — manager.shutdown() exists and nothing called it. The writer thread could still be blocked in httpx I/O at interpreter exit (the NousResearch#37632 crash class). Now shutdown() calls manager.shutdown() (flush + join) when persistence is enabled, and a new manager.stop_async_writer() (join only, no flush) when saveMessages is false, so containment and clean teardown compose.
…ager.save() sync_turn called manager._flush_session() directly, which flushes synchronously every turn no matter what writeFrequency says — the "async", "session", and every-N-turns modes were dead configuration on the main turn path. Route through save(), the dispatcher that actually implements those modes. Same bug class reported in NousResearch#19650 (starship-s) and NousResearch#72708 (Diaspar4u); this takes the minimal one-line routing fix without their broader lifecycle refactors. Co-authored-by: starship-s <45587122+starship-s@users.noreply.github.com>
![carnie[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
…ousResearch#801) migrate_memory_files() uploads USER.md/MEMORY.md with peer=user_peer — the session's runtime user. In shared channels, a non-owner's new thread uploads the owner's full profile under the NON-OWNER's peer; Honcho's deriver then attributes the owner's psychometrics/medical/biography to that person. This was the root contamination vector (55/70 contaminated sessions carried the payload). Skip migration unless the session user is the configured owner. SOUL.md unaffected (uploads under assistant peer). Co-authored-by: Minh Nguyen <menhguin@users.noreply.github.com>
The owner gate from NousResearch#82038 compared against config.peer_name directly, which is None for most single-user setups — sanitizing None would raise and the gate never accounted for pinned/runtime/aliased identities. Resolve the owner the same way sessions do, and add the non-owner skip regression test the original PR shipped without. Co-authored-by: menhguin <menhguin@users.noreply.github.com>
alt-glitch
added
type/bug
The previous gate compared session.user_peer_id against a fresh _resolve_user_peer_id() call on the same manager. Both values come from the same resolver with the same inputs, so a non-owner triggering a new session in a shared channel passed the check and received the owner's MEMORY.md/USER.md under their peer. The owner is now a config fact: _declared_owner_peer_id() returns the sanitized peerName, and migration runs only when the session's user peer is that peer. Without a declared peerName, migration runs only when no runtime gateway identity is present (the single-operator CLI path). Aliases still work: a platform ID mapped onto peerName resolves to the owner peer before the comparison. Tests now derive each session's user peer from the real resolver instead of hand-picking mismatched ids, so the non-owner test fails against the old gate.
kshitijk4poor
added a commit
that referenced
this pull request
Aug 13, 2026
on_memory_write spawns a fire-and-forget daemon thread that was never stored on self, so shutdown() couldn't join it — the exact problem the PR fixes for the async writer thread. Store as self._memwrite_thread and include it in the shutdown join loop. Review follow-up for salvaged PR #83500.
Contributor
|
Merged via #85452. All commits cherry-picked with authorship preserved via rebase-merge. Thanks @dtownsel, @strzhao, @Matroskin86, @menhguin for the contributions adopted in this salvage. |
skappafrost
pushed a commit
to skappafrost/hermes-agent
that referenced
this pull request
Aug 15, 2026
on_memory_write spawns a fire-and-forget daemon thread that was never stored on self, so shutdown() couldn't join it — the exact problem the PR fixes for the async writer thread. Store as self._memwrite_thread and include it in the shutdown join loop. Review follow-up for salvaged PR NousResearch#83500.
bobaba76
pushed a commit
to bobaba76/hermes-agent
that referenced
this pull request
Aug 27, 2026
on_memory_write spawns a fire-and-forget daemon thread that was never stored on self, so shutdown() couldn't join it — the exact problem the PR fixes for the async writer thread. Store as self._memwrite_thread and include it in the shutdown join loop. Review follow-up for salvaged PR NousResearch#83500.
melon-xf
added a commit
to melon-xf/hermes-agent
that referenced
this pull request
Sep 3, 2026
on_memory_write spawns a fire-and-forget daemon thread that was never stored on self, so shutdown() couldn't join it — the exact problem the PR fixes for the async writer thread. Store as self._memwrite_thread and include it in the shutdown join loop. Review follow-up for salvaged PR NousResearch#83500.
11 tasks
erosika
added a commit
to plastic-labs/hermes-agent
that referenced
this pull request
Sep 6, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
erosika
added a commit
to plastic-labs/hermes-agent
that referenced
this pull request
Sep 6, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
erosika
added a commit
to plastic-labs/hermes-agent
that referenced
this pull request
Sep 8, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
erosika
added a commit
to plastic-labs/hermes-agent
that referenced
this pull request
Sep 8, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
erosika
added a commit
to plastic-labs/hermes-agent
that referenced
this pull request
Sep 8, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
erosika
added a commit
to plastic-labs/hermes-agent
that referenced
this pull request
Sep 8, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
erosika
added a commit
to plastic-labs/hermes-agent
that referenced
this pull request
Sep 9, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
teknium1
pushed a commit
that referenced
this pull request
Sep 10, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; #83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
keon94
pushed a commit
to keon94/hermes-agent
that referenced
this pull request
Sep 10, 2026
The manager resolved one user peer in `get_or_create` and froze it onto the session, then `_flush_session` chose between it and the assistant peer by role. Every user turn in a shared session landed on that one peer, so the first person to message the agent collected everyone else's facts — and a Honcho conclusion, once derived, is not self-correcting. `resolve_author_peer_id` maps the turn's author onto its own peer using the alias-then-prefix order `_resolve_user_peer_id` already applies, so an aliased account reaches the same peer whichever turn it wrote. `sync_turn` resolves it before starting the write thread, so a following turn cannot retag a queued write. `_flush_session` then writes each user message under that peer. A shared session's roster is open — people and other agents arrive after the session exists — so `_author_peer_for_session` joins a peer when it first writes instead of enumerating participants at init. Joins are remembered per session, and a failed join still writes under the right peer, losing only the observe config. Three cases return None and keep the session's own peer: no author named, the author IS the session's peer, and `pinPeerName` set — that flag is an explicit request to unify identities, so it still collapses authors in a shared chat. An unnamed author stays unattributed rather than defaulting to the owner. That preserves today's behavior for the transports that send no author, so those turns still reach the session peer; NousResearch#83500 owner-gated the memory-file migration for the same reason. Display names never become peer IDs — they are attacker-influenceable on any platform where participants set their own name.
abdulrahman305
added a commit
to qenex-ai/hermes-agent
that referenced
this pull request
Sep 11, 2026
* fix(relay): honor explicit profile disable before automatic relay activity
Relay bootstrap treated endpoint availability as activation, bypassing the
platform configuration's explicit opt-out. An injected relay URL could
provision credentials from a native-only profile and suppress its native
connectors even when relay was disabled.
Reuse the gateway's platform merge and boolean normalization for the
explicit-disable decision. Guard registration overrides, discovery, media,
and all dial/retry entrypoints; preserve URL-only legacy activation and
explicit operator enrollment. Skip relay-exclusive native suppression for
an opted-out relay.
Add real-config startup and standalone regression coverage, including
inherited credentials, managed config, config precedence, native delivery,
and fresh-token retry. Document restart semantics without claiming live
socket teardown.
* fix(relay): preserve legacy opt-out without standalone bootstrap
Carry legacy relay enabled intent through the canonical env sweep without changing other platforms. Read opt-out config through the cached non-bootstrap reader and existing managed overlay. Reproduce both Salt findings before fixes, cover native startup/delivery and isolated cold imports, and mutation-check the regressions.
* fix: apply managed gateway config without user YAML
Read an empty raw user layer on absent, invalid or unreadable YAML before applying the existing managed overlay. Preserve raw defaults and platform precedence so managed relay opt-out prevents env-exclusive native suppression.
Prove absent-YAML startup/native routing, managed enabled and URL-only controls, managed leaf precedence, and invalid-file siblings. Mutation: 17 failed/30 passed. Canonical 50-file suite: 682 passed.
* test(gateway): exercise streaming configuration with real YAML
* fix(config): reuse unchanged legacy gateway reads
* fix(relay): log terminal config opt-out on websocket dial
* feat(skills): archify joins the optional-skills catalog as an upstream-maintained stub
tt-a1i/archify (MIT, 57k stars) turns a typed JSON spec into validated,
self-contained interactive HTML diagrams (architecture / workflow /
sequence / dataflow / lifecycle) with a 9-check validate/deliver receipt,
Mermaid import and PNG/SVG/WebM export. The upstream repo already ships a
complete skill directory (archify/), so this follows the impeccable
pattern: a catalog stub whose metadata.hermes.upstream pointer makes
`hermes skills install official/creative/archify` pull the live tree
through OptionalSkillSource._fetch_from_upstream. Nothing executable is
vendored and the copy can never go stale.
Docs: generated page, one catalog row, one sidebar line.
Credit: tt-a1i (upstream author). Supersedes the vendored-references
port in #106442.
* fix(auxiliary): auto never bills a provider the user did not select
With a main provider selected, an unusable main route (expired xAI/Codex
OAuth token, 401/402/429 mid-session) fell through the built-in discovery
chain (OpenRouter -> Nous -> custom -> api-key) and quietly ran every
compression, title and memory-flush call on whichever OTHER account was
still logged in. Reported as "using Grok on my Premium+ sub, my Nous
Portal balance kept draining" — the chat visibly stayed on Grok while the
side tasks were billed elsewhere, and re-logging into X did not help
because the aux side never consulted the selected provider.
The discovery chain is now reserved for installs with no selected main
provider (`model.provider: auto` / unset). Otherwise the ladder is
main -> auxiliary.<task>.fallback_chain -> fallback_providers -> refuse
with a warning naming the dead provider and the fix. Both entry points
gate on the same predicate: the resolve-time route and the mid-request
payment/auth hop (_try_payment_fallback).
Existing chain tests that asserted the hop now pin `provider=auto`, the
one case where discovery is still the contract.
* fix(models): a vendor's own id on its first-party provider never re-routes
215fd0ecb9a made the current provider's live catalog outrank static
guesses, but a live catalog that could not be fetched (Codex outage, cold
cache) looked identical to "not served", so `/model gpt-6-astra` on
openai-codex still walked to OpenRouter (which relists every vendor)
whenever an OpenRouter key existed. Same shape for grok-* on xai-oauth
and claude-* on anthropic.
detect_provider_for_model now treats a vendor id typed on that vendor's
single-vendor first-party provider as a selection: stay, let the vendor
accept or reject it (the existing "not found in listing" note still
fires). Cross-vendor remaps (claude id on Codex -> keyed OpenRouter) and
aggregator / custom / multi-vendor reseller sessions are unchanged.
* fix(routing): address review — session runtime decides, quarantine continues the chain, unclassified ids break ownership
Three defects found in review of the first head (@ehz0ah):
* The mid-request hop read the PERSISTED provider from disk. A live
`/model xai-oauth` session over `model.provider: auto` therefore still
reached the discovery chain and billed Nous. _try_payment_fallback now
takes the route's main_runtime snapshot; disk is the fallback only when
no session runtime exists.
* After a configured fallback was quarantined mid-request (401, refresh
failed), the second pass went straight to the discovery chain, which
the new gate refuses — so later CONFIGURED entries never ran and the
original error was re-raised. The second pass now re-walks the task
chain and main chain (the quarantined entry is unhealthy and skipped)
before discovery.
* current_provider_owns_vendor dropped ids detect_vendor could not
classify, so Bedrock's 15-id catalog (14 unclassified `us.anthropic…`)
looked exclusively DeepSeek and `/model deepseek-v4-pro` stuck on
Bedrock. An unclassified id now counts as evidence of a multi-vendor
catalog: ownership requires every id to classify to the one vendor.
* feat(models): DeepSeek V4.1 Flash on the Nous Portal and OpenRouter pickers
Add deepseek/deepseek-v4.1-flash to OPENROUTER_MODELS (Nous list derives from it),
regenerate the docs manifest, and give the slug its own 1M context entry and 600s
reasoning-stale floor — the longest-key-first scan otherwise lands the new slug on
the 128K `deepseek` catch-all and no floor. Live probed on both routes: echoed
model matches, usage.cost billed.
* fix(desktop): match HUD transcript rows with aui_message-group slot
TurnRow roots now carry data-slot="aui_message-group", so the band's
*:not([data-slot]) selector measured an empty short session as 0px.
Include message-group rows while keeping the slot-less "show earlier" path.
Fixes #107050
Co-authored-by: Cursor <cursoragent@cursor.com>
* test(desktop): trim HUD band tests to the two invariants
Keep the row-shape contract (a TurnRow carrying aui_message-group measures;
clearance/background-resume spacers do not) and drop the two cases that
only re-assert the selector's shape.
* fix(desktop): give the Hyprland HUD float/pin promotion room for a lagging j/clients
The first map on Hyprland can leave the HUD tiled when `j/clients` does not
list the new client within the 8 × 50 ms the promotion loop allowed; the
window then stays a stretched transparent tile (#103091). Widen the budget to
24 × 100 ms. The loop returns on the first successful float+pin, so a prompt
compositor pays nothing extra.
Salvaged from #103116. Its second half (re-promote from focusWindow's
re-show branch) is dropped: the HUD is destroyed and respawned on every
toggle and is not minimizable, so that branch never runs for it.
* fix(desktop): read an auto-TTS reply aloud once when the HUD is open
With `voice.auto_tts` on and HUD mode active, a reply could be spoken
twice: the HUD renderer and the hidden app window both claim
`speak:<messageId>` through `hermes:ambient:claim`, and main collapsed
the two claims with the same 1 s deduper it uses for the turn-end beep.
The app window under the HUD is throttled by Chromium, so its transcript
subscription fires well past 1 s, finds the key pruned, and is told it
owns the cue. Fixes #99717.
The unit was wrong, not the window: a spoken reply is minutes of audio
keyed by a durable message id. `createAmbientClaimArbiter` keeps the
tick-sized window for `sound:*` and holds `speak:*` claims for a
10-minute TTL. No HUD special-casing: the same race exists between any
two windows showing the same chat, and the arbiter fixes them all.
Diagnosis credit: #99810 (@liuhao1024) and #100289 (@shivamjg101),
whose TTL framing this follows.
* fix(preview): scope action responses to active session
* fix(desktop): scope tour responses to active session
* fmt(js): `npm run fix` on merge (#107504)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* fix(desktop): force-settle the login-shell PATH probe past its timeout
execFile's `timeout` only SIGTERMs the direct shell child. A profile
that spawns a daemon (e.g. Powerlevel10k's gitstatusd under a non-TTY
GUI launch) can leave a grandchild holding the stdout pipe open, so
the execFile callback never fires and runProbe's promise hangs
forever — pinning desktop boot at "Resolving Hermes backend"
indefinitely.
Add a hard deadline that force-resolves the probe past its timeout and
kills the whole process group (shell + any daemons it spawned) so a
hung profile can never park boot.
Fixes #107109
* fix(desktop): preserve a sentinel already captured when force-settling
Mirror execFile's stdout into a buffer so the hard-timer path can still
extract a PATH sentinel that printed before a wedged descendant kept
the callback from firing, instead of discarding it as null.
* fix(bot-mode): keep the relay waiter watching past the Desktop deliver deadline
The sender-side waiter gave up at 900s while the Desktop held bot_relay.deliver open for 1500s, so a turn finishing between minute 15 and minute 25 wrote a reply nobody read. REPLY_WAIT_SECONDS now rebuilds the Desktop budget from the same numbers and waits 60s past it. The two turn constants move into tools/bot_relay.py so the gateway handler and the waiter share one definition.
* test(bot-mode): pin the waiter budget from Python constants, not relay.ts text
The waiter budget test read relay.ts with a regex, which AGENTS.md bans and which the Python CI lane would not rerun on an apps/-only PR. It now checks DESKTOP_DELIVER_TIMEOUT_SECONDS against the module's own constants and that REPLY_WAIT_SECONDS exceeds it. relay-deliver-budget.test.ts still pins the TS mirrors against those Python constants from the Desktop side.
* fix: resolve subagent control authority from the live session slot
Subagent list/tail/steer/interrupt authorized against a per-record copy of
the owning session's transport (`owner_transport`). That copy had to be
re-synced at every reattach site; `_rebind_live_transport` did it for
session.resume/activate but prompt.submit and the queued-prompt drain still
attached bare, so a client that reconnected through a prompt (the common
path on a remote gateway / Bot Mode switch) streamed fine while
`subagent.list` returned [] and controls rejected.
Read `owner_session_record["transport"]` at check time instead: the slot is
already mutated by every attach/detach/viewer-failover path, so no site can
forget the sync. `owner_transport` stays as the capture-time "commissioned
by a gateway session" marker (None = no RPC authority ever); non-dict owners
keep the exact-object rule. Drops the registration-time re-read and the
attach-time registry loop.
Diagnosis credit: nftpoetrist (#106663) — their prompt.submit / drain
regression tests pass against this change with no call-site edits.
* feat(memory): carry the turn's author into the memory-provider contract
`on_turn_start` documents a per-turn kwargs channel — "kwargs may include:
remaining_tokens, model, platform, tool_count" — and `MemoryManager`
forwards whatever it receives. Its only caller passed nothing, so a memory
provider had no way to learn who wrote the turn it was being told about.
Providers that key durable state on identity resolve one identity when the
session is created. A shared session does not work that way: threads are
shared by default (`thread_sessions_per_user` is False), so alice, bob, and
another agent all write turns into a session whose peer is whoever spoke
first. The gateway's answer today is the `[name]` prefix it prepends to the
message text, which the model reads and a provider cannot.
`turn_author` now travels from the gateway through `run_conversation` into
`build_turn_context`, which forwards `author_id`, `author_name`, and
`author_is_bot` to every provider. It stops there — the trio never reaches
the model, and providers that ignore the kwargs are unaffected.
The bot flag is sent on every transport, not only shared sessions: a
provider deciding whether a turn may write to durable memory needs it in a
DM too.
`SessionSource.is_bot` is only as good as its producers. `build_source`
defaults it to False and 3 of 32 adapter call sites pass it, so most
platforms still report every author as human. Populating the rest is
follow-up work; nothing here depends on the flag being right yet.
* feat(memory): carry the turn's author to sync_turn
on_turn_start already received the author trio. sync_turn did not, so a
provider that wanted to write the turn under its author had to stash state
between the two hooks. sync_turn now takes turn_author as a keyword-only
argument, and MemoryManager sends it only to providers whose signature
accepts it, so existing providers keep working unchanged.
build_turn_context resets the author on the agent at the start of every turn
so a cached gateway agent never carries a bot author into the next human
turn. agent/turn_author.py holds the parsing and the HERMES_TURN_AUTHOR
carrier.
MemoryProvider.identity_signature() is a new optional hook: the identity
values a provider writes under, declared by the provider itself, for the
gateway's agent cache to key on.
* feat(gateway): bust the cached agent on provider-declared identity values
_extract_cache_busting_config knew one memory provider by name and imported
its config class to read identity keys. it now also asks the configured
provider for identity_signature() through plugins.memory.load_memory_provider
and merges the result under "memory.<key>". the hardcoded block stays until
that provider implements the hook.
* feat(bot-mode): carry the sender through local and relay deliveries
a bot dm arrived as an ordinary user message. the only trace of the sender
was the "Message from" text prefix, which the model reads and nothing else
does. the recipient's memory provider saw its own configured user.
message_agent now passes the sender as {"id": "bot:<profile>", "name":
<handle>, "is_bot": true} to the delivery runner (--author <json>), which sets
HERMES_TURN_AUTHOR on the recipient one-shot only. the -Q turn reads it and
passes turn_author into run_conversation. the desktop relay forwards the
envelope's from_profile/from_handle to bot_relay.deliver, which sets the same
variable on its delivery turn. the runner drops any inherited author first so
a delivery without one stays unattributed. the text prefix is unchanged.
* feat(api): accept a turn author on session chat and runs; peer dm forwards it
POST /api/sessions/{id}/chat, /chat/stream and /v1/runs take an optional
"author" object. absent or null keeps today's behavior; a non-object is a 400
invalid_author. the value reaches run_conversation as turn_author and nothing
else: it is a claim by an API-key holder and grants no capability.
hermes peer dm and peer run add the author to the request body when the
message_agent runner launched them with HERMES_TURN_AUTHOR set, so a
cross-machine dm is attributed the same way a local one is.
* fix(gateway): add bot-to-bot loop guard for Telegram
Telegram Bot API 10.0 (2026-05-08) lets bots receive messages from other
bots, and the platform ships no loop guard of its own. core.telegram.org
/api/bots/bot-to-bot ("Loop prevention") requires the BOT to make
bot-message handling terminate predictably via dedupe, per-chat rate
limits and maximum interaction depth, and warns that "failure to handle
loops properly may lead to degraded performance or platform
restrictions".
Hermes had no brake at all: TELEGRAM_ALLOW_BOTS in gateway/authz_mixin.py
was a bare `return True` with no counter, window or cooldown.
TELEGRAM_ALLOW_BOTS=mentions does not help, because when bot A replies to
bot B the reply itself satisfies the mention test, so every turn re-arms
the peer. Observed 2026-08-21: two Hermes bots exchanged 132 messages in
one group before a human intervened.
This adds gateway/bot_loop_guard.py, a thread-safe sliding-window budget
with cooldown and sweeping of stale buckets, wired into
_is_user_authorized. Defaults (20 events / 60 s window / 60 s cooldown)
match the OpenClaw reference implementation.
Two placement details that are easy to get wrong:
- The guard runs BEFORE the TELEGRAM_GROUP_ALLOWED_CHATS shortcut. That
env var returns True for any sender in an allowlisted chat, bots
included, ~32 lines before the is_bot block, so a guard placed in the
is_bot block never executes for the one configuration that needs it.
- The budget is keyed per CONVERSATION, not per (sender, receiver). This
process only sees inbound messages, so the receiver is constant; keying
on the pair would give each sender its own budget and N bots would need
N x budget messages to trip a guard meant to cap the whole exchange.
Installations without ALLOW_BOTS are byte-identical in behaviour: the
guard only runs on the source.is_bot branch with ALLOW_BOTS set to
mentions or all. HERMES_BOT_LOOP_PROTECTION=off is a full kill switch.
Adds tests/gateway/test_bot_loop_guard.py (7 cases), each verified
failing against the tree without this patch.
* fix(gateway): loop guard judges the final authz verdict and reads config.yaml
#91483 added the guard inside the ALLOW_BOTS block. on today's authz layout
an admitted bot returns from an earlier rule before that block runs, so the
guard never tripped (its own ping-pong test passes turn 21 on this tree).
_is_user_authorized now computes the allowlist verdict first and runs every
admitted bot-authored message through the guard, so bots admitted by a chat
allowlist, allow-all, pairing or delegation are metered too. the budget stays
per conversation. settings move from HERMES_BOT_LOOP_* environment variables
to config.yaml gateway.bot_loop_guard (defaults added to config_defaults),
re-read on every call. an unauthorized bot dm no longer gets a pairing code,
so a cooldown produces no outbound traffic. tests rebuilt against real
SessionSource objects.
* fix(gateway): count each bot message once in the loop guard and consume the author variable
The Telegram adapter asks the authorization check before dispatch, the ingress gate asks it
again, and the busy path asks a third time. Each call counted one loop-guard event, so a
Telegram bot tripped the budget after a third of the configured messages. The verdict now only
refuses a chat that is cooling down. The ingress gate counts an admitted bot message once.
`parse_turn_author` treats only booleans, integers and the strings true/1/yes as a bot flag,
and returns None for an author with neither id nor name. Names keep format characters and
non-breaking spaces so emoji sequences survive. The quiet one-shot pops HERMES_TURN_AUTHOR
before the turn so tool subprocesses do not inherit it. `max_events` must be a whole positive
number. Issue numbers move out of code comments.
* fix(agent): pass turn_author only to a run_conversation that accepts it
The gateway turn runner and the quiet one-shot passed `turn_author=` unconditionally. Every
test double and wrapper with an older `run_conversation` signature raised TypeError, which CI
caught across twenty gateway tests. Both call sites now check the callee with the existing
`_accepts_keyword` helper. A human `-Q` turn keeps today's call shape with no author keyword.
* fix(bot-mode): carry the relay sender into a live Bot Chat turn
When the target Bot Chat is already open on this gateway, the relay handler delivers through
`prompt.submit` with `queued: true`, and that branch dropped the envelope's sender. The model
still saw the text prefix, but the turn reached the agent unattributed, the exact case the
subprocess branch fixes.
The relay handler now stamps the author on the submit as a `DeliveryAuthor`, an in-process object
a JSON client cannot build, so `prompt.submit` accepts it the way it accepts a hosted-room callback
and refuses a dict with error 4124. The busy queue keeps an authored envelope in its own slot, the
drain hands the author to the turn runner, and the runner passes it to an agent that declares the
keyword. A plain prompt after an authored dm carries no author.
Local deliveries to a desktop-owned Bot Chat take the live-owner mailbox instead. The admission
intent and the mailbox record now carry the author, a retry under the same id with a different
author is refused, and the owner gateway hands the author to the turn it runs. Isolated compute
turns still run unattributed, because the compute-host frame has no author field.
* fix(gateway): charge the bot loop budget on the busy path
_handle_active_session_busy_message only peeked at the guard, so a bot steering a running turn was never counted and the budget never tripped. The busy handler now admits the message once after the authorization verdict and marks the event. _hm_admit_event skips a marked event, so a follow-up that was queued on the busy path and drains later is not charged twice.
* fix(gateway): count bot messages under the transport profile
The loop guard peeked under the transport profile stamped on the source but counted under the routed profile's scope, so the two read different gateway.bot_loop_guard blocks. _admit_bot_message_for_source runs the count under the same _authorization_profile_home as _is_user_authorized_for_source, and both the ingress gate and the busy path call it.
* fix(bot-mode): keep authored queued DMs out of the inflight dedup
_enqueue_prompt dropped a queued entry whose text matched the live prompt without checking turn_author, and _sanitize_queued_entry_vs_inflight_user stripped the inflight prefix from any text entry. A relayed DM carries its sender, so an entry with turn_author is never treated as a self-duplicate and never prefix-stripped.
* fix(memory): pass on_turn_start kwargs only to providers that accept them
MemoryManager.on_turn_start forwarded the author kwargs to every provider and _each_provider swallowed the TypeError, so a provider with the two-positional on_turn_start(n, text) stopped running. The kwargs are now filtered against the provider's signature the way _provider_sync_accepts filters sync_turn.
* fix(bot-mode): qualify relayed authors with the sender's connection id
A relayed DM stamped bot:<profile> on the recipient turn, so an ops profile on another machine and the local ops profile shared one author id. The Desktop now forwards from_connection with each bot_relay.deliver, and delivery_turn_author builds bot:<connection>/<profile> for it while the Desktop's own gateway ("local") keeps the bare id. An api author object accepts an optional origin string that yields the same shape.
* fix(bot-mode): qualify a relayed author from the local connection too
delivery_turn_author kept the bare bot:<profile> id when the sender's connection was the Desktop's own "local", so a DM relayed from that machine collided with the recipient's profile of the same name. A relayed DM always crosses gateways, so the connection id is now part of the id whenever the Desktop sends one, and only the direct message_agent path in tools/bot_mode_dm.py stays bare. The relay.ts and session_auto_continue.py comments added earlier are cut to one line each.
* test(bot-mode): a human prompt after a relayed dm carries no author
The author travels on the queued entry and the _run_prompt_submit call, and turn_context resets agent._turn_author at every turn start. The test pins that the human prompt following a drained relayed dm reaches run_conversation without a turn_author.
* fix(desktop): keep the relay deliver timeout beside its call
relay-deliver-budget.test.ts reads relay.ts and expects RELAY_DELIVER_TIMEOUT_MS within 400 characters of the bot_relay.deliver call. The comment above the new from_connection parameter pushed it past that window. The parameter names say what the gateway does with them.
* fix(bot-mode): qualify the peer-dm author id with the sender's hostname
message_agent sent a bare bot:<profile> id through hermes peer dm, so a remote coder and the recipient's own coder shared one author id. The peer branch now sends bot:<hostname>/<profile>, with the hostname cleaned like any author field and slashes dropped. The direct local path keeps the bare id.
* fix(gateway): refuse relay sender fields from a logged-in client and say what the author trusts
bot_relay.deliver accepted from_profile, from_handle and from_connection from any admitted JSON-RPC client. The handler now refuses them with error 4095 when the calling transport carries a browser login identity, since a logged-in browser never relays for another connection. The DeliveryAuthor docstring now says the author is trusted because an admitted client relays it, not because the sender is verified.
* test(bot-mode): trim the author and loop-guard suites to their invariants
Keep one or two behaviour tests per seam (author reset on a cached agent, forged
_turn_author refused, guard trips and cools, single charge on the busy path) and
drop the parser/setting enumerations. a2a_key goes with them: nothing in this PR
reads it; the honcho follow-up that does can bring it back with its consumer.
* docs(gateway): document gateway.bot_loop_guard where ALLOW_BOTS is explained
The Discord page said there was no circuit breaker for bot ack-loops; there is one now.
Also strips two trailing blank lines left by the test trim.
* fix(agent): thread turn_author through conversation_loop.run_conversation
The facade forwarded turn_author= to the loop's public entry point, which did not
declare it: every real AIAgent.run_conversation() turn raised TypeError (16 CI
failures across provider, sidecar, cron and finite-chat suites). The PR's tests
only exercised build_turn_context directly, so the missing hop was invisible.
Adds one facade-through-loop test that goes red when the kwarg is dropped.
* feat: agent signs into sites from an encrypted local vault (CLI, browser fill, Desktop Settings)
Consolidated re-apply of #96988 onto current main. Ported from
Merit-Systems/OpenInstinct (MIT) opaque-handle autofill design: the model
sees vault handles + login metadata, the password is resolved and filled
server-side over the supervised CDP socket, and filled values are scrubbed
from every browser tool result by an unconditional redaction registry.
Rebase adaptations to the Sep-2026 facade/sibling layout:
- toolsets: one _HERMES_CORE_TOOLS entry (the browser toolset derives from it)
- hermes_cli/main.py: vault parser registered via the subcommand owner table
- file_safety: vault/ joins the _READ_DENIED_DIRS credential-dir table
- redact: registry scrub runs before the redact_secrets early-return
- browser_vault_tool: _run_browser_command now lives in browser_tool_session
* feat(vault): sign in with 1Password or Bitwarden logins, unlocked per session
The browser vault now draws from three login sources behind one handle
shape: the local encrypted vault (vault_…), 1Password Login items (op:…)
and Bitwarden Password Manager logins (bw:…). browser_vault_list aggregates
metadata across them; browser_vault_fill routes by prefix and resolves the
password at fill time only, through the manager CLI.
External managers are locked until the user unlocks them for the current
session. The new browser_vault_unlock tool (and the fill path, implicitly)
asks the surface to show a masked master-password prompt — CLI panel
(reuses the sudo panel state), TUI/Desktop via a vault.unlock.request
blocking card. The password goes to `op signin --raw` / `bw unlock --raw`
on stdin, never argv or env; only the session token is kept, in memory,
with a 30-minute idle TTL, cleared on session close or `vault.lock`.
Headless contexts (cron, webhook, api_server, -q) can never prompt: the
manager is reported as locked with unlock=unavailable_in_this_session and
fill refuses — the same posture approvals take where nobody can answer.
Config: vault.onepassword / vault.bitwarden {enabled, binary_path, …};
a 1Password service-account token skips the prompt for headless use.
RPC: vault.sources, vault.source.set, vault.unlock, vault.lock for Settings.
Tests (2, real subprocess against a fake bw; each proven red by sabotage):
headless never prompts or spawns; unlock feeds stdin only, token never
enters os.environ, fill routes by prefix and the password only reaches the
fill script.
* feat(vault): Desktop, TUI and CLI surfaces for password-manager unlock
Desktop
- Settings → Credential Vault gains a "Password managers" section: per-manager
toggle (disabled with a hint when the CLI isn't installed), Locked/Unlocked
pill, Unlock (masked master-password dialog → vault.unlock) and Lock.
Items from a manager show a source badge instead of a delete button.
- Mid-turn vault.unlock.request renders a masked card in the chat (same
contract as the secret/sudo cards: dismiss = keep locked, late answers
tolerated, blocks the composer, badges background sessions).
- i18n parity en/ar/ja/zh/zh-hant.
Ink TUI (hermes --tui): vault.unlock.request/expire overlay via MaskedPrompt;
Esc keeps the manager locked.
CLI: `hermes vault sources [--enable|--disable NAME]`; `hermes vault list`
shows the source column and names enabled-but-locked managers.
Docs: credential-vault.md covers managers, per-session unlock, and the
headless (cron/webhook/API/-q) no-prompt posture.
* fix(vault): carry the unlock prompt onto tool worker threads; honour binary_path in install checks
Live Desktop repro: the fixture model called browser_vault_unlock and got
unlock_unavailable although the renderer was interactive. tool_executor runs
handlers on a propagated worker thread; thread_context only copied the
approval and sudo thread-local callbacks, so the unlock prompt registered by
_wire_callbacks was invisible there and can_prompt_here() said nobody could
answer. The callback table in thread_context now lists every per-thread
prompt (approval, sudo, vault unlock) so a new one cannot silently drop off
worker threads again. After the fix the same turn shows the masked card and
completes.
vault.sources / `hermes vault sources` report a manager as installed when
its configured binary_path exists, not only when it is on PATH.
* fix(tui): hide the composer while the password-manager unlock card is open
Live Ink TUI repro: with the unlock card mounted, keystrokes reached BOTH the
masked prompt and the still-focused composer, so the master password echoed
in clear text in the composer row and was queued as a message. `$isBlocked`
(which unmounts the composer for approval/sudo/secret cards) did not list the
new overlay; the pet's awaiting-input predicate had the same gap. After the
fix the raw PTY stream no longer contains the typed password.
Also tightens the classic-CLI panel copy to fit an 80-column box.
* fix: adapt execute_code cell authority to the widened prompt-callback table
_callback_api() now yields (getter, setter) pairs for every per-thread prompt
(approval, sudo, vault unlock); the kernel cell captured and restored the old
fixed 4-tuple. Iterate the table so a cell carries every callback and a future
addition needs no change here. Test recorder unpacks the new shape.
Also: perfectionist import order in ui-tui interfaces.ts (CI lint).
* fix(vault): independent-review findings — vendor contracts, profile scope, transport, target binding
Bitwarden unlock now uses the CLI's documented non-interactive channel:
`bw unlock --raw --nointeraction --passwordenv VAR`, VAR set on the child
environment only (bw 2026.x rejects a piped password with "Master password
is required"). Verified against the real published binary.
Manager session tokens are keyed by (profile home, backend): a Desktop
gateway hosting several profiles can no longer reuse or lock another
profile's session. Status probes (`vault.sources`, is_unlocked) no longer
refresh the idle TTL; only real manager calls do. Gateway session teardown
locks the profile's managers (a per-session unlock ends with the session).
1Password service-account token comes from the profile-scoped secret store
(get_secret), not ambient os.environ.
`vault.source.set` no longer references a module constant (bind_module
rebinding dropped it → NameError on every Settings toggle).
Fill target binding: inspection stamps each input with a per-inspection
slot attribute; the fill resolves by stamp and requires type=password, then
strips every stamp. A DOM reflow between inspect and fill can no longer
redirect the password into a text field (reproduced in real Chrome before,
0 filled after).
Redaction boundary: no 4-char floor, CR/LF-normalized form registered
(what a text input actually stores), JSON object KEYS scrubbed in both
browser redactors; longest value first. Docs now state the real trust
model: accidental-disclosure protection, not an execution sandbox.
Desktop: the mid-turn card sends the master password through the owning
session's socket (requestForOwnedSession), never the ambient foreground
gateway; `vault.unlock.expire` clears a stale card; Settings keeps the
master password out of react-query mutation variables (ref consumed by the
mutationFn). One renderer invariant test for the routing.
* fix(vault): ownership and race findings from the second independent review
Manager tokens: lock generation fence (a Lock acknowledged while `bw unlock`
/ `op signin` is still running discards the late token); tokens record the
unlocking gateway session and are released when THAT session ends, not when
any sibling session in the profile is torn down.
1Password: OP_CONNECT_HOST/TOKEN come from the profile's scoped secret store
like the service token (Connect outranks a service token inside op), never
from the launch environment.
Vault RPCs bind params.profile (home + secret scope) so a shared remote
backend serving several profiles locks/lists/unlocks the requested one;
unknown profile → RPC error, not a crash.
Fill target: inspection stamps are `<nonce>:<index>`; a fill resolves only
its own inspection's stamps, so an interleaved second inspection can no
longer redirect A's password into a newly mounted field (real Chrome: 0
filled, both fields empty).
Desktop Settings: every RPC goes through the owner profile's socket
(requestGatewayForProfile), query keys carry (connection, profile), an owner
change closes dialogs and wipes drafts (a master password typed for A is
never submitted to B; a late list from A never paints under B), and vault.add
secrets travel in a ref consumed by the mutationFn instead of mutation
variables. Three owner-routing invariant tests on the real component.
Docs/PR body: session-scoped release, lock-race semantics, bw --passwordenv.
* fix(desktop): key the vault panel by owner instead of syncing state in an effect
CI lint: the owner-change wipe was a useEffect that reset state from a derived
value (no-restricted-syntax) — replace it with what the guide prescribes: the
mount site keys <VaultSettings> by (connection, profile), so an owner change
remounts the panel and drafts/dialogs are gone by construction. Owner test
mirrors the keyed mount; curly-brace lint in the test fixture.
* fix(browser): stop refusing credential-named query params on cloud browser/extract backends
browser_navigate / browser_exec / web_extract refused any URL whose query carried a
credential-NAMED parameter (token, signature, access_token, ...) when the backend was
a cloud provider. That is exactly the shape of magic links, OAuth callbacks and signed
CDN assets, so on Browserbase/Browser Use the agent could not finish a sign-in flow or
open an X video asset ("Blocked: URL contains a credential-like query parameter").
The floor protected nothing: the cloud browser already sees every cookie and typed
password of the session, and with the credential vault it receives the real password at
fill time. Hermes' own secrets leaking into a URL stay blocked by the value-shaped
_PREFIX_RE check (_secret_url_error), which is backend-independent. IMDS and
private-address floors are unchanged.
* fix(vault): make browser_vault_fill work on the default Browser Use backend
On the default backend (browser.backend unset → browser_exec) the vault tools were
advertised but could never fill: the CDP supervisor that carries the secret-bearing
eval is started only by the built-in browser_* session path, so _eval_js_secret
failed closed with supervisor_required and the origin pre-check fell back to an
agent-browser CLI eval against a browser browser_exec never touched.
- browser_exec now attaches SUPERVISOR_REGISTRY to the CDP endpoint it just routed
the harness to (BU_CDP_WS/BU_CDP_URL), so the fill talks to the SAME browser over
the same secret-capable WebSocket. BU direct-cloud (BU_AUTOSPAWN) exposes no
endpoint and keeps the supervisor_required refusal.
- CDPSupervisor.focus_page(origin, accept=<js>) (used by browser_vault_fill, next commits) re-attaches the page session to the
open tab on the item's origin whose DOM holds the form being filled (browser_exec
opens its own tabs; the supervisor's initial attach picks the first page target,
which is chrome://new-tab-page). browser_vault_fill uses it before the origin
pre-check with a per-kind probe (password input / card fields / address fields).
Live: evals/vault_fill_live_e2e.py drives the real browser_exec tool against Hermes'
packaged Chromium with the login page in the third tab; A/B with the attach line
disabled fails at "did not attach a supervisor", enabled fills the password into the
/login tab and card fields into the /checkout tab with every model-facing read
scrubbed.
Also: browser_vault_list/fill described the workflow as "type the identifier with
fill_input", a helper that exists only inside browser_exec code (toolset browser-use) and is
a ghost on the built-in stack. model_tools._rewrite_browser_vault substitutes the concrete
name from the session's actual tool set (`fill_input` inside browser_exec, or browser_type),
the same dynamic cross-reference pattern browser_navigate uses for web_search.
* fix(vault): cross-process store lock + fsync; profile-scoped, bounded redaction registry
Two review findings on #96988/#106480 that were still open:
- VaultStore serialized read-modify-write with a threading.Lock only. The Desktop gateway,
a CLI `hermes vault add` and a TUI slash worker are separate processes writing the same
vault.json.enc, so two adds could drop each other's items, and the temp file was renamed
into place without fsync (a crash between rename and the next sync loses the vault).
Writes now take an flock/msvcrt lock on <vault>/.vault.lock and fsync file + directory.
- The vault redaction registry was one process-global, unbounded set. Under gateway
multiplexing profile A's passwords scrubbed profile B's browser output (and confirmed to
B that those bytes exist). It is now keyed by profile home, capped at the 64 most recent
values per profile, and clearable (clear_vault_redaction_values).
Also canonicalizes payment/address payloads (PAYMENT_FIELDS / ADDRESS_FIELDS, required
fields enforced, stray keys dropped) so the checkout fill in the next commit never has to
guess a user's ad-hoc field names; the Desktop dialog already wrote these names.
* feat(vault): fill payment cards and addresses at checkout, cards behind a confirm prompt
payment and address items could be stored (CLI wizard, Desktop dialog) but nothing could
fill them: a dead surface holding real card numbers. browser_vault_fill now handles all
three kinds through the same origin-bound, supervisor-only, redacted path:
- classify_checkout_control / select_checkout_fills map WHATWG autocomplete tokens
(cc-number, cc-exp[-month|-year], cc-csc, address-line1/2, address-level1/2, postal-code,
country-name) with label/name heuristics as backup; a combined "MM/YY" control gets
exp_month+exp_year and suppresses the split fills; inspection now covers <select>
(country, state, expiry month) and the fill script picks an option by value or text.
- Every payment fill goes through request_elicitation_consent (gateway button round-trip
or CLI panel) before a byte is written; declined → payment_declined, headless sessions
are refused. A prompt injection that reaches a checkout can ask, not spend. Card values
join the redaction registry like passwords; the result lists targeted field tokens only.
- Origin is now required for every kind (CLI wizard asks; Desktop dialog always shows the
field) because a card without a bound origin is unfillable.
- The tool descriptions, docs and CLI copy drop "Phase 1 / login only".
Live (evals/vault_fill_live_e2e.py, real browser_exec + packaged Chromium): decline writes
nothing; accept fills card/expiry/CVC on the /checkout tab, leaves the email box and the
country <select> untouched, and neither the card number nor the CVC appears in any result.
browser_vault_tool also: focuses the tab on the bound origin holding the right form before the
origin pre-check (focus_page from the previous commit); tool descriptions say "the browser's
input tool" (rewritten per session by model_tools); _check_vault_available is registered
uncached because its answer is per profile (vault dir + config) and the probe is a file stat.
* fix(vault): declare tool parameters the registry understands; attach a supervisor to local built-in sessions
Found by a model-driven live run (hermes chat -q against a real login page): the agent found the
vault tools, typed the identifier, then failed twice for reasons the direct-call E2E could not see.
- The three schemas spelled their arguments `input_schema` (Anthropic shape). The registry and every
provider adapter read `parameters`, so the model was shown browser_vault_fill with NO arguments and
called it with an empty handle. Renamed; a registry-wide invariant test now fails on any schema
without `parameters`.
- A local built-in session (agent-browser --session) carries no cdp_url, so nothing ever started a
supervisor for it and the fill refused with supervisor_required. _ensure_supervisor asks the daemon
for the packaged Chromium's endpoint (`get cdp-url`, carries no secret) and attaches on demand; the
fail-closed test now pins that the daemon is only ever asked `get`, never handed an eval with the
password.
Live: same run after the fix -> browser_navigate, browser_vault_list, browser_type, browser_vault_fill,
browser_click; the test server received the correct password; landing title "Welcome"; the password
string is absent from the whole transcript.
* feat(vault): zero-setup UX — save a login on the page that needs it, managers auto-detected, one "Passwords & Logins" surface
Nobody should have to learn `hermes vault add` or find a toggle before "log into GitHub" works.
- browser_vault_save_login: when the agent reaches a sign-in page with no saved login it asks the user
on THEIR surface (CLI two-step panel on the sudo modal: identifier shown, password masked; Desktop
card with labelled Email/username + Password fields). The answer goes to the encrypted vault bound to
the page origin and is filled at once; the model gets back only the handle and identifier. Declining
returns save_declined; headless sessions get prompt_unavailable. Never a password in chat.
- Vault tools ride with the browser toolset (check_browser_requirements) instead of appearing only once
the vault has items — an empty vault is exactly when save_login is needed. browser_vault_list hints
at it when empty.
- 1Password / Bitwarden are login sources as soon as their CLI is installed; `vault.<name>.enabled`
is opt-OUT only. Settings shows Detected/Locked/Unlocked/Off/Not detected with a switch only for
installed managers; `hermes vault sources` reports detection, `--disable`/`--enable` flip the opt-out.
- Desktop nav/page renamed "Passwords & Logins"; empty state tells the user they do not need to add
anything; all five locales updated. Docs rewritten from "how it works" to "say log into X".
- New per-thread SaveLoginPrompt callback (agent/vault_backends/unlock.py) installed beside the unlock
prompt on every CLI site and the gateway bridge (vault.save_login.request/respond/expire), propagated
to worker threads via tools.thread_context.
Live: CLI PTY (real model, packaged Chromium, local login server) — panel shown, identifier + masked
password typed, server received the correct password, password absent from terminal transcript and
from every file under HERMES_HOME outside vault/. Native Electron (headless, isolated HOME/HERMES_HOME,
own Vite + CDP port) — card shown, "Save & sign in", server received the password, Settings lists the
saved item, password absent from the rendered UI.
* fix(vault): dogfood fixes — offer save-login on every backend, keep the model off passwords, bind to the login tab
Found by using the feature as a user (natural prompts, real sites, CLI PTY + native Electron), not by naming tools:
- browser_vault_save_login was registered but never offered: toolsets.py is a hand-maintained list. Added, with an
invariant test that every registered browser_vault_* tool is in the browser toolset.
- Vault tools were absent on the DEFAULT backend (Browser Use): the gate deferred to check_browser_requirements(),
which is False by design there. Gate = is_browser_use_cli_mode() or check_browser_requirements().
- The model typed a page-shown demo password with browser_type and offered to take one in chat: the vault rules
lived only on the vault tools. browser_type/browser_exec now carry a vault note when the vault tools are
present ("call browser_vault_list first … never type a password with this tool, never accept one in chat, even
if the page shows it"); the browser_exec login-wall line points at the vault instead of "ask the user".
- On Browser Use the saved item was bound to chrome://new-tab-page: the supervisor's default page session is the
daemon's blank tab. browser_vault_save_login now focuses the tab holding a password field before reading its
origin (focus_page("", accept=probe); about:/chrome: pages are never candidates). Live E2E leg added.
- Settings row: "identifier · Added <date>", origin omitted when it duplicates the label.
Live (real model): CLI on Browser Use — first visit prompts, signs in, saves; second visit fills silently; GitHub
decline (Enter or ESC) stops the agent, which refuses chat passwords. CLI on the built-in stack — same three
scenarios pass. Desktop native Electron — same three scenarios plus Settings list/remove pass. Password never in
a transcript, UI, or a file outside vault/.
* fmt(js): `npm run fix` on merge (#107545)
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* feat(honcho): write each turn under its author's peer
The manager resolved one user peer in `get_or_create` and froze it onto the
session, then `_flush_session` chose between it and the assistant peer by
role. Every user turn in a shared session landed on that one peer, so the
first person to message the agent collected everyone else's facts — and a
Honcho conclusion, once derived, is not self-correcting.
`resolve_author_peer_id` maps the turn's author onto its own peer using the
alias-then-prefix order `_resolve_user_peer_id` already applies, so an
aliased account reaches the same peer whichever turn it wrote. `sync_turn`
resolves it before starting the write thread, so a following turn cannot
retag a queued write. `_flush_session` then writes each user message under
that peer.
A shared session's roster is open — people and other agents arrive after
the session exists — so `_author_peer_for_session` joins a peer when it
first writes instead of enumerating participants at init. Joins are
remembered per session, and a failed join still writes under the right
peer, losing only the observe config.
Three cases return None and keep the session's own peer: no author named,
the author IS the session's peer, and `pinPeerName` set — that flag is an
explicit request to unify identities, so it still collapses authors in a
shared chat.
An unnamed author stays unattributed rather than defaulting to the owner.
That preserves today's behavior for the transports that send no author, so
those turns still reach the session peer; #83500 owner-gated the memory-file
migration for the same reason.
Display names never become peer IDs — they are attacker-influenceable on
any platform where participants set their own name.
* fix(honcho): read the turn author from sync_turn and treat the alt id as the session peer
sync_turn only knew the author through the on_turn_start stash. The memory
manager now passes turn_author and scope with the turn, and a caller
that skips on_turn_start left the stash empty or stale.
sync_turn takes both keywords and reads the author from turn_author first.
The stash stays as the fallback for callers that never pass it.
resolve_author_peer_id compared the author against the primary runtime id
only. A transport that names the participant by the alt id (Telegram
username instead of UID) got a second peer for the same person. Either
runtime id now counts as the session's own participant.
* feat(honcho): map bot authors onto their profile peer
The bot-mode dispatcher names another profile as bot:<profile>. The
resolver treated that like a human runtime id, so a configured
runtimePeerPrefix produced peers like telegram_bot:coder and a profile
that already owns an AI peer in the same workspace got a second one.
A bot:<profile> author now resolves in this order: a userPeerAliases entry
for the full bot id, else the sanitized profile name. A cloned profile's
aiPeer defaults to the profile name, so a same-workspace sender lands on
its existing AI peer. Prefixes never apply to bot ids. pinUserPeer still
collapses bot authors onto the pinned peer, the same as every other author.
* feat(honcho): declare identity_signature and drop the gateway's honcho keys
The gateway agent cache read honcho.json itself through a honcho-named
block in gateway/run.py and gateway/run_agent_cache.py. Every other memory
provider had no way to bust the cache when its identity mapping changed.
HonchoMemoryProvider.identity_signature() now returns the same values under
provider-neutral keys: user_identity, agent_identity, pin_user_identity,
runtime_identity_prefix, user_identity_aliases, session_prefixing. The
gateway files them under memory.<key> through the MemoryProvider hook. The
hook reads config only, memoizes on the file's mtime and size, and returns
an empty dict when the file cannot be read.
The honcho-specific extractor, its memo and its key tuple are gone from the
gateway. The pinPeerName cache-busting test now asserts on
memory.pin_user_identity.
* feat(honcho): write bot dms into their own a2a session
A DM relayed from another Hermes profile ran as a turn in the recipient's
Bot Chat session. sync_turn wrote the bot's words and the recipient's reply
into that session, and before per-author writes they landed under the
human's peer. The human's representation absorbed conversations the human
never had.
The turn context now marks such turns with scope a2a:<bot id>.
sync_turn routes a bot-authored turn into a separate Honcho session keyed
<session>:a2a:<sanitized bot id>, created with the sender bot as its user
peer, and never writes it into the human's session. The key is deterministic
so every turn from the same bot reaches the same session, and it stays
inside Honcho's 100 character session id limit. Recall still reads the
human's session only.
a2aSessions (host block, then root, default true) turns the routing on.
With it off, bot-authored turns are skipped. A bot turn that names no
author id is skipped as well, because nothing can key its session. Human
turns are unchanged.
get_or_create takes a user_peer_id override so the a2a session's roster is
the bot and the assistant, not the runtime human.
* docs(honcho): document a2aSessions and bot dm attribution
* fix(honcho): pinUserPeer collapses the operator's accounts, not bot authors
with pinUserPeer on, resolve_author_peer_id returned None for every author,
so a bot dm's words were written under the human's pinned peer inside the
a2a session. the pin exists to unify one person's platform accounts. a bot
is not one of them.
bot: authors now resolve to their peer before the pin check, so a pinned
operator still gets bot speech attributed to the bot.
* fix(honcho): every bot author gets its own peer or its turn is skipped
A gateway platform marks a bot sender with its raw user id and a bot flag, never a `bot:` id.
`resolve_author_peer_id` treated that author as a human, so `pinUserPeer` collapsed a bot onto
`peerName` and an unresolved peer opened the a2a session under the human's peer. The resolver now
takes `is_bot` and gives every bot its own peer. `sync_turn` skips the turn when no peer resolves
or when the peer equals this agent's `aiPeer`.
The a2a session key carries an eight-character digest of the author id, so two ids that sanitize
alike stay in separate sessions. During a bot-authored turn `honcho_conclude` and `honcho_profile`
refuse writes and the built-in memory mirror is skipped, because conclusions and cards describe
the human. The README paragraph on bot DMs now matches the code.
* refactor(honcho): name the a2a session from core's a2a_key
The plugin spelled the `a2a:` prefix itself. `agent.turn_author.a2a_key` is the shared name
for a bot author's turns, so the session key now derives from it and every reader that files
bot turns apart agrees on the prefix. The resulting key is unchanged.
* fix(honcho): derive a bot author's peer from its full id with the runtime digest rule
_peer_id_for_runtime_id now looks up userPeerAliases by the full bot id and otherwise passes everything after bot: through _generated_runtime_peer_id. A digest suffix is added when sanitizing changed the id or the result equals peerName or an alias target, so bot:eri never resolves to the operator's peer and bot:a.b stays apart from bot:a-b. The docstring and README no longer claim a cloned profile's aiPeer defaults to the profile name.
* fix(honcho): put this agent's aiPeer in the a2a session key
_a2a_session_key now names the session <session>:a2a:<aiPeer>:<sender id>-<digest>. Two profiles that share a workspace and a session key wrote one sender's DMs into one Honcho session. The recipient peer comes from the same aiPeer derivation the session builder uses, moved into session_peers.assistant_peer_id_for so the two cannot drift.
* fix(honcho): include the workspace in identity_signature
identity_signature now carries cfg.workspace_id. The gateway folds these values into its agent cache key, and a workspace change in honcho.json reused a cached agent that was still bound to the old workspace.
* test(honcho): cover bot:<connection>/<profile> authors end to end
Two senders named coder on different connections get different peers and different a2a sessions, and a userPeerAliases entry keyed by the full connection-qualified id wins.
* fix(honcho): a bot author never lands on the session's human runtime peer
_generated_runtime_peer_id takes a reserved set, and the bot path passes the session's human peer ids: each runtime id and the peer _resolve_user_peer_id returns for the key. bot:coder with a runtime human coder and no runtimePeerPrefix now gets the digest suffix. _explicit_user_peer_ids keeps its meaning for prefixed runtime users.
* fix(honcho): read an author join's observation flags through one manager method
The join read the manager-wide user_observe_me and user_observe_others directly. It now asks _join_observation_flags(honcho_session_id), which returns the same values today. #103889 stores the effective flags per session and replaces the body of that method.
* fix(honcho): bound the joined author peer memory by session count
_joined_author_peers kept an entry for every honcho session the manager ever wrote to. It now holds at most _SESSION_CACHE_MAX_SIZE sessions and drops the oldest past that, so a forgotten session's authors rejoin on their next write. A failed join no longer leaves an empty entry behind.
* fix(honcho): include a2aSessions in identity_signature
sync_turn reads a2a_sessions from the config bound when the provider was built. A cached gateway provider kept the old value after honcho.json flipped it, because the signature that busts that cache did not carry the flag.
* feat(agent): a2a_key names a bot author's turns
Dropped from the #103888 salvage for lack of a consumer; the honcho a2a
session key is that consumer.
* test(honcho): trim the author-peer suites to their invariants
Keep the isolation contracts (bot never on the human peer, bot turn never in the
human session, writes refused mid bot-turn, one join per author, signature busts
the cache) and drop the alias/prefix/sanitize enumerations. 795 -> 454 lines.
* docs(honcho): document a2aSessions and per-author writes on the site page
* Seeded sessions survive a gateway restart and store their seed once (tui_gateway) (#107549)
* fix(tui-gateway): a seeded session is durable at create, and its seed is written once
session.create accepts opening messages. Three defects sat in that path:
- A seeded session without a parent was never persisted at create, so a
restart before the first prompt lost it and session.resume answered
4007. Only branch children (#93959) were persisted up front. The
same rationale applies to any seeded create: seeded content is
intent, not an abandoned draft. Parentless seeds now persist their
row, transcript and client title at create; empty drafts stay lazy.
- _coerce_seed_history dropped display_kind, so a seeded row tagged
"hidden" (model-facing scaffolding) rendered as a user bubble. The
coercion keeps "hidden" and only "hidden"; every other kind is
stamped by the gateway at turn time and is not accepted from the wire.
- A branch child's seed was written twice: _seed_branch_row copied it at
create but never marked it persisted, so the first prompt's
_persist_branch_seed appended the copy again. The create path now
sets _branch_seed_persisted, and the gate is a create-time `seeded`
stamp instead of parent_session_id, so a resumed session (whose
history comes from the DB) can never re-append its transcript.
Two invariant tests, both red on main: a parentless seed survives a
gateway restart with the hidden row kept out of the wire transcript and
not re-written by the first-submit path; a branch child's seed is stored
exactly once. The reasoning-fields fixture stamps `seeded`, the flag
session.create sets.
* fix(tui-gateway): a hidden seed row stays out of the list preview and the create count
Live-testing the seeded create on every surface showed two places where
the newly durable hidden row (display_kind="hidden") still surfaced:
- session.list built a session's preview from its first user row with no
display_kind filter, so a hidden opening row (model-facing scaffolding
the gateway never paints) became the sidebar preview. The preview
predicate now skips hidden rows, in every listing query that shares it.
- session.create reported message_count as the raw seed length while its
messages array already filtered the hidden row (2 vs 1). It now counts
what is on the wire, the same rule session.resume applies.
Both are covered by the existing seeded-create test: the create count
equals the wire transcript, and the preview of a session whose first
user row is hidden is its first visible user row.
* fix(tui-gateway): a live unpersisted resume counts the wire transcript
session.resume on a live session that has no row yet reported message_count as
the raw history length while its messages array was already filtered, the same
mismatch the previous commit fixed on session.create. Count the wire, as the
cold, deferred and reuse-live resume paths already do.
* chore: retrigger CI (zero-job dispatch failure, auto-heal)
* fix(tui-gateway): a hidden seed row stays out of search, a partial seed copy is rolled back, live resume counts the wire (#107562)
Two independent reviews of the seeded-create change found three more
places where the newly durable hidden row, or the new create-time copy,
was not handled by the same rule as the rest of the path:
- Message search (dashboard search and the session_search tool) had no
display_kind filter, so a hidden opening row matched a query the
person never saw. The shared search predicate now skips hidden rows.
- _seed_row left the fresh session row behind when the transcript copy
failed after the row was committed. The first prompt's retry copies
the whole seed, so a kept partial copy would be duplicated. The row
is now deleted when the copy did not complete, the compensation
_persist_branch applies to branch children; the first prompt then
starts clean.
- _live_session_payload (a resume that reuses a live session) reported
message_count as the raw history length while its messages array was
filtered. It now follows _resume_response: the stored size when
messages are omitted, else the wire count.
Tests: the two seeded-create tests now drive the first-submit path
through _persist_session_row_for_submit, the function prompt.submit
calls, and assert search and the reuse-live count; a third test pins
the rollback (no row after a failed copy, one copy after the retry).
* fix(desktop): kill the PATH probe child on timeout
* test(desktop): verify PATH probe child kill on timeout
* test(gateway): pin overflow reply when a failed 400 still has text
* fix(gateway): keep session-too-large reply when a failed 400 still has text
* fix(gateway): one context-overflow verdict for the reply and the transcript skip
Moving the `if response` guard below the failed branch exposed the normalizer's
loose overflow predicate (bare "token"/"exceed"/"context"/"payload", or any 400
on a long session) to failed turns that carry real text: billing, rate-limit,
auth and content-policy replies were rewritten to "Session too large / /compact".
Hoist run_turn's stricter classifier (compression_exhausted, multi-word phrases,
400 on history > 50) into a module-level `is_context_overflow_failure_result` and
use it for both the #1630 transcript skip and the user-facing rewrite, so the two
can never disagree. Populated text is only rewritten when it is the bare provider
envelope (`_looks_like_gateway_provider_error`) on an overflow turn; curated agent
text (compression-timeout guidance, /compress hint) survives. Replaces the
sanitizer-wording test with the passthrough invariants that catch the regression.
* test(gateway): exercise the shared overflow classifier instead of a copy
test_7100 replicated the phrase list inline, so it tested its own copy rather
than production; point it at is_context_overflow_failure_result. Drop a dead
`error=` parameter from the normalizer test helper.
* fix(desktop): show each in-app tip once, never lap the catalog again
The idle tip rotation walked the catalog as a ring: after the last tip it
wrapped to the first, so a user who had already seen every tip kept
getting "Start fresh", "Teach it once", ... again every six hours for as
long as they used the app. Only the X stopped a tip, and letting a bubble
time out (the normal way it leaves) counted for nothing.
The walk is now one lap. nextTip also steps over every tip in the seen
ledger ($tipShownAt, which already recorded every catalog tip that
reached the screen), so a tip shows once however it left, and the
rotation runs dry once every tip has had its moment. Settings > Reset
clears the seen ledger and the cursor as well as the retired set, and its
button counts what a Reset would actually bring back (shown or closed,
counted once). Agent tips carry no catalog id and are untouched.
Live repro (Playwright against the worktree's Vite renderer, all nine
tips seeded as seen, clock fast-forwarded past settle + cooldown):
origin/main re-showed "Start fresh"; fixed renderer shows nothing;
a fresh user (nothing seen) still gets the first tip.
* feat(vault): two-factor codes — automatic from a saved authenticator key, otherwise asked for in the user's UI
Follow-up to #106480. Sites that ask for a code after the password stopped
the agent cold: the login classifier excludes one-time-code fields on
purpose (a password must never land in an OTP box) and there was no tool
for the second step, so the only move was to ask in chat.
browser_vault_enter_code
Fills the one-time code the current page asks for.…
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
summary
the bug, in plain english: setting
saveMessages: falsewas supposed to stop hermes from persisting conversations to Honcho. the knob was parsed but never checked — every automatic write path kept writing. separately, when Honcho activates on an install with existing local memory, hermes uploads MEMORY.md/USER.md (files that describe the install owner) into the new session under the session's user peer. in a shared channel, the first person to message the agent creates that session — so a stranger could trigger the upload and have the owner's profile attributed to them.the fix: every automatic write path now checks
saveMessagesbefore touching Honcho (reads and explicit tools still work). the migration only uploads when the session's user peer is the declared owner — thepeerNamefrom config, including platform IDs aliased onto it. with nopeerNamedeclared, it uploads only on the single-operator CLI path, where no gateway identity exists; nobody reachable through a gateway can silently receive the owner's files.sync_turn,on_memory_write,on_session_end,shutdownflush) onsaveMessages; read/tools paths untouchedsync_turnthroughmanager.save()sowriteFrequencybatching modes actually applymanager.shutdown()(flush + join writer thread) when persistence is on, or a newmanager.stop_async_writer()(join only, no flush) whensaveMessagesis false — containment and clean teardown composepeerName(aliases onto it still count), and with nopeerNamethe migration only runs when no runtime gateway identity is presentcommits
adopted with original authorship, follow-ups separate:
peerName(an earlier revision re-resolved the session's own peer id, which compares the triggering user to themselves and passes for non-owners)closes / supersedes
verification
tests/honcho_plugin/(12 files),tests/test_honcho_*,tests/agent/test_memory_manager.py, including 9 new saveMessages tests, 15 containment/startup tests, non-owner migration test, stop-without-flush writer testgit diff --checkclean, linear history on mainthanks @dtownsel, @strzhao, @Matroskin86, @Yahome, @menhguin, @starship-s, @Diaspar4u for finding and working these.