2466 Commits

Author	SHA1	Message	Date
Teknium	cbd03e6e4c	fix(gateway): secondary-profile adapters no longer inherit the default's allow-all / allowlists ... Under gateway.multiplex_profiles, os.environ holds the DEFAULT profile's .env. Several adapter-owned authorization gates still read GATEWAY_ALLOW_ALL_USERS, GATEWAY_ALLOWED_USERS or their platform allowlist/allow-all raw from os.environ, so the default profile opting into open access opened every secondary email/QQ/WhatsApp/Matrix/Teams/Slack/LINE/DingTalk bot to any sender (email additionally skipped From: authentication), the default's Matrix allowlist decided who may approve tool calls on a secondary bot, and a secondary that opted in only in its own .env was silently deny-all. Every such read now goes through the adapter's existing module-local scoped reader (gateway.platforms._shared.get_scoped_secret / matrix _startup_env_secret): profile scope first, scoped miss = default, never os.environ; the unscoped default-profile and single-profile paths keep the environ read, where it IS the profile's own value. Sites: email _allow_all_senders/_allowlist_in_effect; qqbot _open_dm_opted_in; whatsapp_common _open_dm_opted_in/_live_dm_allow_from; teams _card_action_denied; matrix _is_authorized_user, MATRIX_ALLOWED_USERS, MATRIX_IGNORE_USER_PATTERNS, _extra_csv_set (allowed/free-response rooms); slack _slack_allow_bots/_slack_api_human_users; line _truthy_env/allowlist (allow-all, user/group/room allowlists); dingtalk _extra_get (allowed_users/chats, free-response chats, require_mention). Live repro (temp HERMES_HOME, multiplex on, default env GATEWAY_ALLOW_ALL_USERS=true, secondary scope without opt-in): EmailAdapter._allow_all_senders() True -> False, QQAdapter._open_dm_opted_in() True -> False, Matrix _is_authorized_user('@stranger') True -> False, Teams card action allowed -> denied. Co-authored-by: Drexuxux <drexux0@gmail.com> Co-authored-by: MoonsvnLyn <FirmamentalSpring@users.noreply.github.com> Co-authored-by: svector-anu <anuoluwakolapo94@gmail.com> Co-authored-by: babatorik <durgun.ismail@gmail.com> Co-authored-by: salch-cred <salch-cred@users.noreply.github.com>	2026-09-11 02:24:55 -07:00
Teknium	94fb74fa97	docs(bot-mode): explain Warm Bot Backends, idle reaping, and slot waits ... Fleet users read "Hermes backend for profile X exited (1)" as a crash and raise Warm Bot Backends past their profile count to make it stop. Name the setting, the defaults, what the exit line means, and which operations take a slot so the knob is tuned for active bots instead of total profiles.	2026-09-11 02:23:29 -07:00
Teknium	fc3d60af09	feat(compression): provider-scoped model_thresholds keys ("<provider>:<substr>") ... A bare `astra: 0.85` in compression.model_thresholds was written for the Codex OAuth route, where Astra is capped at 272K and 50% would compact at ~136K. The key is substring-matched on the model name alone, so it also fired on openai/gpt-6-astra via OpenRouter and Nous, where the window is 1.1M: the user's 0.5 global threshold was silently replaced by 0.85 and the session sat at 620K (~59%) without compacting. Keys may now carry a provider prefix: `"openai-codex:astra": 0.85` applies only when the session's provider is openai-codex; bare keys keep their route-agnostic behaviour. Ranking is by model-substring length with scope as the tie-break, so `astra-900k` still outranks `openai-codex:astra` for the 900K picker. The provider flows through ContextCompressor (ctor + update_model), the ContextEngine base class and the TUI hot-reload path, so a /model switch between routes re-scopes the override.	2026-09-11 02:07:48 -07:00
shannonsands	a6ee31f55a	feat(wisdom): add Hermes Collective Wisdom Agent V1 (#94266) ... * feat(wisdom): add trusted publish and install foundation * feat(wisdom): add private contribution loop * feat(wisdom): add managed consumption workflows * fix(wisdom): close cross-repository safety gaps * fix(wisdom): align local package and lifecycle policy * fix(wisdom): require explicit profile setup * docs(wisdom): repin reconciled gateway head * fix(wisdom): fence content downloads and approval receipts * docs(wisdom): record generation-fenced downloads * docs(wisdom): record unified delivery PR * fix(ci): stop passing invalid classifier inputs * docs(wisdom): remove internal requirements ledger * feat(wisdom): localize dashboard and desktop copy * feat(wisdom): complete local contribution and consumption UX * style(wisdom): satisfy desktop lint * chore(wisdom): refresh requirements pin * test(dashboard): allow formatted profile copy * test(wisdom): stabilize desktop interaction coverage * fix(wisdom): surface dashboard action failures * fix(wisdom): add repeatable Portal demo login * feat(wisdom): add actionable skill notifications * feat(wisdom): add notification install and update actions * fix(wisdom): make Telegram skill alerts actionable * fix(wisdom): always refresh demo Agent login * feat(wisdom): embed Telegram notification actions * fix(wisdom): preserve Telegram notifications after actions * fix(wisdom): keep Telegram notification cards readable * feat(wisdom): add Telegram candidate approval flow * feat(wisdom): explain Telegram qualification reasons * fix(wisdom): reconcile cross-surface candidate actions * feat(telegram): add Collective Wisdom management command * chore(wisdom): refresh Gateway contract pin * chore(wisdom): advance Gateway contract pin * feat(wisdom): align command UX across clients * feat(slack): add Collective Wisdom management parity * feat(wisdom): add security and professionalism reviews * feat(wisdom): add first-time qualification guidance * feat(wisdom): simplify qualification sharing choices * feat(skills): add optional editorial metadata * feat(wisdom): enrich legacy skill presentation * fix(wisdom): harden review and update boundaries * fix(wisdom): emit canonical review timestamps * fix(wisdom): align with merged gateway and main * wisdom: add agent-led sharing core (policy, evidence, schemas, templates, delivery, weekly job, share/install flows) - hermes_wisdom/agent_led/: policy resolution (server > local > defaults), 7-day evidence builder that excludes bundled/hub/managed skills and dismissed/handled/recently-suggested content hashes, strict pydantic schemas for agent output with repair-or-reject, fixed copy templates (Share / Teammate / Published / Update / Mute), idempotent retried delivery ledger with stale-action resolution, weekly review job, resumable Share and Install flows. - prompts/: candidate review, recipient recommendation, share packaging. - tests/wisdom/test_agent_led.py: 30 tests. * wisdom: agent-led renderers and button action dispatcher - render.py: Telegram HTML, Slack blocks, Desktop payload; editorial name is the emphasized line, product label stays separate. - actions.py: resolve opaque wa:<action>:<dedup> targets via the delivery ledger; Not now -> dismissal, Mute -> fixed options, Share -> resumable packaging flow, Install/Update -> plan command. Never publishes/installs. * wisdom: CLI verbs, agent_led config default, conversational catalog skill - hermes wisdom browse/review-week/act/share/dismiss/mute (all --json). - wisdom.agent_led config block, default enabled. - SKILL.md rewritten so natural-language catalog questions map to the CLI verbs, share/install flows and fixed notification templates. * wisdom: wire agent-led weekly review into gateway tick and Telegram buttons - gateway housekeeping tick calls maybe_run_weekly_review with a home channel sender when a Telegram adapter is available. - Telegram: wa: callbacks resolved through the ledger (stale-safe), mute duration keyboard, send_wisdom_agent_recommendation rich card + fallback. * fix(wisdom): integrate local mediation and harden model and setup boundaries * fix(wisdom): honor authoritative recommendation policy and defer on failure * fix(wisdom): synchronize opaque suppression and recheck delivery preferences * feat(wisdom): route weekly selection through the session-owned assessment queue * fix(wisdom): prepare and submit the reviewed generated share package * feat(wisdom): separate native Share preparation from publication consent * feat(wisdom): sync native mute choices through a leased preference outbox * feat(wisdom): bind native mute controls to durable preference choices * feat(wisdom): add scoped desktop and dashboard notification settings * fix(wisdom): revalidate feed recommendations before assessment and delivery * fix(wisdom): persist validated delivery receipts before completing notices * feat(wisdom): add private notification claim and receipt client * Persist Wisdom send reservations and recover delivery acknowledgements * Route legacy Wisdom controls through current native review * Add typed private Wisdom operation outcome client * fix(wisdom): make agent-led advice usable in the local demo * fix(wisdom): keep requested consent outside proactive limits * fix(wisdom): distinguish unavailable assessments and preserve digest text * fix(wisdom): assess ongoing usefulness beyond the current task * fix(wisdom): restore immediate qualification sharing controls * fix(wisdom): separate qualification review from installation advice * fix(wisdom): collapse review checklists and simplify sharing copy * fix(wisdom): show compact sharing progress and publication receipts * fix(wisdom): require credential prefixes rather than matching skill names * fix(wisdom): finish package checks before presenting sharing consent * fix(wisdom): scan local skills before qualification cards * fix(wisdom): update moderation results on existing sharing cards * fix(wisdom): keep sharing review accessible from receipt cards * fix(wisdom): align mediated review cards and collapsible checks * fix(wisdom): clarify clean security summary wording * fix(wisdom): normalize consent plans and add explicit recheck * fix(wisdom): keep install and update receipts concise * fix(wisdom): collapse assessments and deduplicate operation cards * fix(wisdom): restore private Portal review from native cards * fix(wisdom): sync Portal publication to original consent card * fix(wisdom): show local skill version on sharing cards * fix(wisdom): skip agent recommendations for self-published versions * fix(wisdom): simplify candidate notices and local-edit recovery copy * feat(wisdom): submit locally reviewed packages with one confirmation * feat(wisdom): expose safe receipt and outcome sync recovery * wisdom: onboarding notice says detect and share, names the user's own skill Copy review from the product owner on the first and returning qualification notices (fixed delivery mode): - the feature blurb now says the org enabled detection *and sharing* - both notices say the detected skill is one the user created - both close with an exclamation mark Applied identically to hermes_wisdom.notice, the desktop and web i18n strings, and the tests that assert the sentences. * wisdom: one opener, no approval line, ask to share after the skill is shown Product owner review of the candidate card. - The Hermes written card now opens with the same sentence as the fixed card ("Your organisation has enabled Collective Wisdom, a feature designed to automatically detect and share useful skills across all team members.") instead of its own blurb, so there is one first time message. - "Nothing is shared without your approval." removed from Telegram, Slack and Desktop. The buttons already make the permission explicit. - "Would you like to share?" no longer appears before the skill is named. It is now the last line, after the skill name, description, why suggested and the checks, and reads "Would you like to share it?" (matching the agent led template wording). Tests updated for the new order; proposalNotice removed from all desktop locales. * wisdom: American spelling, organization Product owner decision: user facing copy uses American spelling. Changes "Your organisation" to "Your organization" in the chat notice, the Hermes written card opener, the desktop and web strings, and the tests that assert them. Identifiers such as nas_organisation:* and the German and French locales are untouched. * wisdom: candidate card copy round 4 (owner review) Apply the product owner's round 4 copy decisions to the Hermes Collective Wisdom candidate card on Telegram, Slack, Desktop and the shared views: 1. Hermes-written cards are titled "Hermes Collective Wisdom" instead of the bare "Collective Wisdom". 2. The "Reusable skill ready to review" line is gone from the candidate card (Telegram rich card and plain fallback, legacy agent-led share template). 3. The skill name and description are labelled: "Skill name: <name>" and "What it does: <description>" (Telegram, Slack, Desktop). 4. "Why suggested:" is now "Why others might benefit:". 5. A passing professionalism review reads "Safe to share at work ✓ (no inappropriate content found)" with no per-check bullets and no "Pass"; a failed review reads "Needs a look before sharing at work (possible inappropriate content)" and lists only the checks that flagged something. Pending/unavailable wording is unchanged. 6. Telegram button toasts: "Will ask later...", "Preparing more details...", "Sharing...". 7. Qualification reasons: "You used this skill consistently across many days." and "You've really refined this skill." 8. prompts/wisdom_candidate_review.md asks for a compelling editorial_name, a simple one_line_description and a compelling why_coworkers_benefit under 300 characters; "Be concise and convincing." becomes "Be concise and compelling: the goal is that the user wants to share it." Tests updated for the new strings; review_text() gains direct coverage. * wisdom: re-apply owner copy after rebase - Native share cards (advice_view/interaction_view): drop the approval line, ask "Would you like to share it?" as the last line after the checks - Hermes-written completion card titled "Hermes Collective Wisdom" - Qualification reasons use the owner wording (consistently across many days / really refined) - American spelling (organization) in remaining English copy - Desktop test asserts the current Share button; web test matches the returning notice * fix(wisdom): pin reconciled Gateway and verify Unicode hash vectors Pin Gateway 60cd2d6b613ae3cd4a6e65155d1142006d907e78 and byte-identical producer artifacts. Verify every content-order case and package-manifest binding. Validation: 186 focused Python tests, Ruff and contract verifier. * fix(wisdom): reconcile optional SDK tests and frontend lint * fix(wisdom): default to agent-written notification summaries * fix(wisdom): restore deferred install review and browse controls * feat(wisdom): inspect installed setup with exact package provenance * feat(wisdom): run native-approved installed setup steps with durable evidence * fix(wisdom): recover interrupted setup with explicit native consent * feat(wisdom): hand native installs into guided setup review * fix(wisdom): continue requested setup with fixed notification copy * fix(wisdom): preserve setup while waiting for a session model * fix(wisdom): expose canonical setup review controls on desktop * fix(wisdom): resume setup after recorded automatic updates * fix(wisdom): make missing setup prerequisites recheckable * chore(wisdom): align Agent with verified Gateway contract * fix(wisdom): stop guessing team slugs in portal links * fix(wisdom): retire pending advice on account sign-out * fix(wisdom): cancel advice after terminal account revocation * fix(wisdom): fence feed responses across account sign-out * fix(wisdom): checkpoint signed-out feed before reactivation * fix(wisdom): link proactive advice to scoped notification settings * fix(wisdom): coalesce queued publication recommendations by version * fix(wisdom): keep package review navigation local and deferable * fix(wisdom): reflect installed state in discovery controls * fix(wisdom): show exact checks before command confirmation * chore(wisdom): pin bounded analytics privacy contract * chore(wisdom): pin retired legacy notification contract * feat(wisdom): review publisher usage with exact sharing copy * fix(wisdom): align discovery and review check summaries * fix(wisdom): show expired consent before confirmation * fix(wisdom): require fresh review for legacy install controls * fix(wisdom): preserve review expiry across check toggles * fix(wisdom): retain update policy in native install reviews * fix(wisdom): surface failed native card edits * fix(wisdom): persist local command approval reviews * fix(wisdom): use saved approvals for messaging commands * test(wisdom): provide scan result in setup handoff fixture * test(wisdom): exercise Telegram approvals with saved review state * fix(wisdom): retain suppression policy for offline deferral * fix(wisdom): reconsider candidates after deferred suppression expires * fix(wisdom): bind review checks and report verified readiness separately * fix(wisdom): persist accepted publication intent and recover exact outcomes * fix(sync): pin UTF-8 tree ordering across writers * chore(wisdom): pin organisation-scoped Gateway authorization * fix(wisdom): restrict consent delivery to user-facing sessions * chore(wisdom): refresh reviewed Gateway contract pin * fix(wisdom): preserve kept tools in Blank Slate exclusions * test(auth): reset anonymous fixture with a profile-scoped cache * fix(wisdom): gate local surfaces and work on current profile entitlement * fix(wisdom): invalidate quiet tool cache on entitlement changes * test(wisdom): authorize local consent gateway fixtures * fix(wisdom): keep entitlement decoding free of native crypto imports * test(wisdom): provide local entitlement to demo CLI subprocess * ci: leave upstream workflow unchanged in Wisdom PR * fix(wisdom): ship package and contracts in Nix wheels --------- Co-authored-by: hbizi <36184542+hbizi@users.noreply.github.com>	2026-09-11 19:04:06 +10:00
Teknium	f8456248d9	fix: Bedrock Guardrails enforced on the Claude route and blocks surface as refusals ... bedrock.guardrail was only attached on the Converse route (guardrailConfig in the body). Claude on Bedrock goes through the AnthropicBedrock SDK, i.e. InvokeModel, whose body has no guardrailConfig, so the default Claude route ran with no guardrail at all (#52179; live-verified by JiaDe-Wu: the blocked word came back through Hermes). Bedrock reads the guardrail for InvokeModel from X-Amzn-Bedrock-GuardrailIdentifier / -GuardrailVersion / -Trace headers. Attach them as default_headers in build_anthropic_bedrock_client so every AnthropicBedrock client Hermes builds (primary init, /model switch, fallback, per-request rebuild, auxiliary) enforces the same guardrail, with prompt caching / thinking / 1M context kept (the reason Claude is not routed through Converse). InvokeModel blocks do NOT change stop_reason (stays end_turn) and return the guardrail's canned text as an ordinary assistant reply, flagged only by amazon-bedrock-guardrailAction=INTERVENED in the body (SDK: response.model_extra). AnthropicTransport.response_finish_reason maps that to content_filter so the loop runs its refusal handling instead of reasoning over the canned text; _derive_finish_reason uses it for the anthropic_messages branch. Mantle (openai.gpt-5.x) is documented by AWS as not supporting Guardrails on the Responses endpoint; the docs now say so instead of promising "all model invocations". Header mechanism proposed in #52312 by @JoaoMarcos44 (stale base, 7-file conflict, detection keyed on a Converse-only stopReason); reimplemented on current main. Live probe (local sink, SigV4 fake creds): before, no X-Amzn-Bedrock-* header on the InvokeModel request; after, headers present, SigV4 intact, INTERVENED → content_filter.	2026-09-11 01:37:22 -07:00
Jeffrey Quesnelle	8d79c2ff57	Merge pull request #107959 from NousResearch/fix/local-fit-mtp-accounting ... fix(local-runtime): unify memory accounting and effective-window MTP	2026-09-11 02:05:40 -04:00
emozilla	0316d3d404	fix(local-runtime): unify memory accounting and effective-window MTP ... Price weights, context, runtime, projector and batch overhead consistently across catalog admission, initial launch, growth and restored windows. Keep MTP and the larger window when lean batches avoid unnecessary spill. Admit optional external drafts only when their complete footprint fits. Use preset-only model discovery so refused files cannot autoload, and preserve refusal/spill decisions atomically for desktop status read-back. Add regression coverage for complete-footprint boundaries, MTP restarts, growth admission, draft budgets and placement status transitions. Builds on the overhead-accounting contribution in #102993 and the restored-window MTP contribution in #106897. Does not adopt the 40% host-RAM reserve or resolve the remaining requests in #102865/#106895. Co-authored-by: infinitycrew39 <infinitycrew39@gmail.com> Co-authored-by: KoNit-K <124019182+KoNit-K@users.noreply.github.com>	2026-09-11 01:40:43 -04:00
Ben Barclay	05d705dd69	Merge pull request #105839 from victor-kyriazakos/fix/relay-explicit-disable ... fix(relay): honor explicit profile disable before relay startup	2026-09-11 14:02:08 +10:00
Teknium	45a6101f36	fix(gateway): secondary-profile send_message, notices and /loop wakeups go out via their own bot ... Under gateway.multiplex_profiles a turn running for a secondary profile P resolved its live adapter by bare platform from runner.adapters — the DEFAULT profile's map — so P's send_message tool calls (send/react/media on slack, matrix, wecom, buzz, ntfy, every plugin platform), its "Gateway shutting down/restarted" and /update notices, its /loop wakeups, and its Discord bot's unauthorized-slash operator alert all left through the default bot (Telegram DMs landed in the user's chat with the other bot). Every such door now resolves through the profile-aware, fail-closed resolver already used by the inbound reply path (authz_mixin: _adapters_for_profile / _authorization_adapter / _adapter_for_source): P's own adapter, or None → a clear error, never the default bot. - tools/send_message_senders.py::_live_adapter — resolve via runner._authorization_adapter(platform, get_active_profile_name()); shared by _send_via_adapter, _handle_react/unreact, media sends, matrix E2EE fast path and the WeCom standalone sender. - gateway/authz_mixin.py — extract _adapters_for_profile (the whole map, for relay- aware resolve_delivery_transport callers); _authorization_adapter reuses it. - gateway/run_shutdown.py — shutdown/restart notice for a running session uses the session's source transport / agent:<profile>: key lane, never self.adapters. - gateway/slash_commands.py + run_notifications.py — /restart and /update markers persist `profile`; the restart notice, update result and update prompt resolve the requester's own adapter (legacy markers fall back to the session_key lane). /goal, /heartbeat, /approve, /deny confirmations use the source's own transport. - gateway/slash_commands_goals.py + run_goals.py — /loop persists `profile` in its route; the wakeup watcher scans every served profile's store under its own scope (same shape as _handoff_watcher) and fires through that profile's adapter map. - plugins/platforms/discord/adapter.py::_notify_unauthorized_slash — alert stays in the owning profile (its adapters and its home channels). - plugins/platforms/wecom/adapter.py::_standalone_send — via _live_adapter. - docs: website/docs/user-guide/multi-profile-gateways.md (outbound identity). Tests (red on base): tests/tools/test_send_message_multiplex_profile_adapter.py, tests/gateway/test_multiplex_notice_egress_profile_adapter.py. Co-authored-by: pierrenode <298902573+pierrenode@users.noreply.github.com>	2026-09-10 18:17:22 -07:00
Teknium	c3e01c753d	fix(gateway): /p/<profile>/ webhook delivery and api_server callbacks stay on the routed profile ... Under gateway.multiplex_profiles a /p/<profile>/ webhook route (or one with `profile: <name>`) executed under that profile but delivered its reply as the FIRST profile owning the target platform: `_find_adapter` took `runner.adapters` then iterated `_profile_adapters` in dict order, and the home-channel fallback read `runner.config` (the default profile's). The gh leg for `github_comment` inherited the process environ, i.e. the default profile's GH_TOKEN. Both directions leaked: a secondary route posted through the default bot, and a default route borrowed a platform parked only on a secondary. The api_server `/p/<profile>/api/platforms/<platform>/events` callback had the same shape — `_get_platform_callback_adapter` read `runner.adapters` regardless of `_api_request_profile`, so a secondary's Google Chat / Teams events were verified and dispatched by the default adapter. Now: - webhook: `_delivery_info` / the deliver_only dict carry the resolved profile; `_find_adapter(platform, profile)` resolves through the runner's shared fail-closed `_authorization_adapter`; the delivery leg runs inside `_profile_scope(profile)` and takes the home channel from that profile's `load_gateway_config()`; `gh` gets GH_TOKEN/GITHUB_TOKEN from the profile secret scope (default's values dropped from the child env when the profile has none). - api_server: the callback adapter resolves via `_authorization_adapter(platform, _api_request_profile.get())`; a named profile without the adapter is a 503, never the primary's adapter. A profile without the target platform fails closed ("not connected" → 502 / 503) instead of a silent cross-profile send. Fixes #65939 Fixes #84266 Co-authored-by: 604maestro <604maestro@protonmail.com> Co-authored-by: mjshorty <mjshorty@users.noreply.github.com> Co-authored-by: StellarisW <stellarisw@users.noreply.github.com>	2026-09-10 18:16:43 -07:00
Teknium	338bf9ea9a	fix(cli): banner/TUI/dashboard update checks go through the GitHub API, cached 24h ... The Python passive check (`banner.check_for_updates`, used by the CLI banner, `hermes --tui`, every `tui_gateway` spawn and the dashboard's /api/hermes/update/check) also ran `git fetch origin main` on every cache miss, and never cached an inconclusive result so a flaky line retried on every start. Same GitHub complaint, same fix: - remote tip via GET /repos/{slug}/commits/main (vnd.github.sha), local tip via rev-parse, exact count + changelog via the compare API when they differ. HTTPS `ls-remote` remains only as the fallback when the API is unreachable or the origin isn't on GitHub. - cache TTL 6h -> 24h, failures cached 1h; the cache is keyed on HEAD so `hermes update` invalidates it immediately. - the dashboard's "what's changed" list comes from the memoized compare payload (`upstream_commits_behind`) instead of `git log HEAD..origin/main`, which was stale without a fetch. Tests rewritten to the new contract: passive checks must not run `git fetch`/`ls-remote` for a GitHub origin; the daily cache invalidates when HEAD moves and re-asks after the failure window.	2026-09-10 18:15:54 -07:00
Teknium	08830efd96	fix(secrets): secret-source re-pull no longer latches an empty snapshot or wipes sibling profiles ... Symptom (#102041): under a multiplex gateway the default profile's vault/1Password/ Bitwarden/plugin-sourced credentials vanished for the rest of the process after the first cron fire or the post-discovery plugin refresh; with the key already in the process env (systemd EnvironmentFile=) the scope was empty from boot. Every get_secret() read then failed closed ("No usable credentials", every Telegram sender rejected). Why: _apply_external_secret_sources marked the home applied after any real fetch, but only snapshotted names in report.provenance — the NEWLY applied ones. On a re-apply the previous apply's own write-back makes every key `skipped_existing`, so the snapshot latched to {} and _hydrate_profile_secret_sources returned that empty snapshot forever. Separately, reset_secret_source_cache() was process-wide, so one profile's cron re-pull dropped every sibling's hydrated snapshot (1aa62ceb45 isolated the routed reload but not the reset). Change: - env_loader: snapshot every name a source supplied (provenance + skipped_existing) from the home's effective environment, so a shadowed re-apply keeps the values it had. - reset_secret_source_cache(hermes_home=None): optional per-home reset; global clear kept for tests/config edits. - cron per-fire re-pull and plugins._refresh_secret_sources_after_discovery reset + reload only the home they resolve to. - Two invariant tests (red on base) in tests/test_env_loader_secret_sources.py; docs note in secret-source-plugin.md. Reported-by: luochen1990 Addresses #102041	2026-09-10 18:13:16 -07:00
Teknium	580322ef1e	fix(mcp): stdio MCP children get the routed profile's vault secrets, not the default's ... Under a multiplexed gateway, `_build_safe_env` forwarded `os.environ[name]` for every name tagged in the process-global `_SECRET_SOURCES` map. That map is filled by EVERY served profile's secret-source hydration, while `os.environ` only ever holds the LAUNCH (default) profile's values — so once any profile's 1Password/Bitwarden source supplied e.g. GITHUB_TOKEN, every profile's stdio MCP server was started with the default profile's token. Resolve those names through the active profile's secret scope (`get_secret`) instead: the routed profile's value, or omitted when that profile has none. Under multiplex `get_secret` never falls through to environ; single-profile runs keep the .env overlay + environ behaviour, so the existing "vault vars reach MCP subprocesses" contract still holds there. `secret_source_names()` exposes the tagged NAMES only — values are never read from the shared map. Docs: the multi-profile guide's "MCP subprocesses only see their own profile's secrets" claim is now true for source-injected names too; say so explicitly.	2026-09-10 18:12:39 -07:00
Teknium	3b044261b6	fix(gateway): media denylist covers every profile's credentials, not just the launch home ... Under `gateway.multiplex_profiles` one process serves every `<root>/profiles/*`, but `_media_delivery_denied_paths` expanded `_ROOT_CREDENTIAL_PATHS` only under the import-time `_HERMES_HOME` / `_HERMES_ROOT`. A `MEDIA:<root>/profiles/<B>/.env` (or auth.json, state.db, config.yaml, sessions/, mcp-tokens/) emitted in ANY profile's turn — including B's own, whose HERMES_HOME override was never consulted — passed validation and was natively uploaded to the chat. The ALLOW side (`_profile_cache_roots`) already enumerated profiles at check time; the DENY side did not. `_credential_home_roots()` now yields the active `get_hermes_home()`, the shared root and every `<root>/profiles/*` at check time (shared `_profile_dirs()` with the allow side), and the denylist is built from that. Profile cache artifacts and plain agent-written files under a profile stay deliverable. Live repro (/tmp/mux_audit/fix-media-denylist/repro.py): before, all five of profiles/B/{.env,auth.json,state.db,config.yaml,sessions/s1.json} validated as deliverable while <root>/.env was blocked; after, all None, cache/images/gen.png and report.pdf still deliverable. No prior report. Write-side analogue: #107327 / #107335 (memo keying, different mechanism — left as is).	2026-09-10 18:10:48 -07:00
Ben Barclay	6f5dda1aee	fix(relay): read the opt-out through the loader's own YAML reader ... relay_explicitly_disabled() went through hermes_cli.config.read_raw_config, which turns a malformed config.yaml into {} and then applies the managed overlay. load_gateway_config() raises on the same file and falls back to env + gateway.json WITHOUT the managed layer. With a managed relay.enabled: false and an injected URL the two readers disagreed: the loader kept relay enabled and suppressed native Slack, while startup refused to register relay — a profile with no route at all. Extract the loader's file selection into config_loader.read_yaml_layers() and have both consumers use it; the predicate mirrors the loader's fallback (no YAML layer) on a parse error. Regression test fails on the previous predicate.	2026-09-11 10:45:33 +10:00
Ben Barclay	7ea67e97f4	docs(relay): describe the opt-out at its real boundary ... Drop the claims about reconnects and media handling that no longer have code behind them; state where the verdict is read and what a gateway.json disable does.	2026-09-11 10:30:41 +10:00
Siddharth Balyan	4bdd64b334	The free tier is created in one place, at boot, only behind HERMES_GUEST_ONBOARDING=1 (NS-847) (#107697) ... * fix(auth): close the free tier's gaps against the gateway's welcome-tier contract The inference gateway's welcome tier (NousResearch/api DOCS/anon-tier/plan.md) serves an anonymous account exactly one model on its own host, refuses everything else with a structured 429, cross-refuses a request on the wrong host with a 400 (403 while the tier is dark), and tells a signed-in account that still asks for `nous/welcome` what to switch to in an `x-nous-model-switch` header. Four client-side gaps against that contract: - Auxiliary calls were refused on every session. The auxiliary client asked the welcome host for the Portal's recommended compaction/vision model, a guaranteed 429 `model_not_free` before each fallback. On the welcome host it now uses `nous/welcome` (its backing model covers auxiliary work) and skips Nous for vision, which the welcome model does not take. - The structured 429 body was never read. The classifier now parses `reason` / `retry_after` / `alternates` / `upgrade_url`: `model_not_free` and `feature_not_free` are non-retryable gates that fall back; `at_capacity`, `admission_closed` and `rate_limited` are rate limits that honour `retry_after` and never rotate the free tier's only credential. The wrong-host 400 and the dark-tier 403 are deterministic, so they abort this route and fall back instead of retrying or re-exchanging. The terminal paths say what happened and name the sign-in (`/login` in a chat, `hermes auth upgrade` in a terminal). - The `x-nous-model-switch` header was ignored. The chat-completions transport records it beside the rate-limit and credits headers; the next call moves the session, and the config default when it still names `nous/welcome`, to the backing model the gateway named. - A guest fell back to the paid host. With `inference_base_url` absent from the exchange or outside the host allowlist, routing defaulted to inference-api, where every request is a 400. A guest now defaults to the welcome literal at the exchange, in the shared store's shape, and in effective routing. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit fc758aad7efceff6223fc144a9b5c69f13e41bd8) * feat(auth): the free tier is set up on request; nous.guest_setup decides whether also on first use A caller that names nous/welcome on a Nous route with no Nous identity in reach — the guided setup's session (provider=nous, which skips the resolver's nothing-configured rung), the free-tier picker row, a bare --provider nous pointed at it — is asking for the free tier. The OAuth runtime rung now sets it up there instead of failing "not logged in", so the guided chat no longer races the root profile's first-run mint. nous.guest_setup is the policy seam: "auto" (default) keeps today's first-use setup wherever nothing else is configured; "on-request" mints only when the free tier is asked for by name (nous/welcome, /login, hermes auth upgrade, replacing a retired identity). Implicit callers — the resolver's last rung, the first-run check, free_tier.status, the CLI's background setup, the connector token path — still adopt what the shared store holds, so every profile follows the one identity the guided setup created, but never create one on their own. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit ae915ddc65ecdb81b81e29b604671d15cd49233c) (cherry picked from commit 62ad1ff3ab200ea064975a32c502041b25910165) * feat(auth): the guided setup provisions the free tier explicitly; nous.guest_setup is auto | explicit Two questions govern the free tier: may it exist (nous.guest) and who may CREATE the identity (nous.guest_setup). "auto" (default) keeps today's first-use setup wherever nothing else is configured. "explicit" means Hermes never creates one on its own: the only creator is the new provision_free_tier() primitive, exposed as the free_tier.provision RPC, which the guided setup on Hermes Desktop calls as its first step — on the root gateway, before the setup profile and before the guided chat exists — so the identity lands in the root store every profile reads through and is there before any session asks for nous/welcome. That closes the race against the backend's own setup, and makes "only when the setup-bot flow is used" literally true. The earlier "on-request" tier is replaced: it minted whenever any caller named nous/welcome (the hermes model row, --provider nous), which treated a model name as intent and was broader than the guided setup. Under "explicit" a nous/welcome request with no identity fails "not logged in" as before the free tier existed, and /login or hermes auth upgrade report nothing to sign in from. Implicit callers still adopt an identity the shared store holds, and a retired credential is replaced (a continuation, not a creation). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit c63d2c935c1e59016164fdfb90cf70b4094466a0) * fix(auth): remove the nous.guest_setup knob; the free tier is created on first use `nous.guest_setup: auto | explicit` decided who may CREATE the free-tier identity. Under its default every line it added was inert (`may_mint` always true), nothing in tree set `explicit`, unknown values read as `auto`, and under `explicit` a CLI-only install could never get an identity, which contradicts the first-run contract (first command mints, then chats). The mint race the knob accompanied is already benign: every caller takes the profile lock then the shared-store lock, and the loser adopts what the winner wrote. What makes the guided setup win deterministically is `provision_free_tier()` behind the `free_tier.provision` RPC, which stays. `nous.guest` remains the only free-tier policy. Removed: `guest_setup_policy()` and its constants, the `explicit=` / `may_mint=` threading through `ensure_portal_identity` and `_reconcile_and_provision`, the flag at the three replacement call sites (now no-ops), the config default, the docs section, and the four `guest_setup` test-config entries. The three policy tests that hold regardless of the knob are kept under `TestExplicitProvision`; the two that only tested the knob are deleted. (cherry picked from commit d8a50526d93c374c0067dd935b5a65055e0af261) * fix(gateway): a server-driven model switch off nous/welcome does not evict the cached agent When a signed-in account still asks the paid host for `nous/welcome`, the inference gateway serves the current backing model and names it in `x-nous-model-switch`. `apply_model_switch` moves the live session to that model and moves `config.yaml`'s default off the alias in the same step. The messaging gateway's fallback-eviction check compares the agent's model with the config default and evicts on any mismatch that is not a /model override, so when the config write did not land (unreadable config, lock) the cached agent was evicted once per turn, and prompt caching with it. `apply_model_switch` now stamps the alias it moved the session off on the agent, and `_is_intentional_model_switch` treats "agent moved off the alias the config still carries" as deliberate, beside the existing /model override case. The check takes the agent and the config model instead of a bare model string; its one caller in `_run_agent_evict_on_fallback` passes them. (cherry picked from commit 696d1ec86b69db28bf002c841e9389b85178a954) * fix(auth): the free tier outranks implicit host credentials in provider resolution On a fresh install with a leftover ~/.aws profile, resolve_provider("auto") reached the Bedrock rung before the free-tier rung, so the first turn ran on Bedrock and failed 403 while the free tier was still being minted in the background at agent setup (NS-829). Live on a Mac with ~/.aws present: 28 s, three retries, no answer; the next process then switched to nous/welcome. The free-tier rung now sits directly above the Bedrock chain: when nous.guest is on, an existing free-tier identity answers, else a blocking mint runs, and only then does the boto chain get a say. Everything above is unchanged and still wins: CLI creds, config.yaml model.provider, env keys, the OpenRouter pool, a logged-in active_provider. nous.guest: false skips the rung, and a failed mint still falls through to Bedrock and the no-provider guidance. Tests: six precedence cases (identity present, fresh mint, free tier off, env key still wins, sign-in still wins, failed mint falls through). The opt-out test now neutralizes the AWS chain like the precedence tests do; on a machine with ~/.aws it was failing for the same reason as the bug. Live after the fix, same Mac, AWS credentials visible, isolated shared store: identity minted 2 s in, turn on model=nous/welcome provider=nous, answer in 11 s. (cherry picked from commit a04b05260cd334dd7199ad9b6cd5b2538364c75a) * fix(auth): review follow-ups for the free-tier rung (NS-829) - tests/agent/test_bedrock_integration.py: the Bedrock auto-detect test switches the free tier off; its contract is the boto chain, and the free tier now sits above it. - gateway/run_notifications.py: the free-tier startup line reads auth.json before consulting the resolver, so a gateway boot on a machine with AWS credentials never mints or refreshes over the network. - hermes_cli/anon_auth.py: module docstring says where the free tier sits in the ladder instead of "the ladder is untouched". - tests/hermes_cli/test_provider_precedence.py: two invariant tests instead of six (parametrized ladder cases; a failed mint that returns None or raises falls through to Bedrock). scripts/run_tests.sh on the five affected files: 147 passed, 0 failed. (cherry picked from commit 10790d148c60ada11b9ecdde2cd2c836c6a82a11) * feat(auth): HERMES_GUEST_ONBOARDING=1 is the one launch gate for the free tier; HERMES_FORCE_GUEST is gone The free tier is pre-GA. Until GA it must not exist for anyone who did not ask for it: no identity minted, no portal traffic, no free-tier copy on any surface. One environment variable now decides that, and one function reads it. `guest_enabled()` returns False unless `HERMES_GUEST_ONBOARDING` is exactly "1"; only then does `nous.guest` (the user's off switch) get consulted. Every free-tier site already funnels through `guest_enabled()`, so the gate closes minting, routing, connector entitlement, status lines and the picker row in one place. With the variable unset, `resolve_provider("auto")` on a fresh install raises `no_provider_configured` exactly as upstream does. `HERMES_FORCE_GUEST` and `force_guest_mode()` are removed. They inverted the gate (forced the tier ON over `nous.guest: false`), their "new" value re-minted identities as a side effect of provider resolution, and `_has_any_provider_ configured` read them ahead of every other check, making the CLI a second reader of a flag that must have exactly one. `_forced_new_done` and the `force` parameter of `_reconcile_and_provision` go with them. Supersedes the dev lever introduced in fcf9d11679 (rung 1) and hardened in b5c162c3ec. Ruling: NS-845 Q1.1 (recorded on NS-847). Not a user preference: the variable is never written to config.yaml or .env and never shown in setup. It is deleted at GA together with its comment in anon_auth.py. This is a deliberate, temporary exception to the "no new HERMES_* env vars for non-secret config" rule. Tests: fixtures set the gate instead of deleting the old lever; one new invariant (`test_launch_gate_off_means_no_free_tier_at_all`) proves that "", "0", "true" and "new" all leave the tier off with zero portal calls, red on the previous commit. The `HERMES_FORCE_GUEST=new` re-mint test is deleted with the feature. * feat(auth): the free-tier identity is created in one place, at boot; every other site is a read Before this commit eight sites could create a Nous free-tier identity as a side effect of something else: resolving a provider, the CLI's first-run check, the CLI's session setup (in the background beside an own key), a connector bearer read, the desktop polling `free_tier.status`, the sign-in precondition, the desktop's `free_tier.provision`, and the dead-credential re-mint. A poll could mint. Provider resolution could hit the network. Two of them raced each other on a fresh install. Now `hermes_cli/free_tier_bootstrap.py::run_bootstrap` is the only creator. `hermes serve` runs it on a daemon thread from `_lifespan` beside the other background boots; `cmd_chat` runs it synchronously before the first-run guard. It inventories credentials first (`resolve_provider("auto", skip_free_tier=True)`: what would carry inference if the free tier did not exist), creates the identity only when `guest_enabled()`, resolves inference, records a `SetupRecord` in process memory and broadcasts ONE `setup.ready` event. It runs on every boot; only the mint is gated. `ensure_portal_identity` now requires `explicit=True` and raises otherwise. Its callers are the bootstrap, the desktop's `free_tier.provision` (the explicit retry when the boot could not create the identity) and the two dead-credential replacements (`auth_nous.resolve_nous_runtime_credentials`, `managed_tool_gateway._replace_dead_guest_token`). The background thread path and `provision_free_tier` are deleted with their last callers. Reads that used to mint and now only read: `auth.py::resolve_provider` rung 7 (an existing identity still outranks the Bedrock chain, NS-829 ordering kept), `main.py::_has_any_provider_configured`, `cli_agent_setup_mixin._ensure_runtime_credentials`, `managed_tool_gateway.read_nous_access_token` (no identity -> None), `anon_sign_in.run_sign_in` (no identity -> Unavailable), `methods_free_tier` `free_tier.status`. `setup.status` answers from the record for the launch profile, blocking up to 8 s while the bootstrap is in flight so a client's first poll lands after the identity exists rather than racing it; a named profile, or a process that never ran the bootstrap, keeps today's live probe. The record's fields ride along additively (`ready`, `free_tier`, `other_providers`, `inference_provider`). Identity and inference are decoupled (NS-845 Q1.3): the mint sets `active_provider="nous"` only when the inventory found nothing else usable (`_mint_locked(carries_inference=)`); an adopted account always does. A token refresh no longer re-elects the provider it refreshed (`_save_provider_state_to_source` writes credentials, not the user's choice) — that write was how an own-key install ended up on the free tier after the first connector call. Supersedes the mint sites in fcf9d11679, a42d0748fc (first-run check), bbbaa8935a (CLI background setup), 0179efc989 (`free_tier.status` mint), 62ad1ff3ab / c63d2c935c / d8a50526d9 (the `nous.guest_setup` knob and `provision_free_tier`), and a04b05260c (blocking mint in the resolver). Ruling: NS-845 Q1.2 + Q1.3, recorded on NS-847. Tests: `TestBootstrapIsTheOneCreator` (one mint per process; own key keeps inference; reads never reach the portal; a refused mint is memoised), `free_tier.status` fails loudly if it ever calls the creator, the resolver stub fails loudly if resolution ever mints, `setup.status` reads the record, `skip_free_tier` proves the inventory question. The three sign-in tests for the deleted pre-mint collapse into one (`no identity -> Unavailable, zero portal calls`). Live: real `_lifespan` boot with a fake portal, gate on and off (/tmp/ns847-recon/evidence/e2e-rung5-c2-serve-boot.txt), and the CLI matrix incl. an own-key cell (e2e-rung5-c2-bootstrap.txt), 20/20. * fix(credits): the welcome host is free-tier evidence, so a free-tier identity never sees "run /topup" A free-tier identity carries $0 by design, so the portal seed reports `paid_access=False` for it. `is_free_tier_model` did not know the welcome host, read that as a depleted account, and every free-tier turn ended with the credits-depleted notice telling the user to top up an account they do not have. Rule (4) in `is_free_tier_model`: a `base_url` on the Nous welcome host (`anon_auth.route_is_welcome_host`) is the free tier. The host is the evidence, not the model name: the paid inference host can serve `nous/welcome` to a named account and that account's depletion is real, so `("nous/welcome", <inference host>)` stays False. Local data only, like the three rules above it. Restores the two contracts dropped by hermes-magic 674e11d1eaa (the prototype line ran without unit tests): the welcome host is free without any pricing evidence; the model name alone is not. The first is red without this fix. * fix(copy): free-tier text stops promising a connector transfer and never names the config key Sign-in copy on every surface said "Sign in to keep your connectors" and ended with "Your connectors are kept." The transfer registry that would make that true is empty (NS-821): nothing carries over today. The copy now says what signing in does give ("unlock more models and tools") and the completion line names the account, not a transfer. The docs page loses the "connectors carry over" paragraph for the same reason. The picker's off-state line exposed `nous.guest: false` and the word "guest"; user copy names the free tier only (R-USR-1). The docs page gains the pre-rollout note: until GA nothing on it happens without `HERMES_GUEST_ONBOARDING=1`. Its "first command mints" and "replaced on next use" sentences now describe the boot bootstrap. zh is a strict locale: the `freeTier` block was English placeholder text copied from `en`; it is now Chinese. `connectorsKept` is renamed `completedBody` since it no longer talks about connectors. * feat(desktop): the free-tier launch flag is decided once in Electron and stamped onto every backend spawn The Python backend reads `HERMES_GUEST_ONBOARDING` and treats exactly "1" as on. Until now nothing in the desktop set it, so a packaged app could never turn the free tier on, and a backend spawned by the app could disagree with the app about whether the tier was live. `electron/guest-onboarding.ts` owns the decision: `guestOnboardingEnabled` is true when the launch env has `HERMES_GUEST_ONBOARDING=1` or argv has `--guest-onboarding` (the packaged-app spelling). It is read ONCE at launch into a module constant. `desktopBackendSpawnEnv` wraps every backend env as the outermost call and writes the flag LAST, as "1" or an explicit "0", so no earlier spread (`process.env`, `backend.env`) can resurrect a stray value from the parent shell. Stamped onto all three spawn sites: the primary `serve` spawn, the pooled per-profile spawn, and the remote SSH `exec env ...` command (which gains ` HERMES_GUEST_ONBOARDING=1` only when on). The embedded terminal PTY and the backend probes are not backend spawns and do not get it: a `hermes --tui` typed in the pane must not mint. The renderer learns the same fact read-only through the existing `hermes:launch-flags` sync IPC (`guestOnboarding`) and preload (`window.hermesDesktop.guestOnboardingEnabled`). Ruling: NS-845 Q1.1 / Q2 (env var is the contract, `--guest-onboarding` maps to it in main). Two invariant tests on the pure helpers: only "1" or the argv flag enables; the spawn env carries "1"/"0" as the last word and preserves every other key. * feat(desktop): the renderer learns free-tier readiness from one `setup.ready` push, not a 60 s poll The backend's boot bootstrap now announces `setup.ready` once, after it has created (or refused) the free-tier identity and resolved the inference route. The renderer used to discover both by polling `setup.status`, `setup.runtime_check` and `free_tier.status` every 60 s from `useStatusSnapshot`; a fresh install's chip, notice strip and onboarding overlay could sit stale for up to a minute after boot, and three RPCs a minute per window kept asking a question whose answer changes only at boundaries the backend already announces. `handleLifecycleEvent` routes `setup.ready` (active source only, like `skin.changed`) to `notifySetupReady()`, a one-shot tick atom in `live-sync.ts` beside the other change ticks. `useStatusSnapshot` listens to it and runs one readiness round at once (`setup.status` + `setup.runtime_check` + `free_tier.status`). The readiness legs also run once on open and on return from another app, as today. The 60 s tick keeps only `getStatus()`. `SetupStatusSnapshot` types the record's additive fields (`ready`, `free_tier`, `other_providers`, `inference_provider`); readiness semantics are unchanged and still key on `provider_configured` + `runtime_check`. Ruling: NS-845 Q1.2 (renderer half). Tests: the lifecycle branch fires one refresh from the active source and none from another; the snapshot hook's contract is three legs on open, one leg on the tick. * fix(cli): the banner names the free tier's model instead of "no model configured" The welcome banner prints before credentials resolve, so on a fresh install `model` is empty and the banner said, in red, "no model configured — run /model or hermes setup". Under the free tier that is false: the route is already known from local state (identity on disk, tier on), and the first message will run on `nous/welcome`. `_banner_left_lines` now asks the route the same question when `model` is empty (`guest_carries_inference()`, a local read) and shows `welcome · Nous Research`. When nothing resolves the red line stays. Ruling: NS-845 ("the banner's 'no model configured' line reads the resolved route"). Live: fresh HERMES_HOME + fake portal, gate on -> `welcome · Nous Research`; gate off -> the red line, zero portal calls. * fix(aux): vision on the free tier uses nous/welcome too The text-only modality on the gateway's `nous/welcome` row is DeepSeek V4 Flash's, the backing model until the repoint; `z-ai/glm-5.3-flash` is natively multimodal and the repoint declares the welcome row `text+image->text`. Skipping Nous for vision on the welcome host would have sent every image step past the free tier for no reason, so the auxiliary client pins the route's one model for every lane. A backing model that takes no images answers with the upstream's own error, which the ladder handles as it always has. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit 7456e028faba55480db43015dc2c8df3e393a415) * fix(gateway): hermes gateway run is a boot owner of the free tier too Rung 5 made every demand-time free-tier site a read: resolve_provider, the connector token, the /login precondition. That is only correct if every process that can reach those sites ran the bootstrap first. The CLI (cmd_chat) and hermes serve (_lifespan) did; the standalone messaging gateway did not. A fresh HERMES_HOME with the gate on and `hermes gateway run` reached provider resolution with no identity to consume, and /login returned Unavailable. Reported by @andrexibiza on #107697 (P1). GatewayRunner.start now runs `free_tier_bootstrap.run_bootstrap` on an executor thread right after startup recovery and BEFORE any adapter connects, so a fast first DM cannot arrive with nothing to resolve. It is its own step, not part of the turn-machinery warm-up: the warm-up is an optimisation with an off switch (HERMES_STARTUP_WARMUP_TIMEOUT<=0); the bootstrap is correctness and must always run. With the gate unset it is a local inventory and no network. Live, real GatewayRunner.start against a fake portal in a fresh home: gate on -> 1 create, identity persisted, resolve_runtime_provider=nous, /login precondition sees the identity gate off -> 0 portal calls, no identity, no_provider_configured Before the fix the gate-on row was identical to the gate-off row. Test: the bootstrap seam runs before _start_prefilter_platforms and delegates to the one creator. Red on 5554eb6993 (no seam), green here. --------- Co-authored-by: Robin Fernandes <robin@soal.org> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 03:45:33 +05:30
Siddharth Balyan	cbcf7b72f7	feat(gateway): sign in with a Nous account from a chat (/login), one shared sign-in flow (#105261) ... * refactor(auth): one sign-in flow behind SignInState, rendered by the CLI and the desktop * feat(gateway): /signin signs the free tier into a Nous account from a DM * feat(cli): chat surfaces name /signin as the sign-in verb * fix(auth): review follow-ups for the shared sign-in flow and /signin * fix(i18n): carry the /status free-tier line in every locale catalog * refactor(cli): the chat sign-in command is /login * fix(auth): durable override cleanup in the /login sweep, and the sign-in flow in its own modules	2026-09-11 03:45:33 +05:30
Siddharth Balyan	3b01b4ce0f	feat(desktop): Nous free tier on Hermes Desktop (#105260) ... * feat(desktop): free-tier state over RPC, status routes that name it, and a sign-in that keeps connectors The desktop learns about the Nous free tier by reading local auth state (pull): free_tier.status answers has_guest / enabled / carries_inference / notice_pending with zero network, and free_tier.ack_notice persists the one-time notice flag on the identity itself. setup.runtime_check reports free_tier for the selected route; /api/portal, the Nous card in /api/providers/oauth and billing.state carry free_tier (billing answers the free tier locally instead of a portal call that can only fail). The free-tier picker row carries an explicit free_tier_row flag and is never priced or locked. POST /api/providers/oauth/nous/start over a free-tier identity registers the connector transfer and returns its code and consent URL; the poller waits for the transfer before the token grant, persists the account, runs settle_after_upgrade, and the poll response gains reason, account_email and model. * feat(desktop): free tier on Hermes Desktop: ready screen, notice strip, status chip, Billing view, one sign-in dialog The renderer reads the free tier from free_tier.status (pull) into one store; the first-launch intro is the same state rendered two ways, keyed on the backend's one-time flag: the onboarding overlay opens on a ready screen when the free tier carries inference, else a one-time strip above the composer. Settings > Billing gains a free_tier view (notice with one Sign in, Plan / Model / Connectors summary, plan card, footnote; no payment or usage rows). A status-bar chip names the tier and model while it carries inference. Every entry point opens one claimed sign-in dialog that drives the extended oauth/nous route and maps the poll's status and reason to the ruled screens; Done settles billing, model options, providers and re-homes a session still on nous/welcome. The picker badge also fires on free_tier_row. Docs: Desktop section in the free-tier guide, AGENTS notes. * fix(desktop): free_tier.status starts the free tier's background setup when no identity exists A served backend has no session-setup moment like the CLI's, so beside an explicit provider the free tier was never set up on the desktop: no connectors, no notice strip. The first status read now starts the same one-attempt background setup; the call itself never waits. * fix(desktop): one Sign in on the Billing page; Settings > Providers names the free tier, never Connected The free-tier plan card is the what-you-get text alone (the notice carries the page's one Sign in). The Nous provider row reads Nous · free tier with a Free tier tag while the identity is the free tier, instead of Nous Portal · Connected. * fix(desktop): Settings > Providers never files the free tier under Connected * fix(desktop): the intro's shape is keyed on the route, not on the identity free_tier.status reports available (an identity exists and the tier is on); whether inference runs on the free tier is setup.runtime_check.free_tier, keyed on the resolved endpoint. The ready screen shows when that route is the free tier; the composer strip when the user's own provider carries inference. An own-key install used to get the ready screen. * docs(desktop): say what the free-tier chip is keyed on * fix(desktop): the featured Nous row's pitch on the free tier says what signing in adds * fix(desktop): a cancelled or superseded sign-in attempt can no longer change the identity or hide the intro Four lifecycle holes from review. The Nous poller checks the session's cancelled flag after the transfer wait, after the token grant, and once more under the session lock together with the save, so a sign-in the user abandoned never persists. The renderer's sign-in store carries an attempt generation that every continuation checks after each await, so a poll from a closed attempt cannot publish over the one on screen (and its backend session is cancelled). The ready screen comes down only after the backend recorded the acknowledgement. A composer still mounted takes over the notice claim when its owner unmounts. One thin test per hole.	2026-09-11 03:45:32 +05:30
Siddharth Balyan	04a76c4109	fix(auth): a sign-in from the free tier settles the default model and route (#105259) ... * fix(auth): a sign-in from the free tier settles the default model and route once, for every caller Picking the free-tier row leaves model.default at nous/welcome pinned to the welcome host. After a sign-in an account cannot keep either: the welcome host refuses account tokens, and the portal host serves nous/welcome as a paid model. One completion step, anon_auth.settle_after_upgrade, now runs after the account is persisted: a config on the free tier's route moves to the account's inference host and the recommended default for the account's plan, through the same config write a plain Nous login uses; a config on the user's own model is left alone. The pick is the one GET /api/model/recommended-default already makes, factored into models.recommended_nous_default_model so the CLI and the desktop land on the same model. hermes auth upgrade prints the new default. * fix(auth): a sign-in completion with no eligible recommendation leaves no default model The static provider-wide default is not narrowed by the account's plan or org policy, so writing it as a fallback could persist a model the account may not use. When the recommendation cannot yield a model, the route still moves to the account's host but model.default is left unset; the CLI says so and points at `hermes model`. * docs(free-tier): say what happens when no recommendation is available after sign-in * fix(auth): sign-in completion moves the host and clears the default in one config write Two writes could fail between them and leave the account host paired with nous/welcome. _update_config_for_provider gains clear_default so the caller with no model to offer removes model.default in the same atomic write that sets the host.	2026-09-11 03:45:31 +05:30
Siddharth Balyan	a2db110ccc	feat(auth): Nous free tier: free inference and connectors out of the box, one command to sign in (#105258) ... * feat(auth): Nous free tier core: anonymous identity minted on first use, welcome inference, shared-store scoping A fresh install with no provider sets up a free Nous identity (anonymous auth method of the nous provider) instead of forcing the setup wizard. The identity is persisted through the same path a real login uses, so the resolver ladder is unchanged. Two seams differ: token acquisition re-exchanges the anon credential (no refresh token), and routing pins the welcome host's single model nous/welcome. One identity per shared store; nous.guest: false turns the free tier off. * test(auth): free tier core contracts: lifecycle, resolver precedence, exchange seam, model pin * docs(user-guide): free tier and signing in New page explaining what a fresh install gets before any key or sign-in (free inference on nous/welcome plus connectors), how the free tier coexists with a user's own API key, how to sign in with hermes auth upgrade and keep connectors, how to turn the free tier off with nous.guest, what hermes logout does in each state, a troubleshooting table, and a plain privacy note. Wired into the Using Hermes sidebar. * fix(auth): logout leaves the free tier alone and clears the shared store for a real Nous account Logging out of the free tier is a no-op: it is not a login, so nothing is cleared and the user is told they were never signed in. Logging out of a real Nous account now also clears the cross-profile store, so a profile logout is not silently re-adopted on the next boot. * fix(model): switching off the free tier points at signing in, never hops providers * Name the free tier in the gateway startup notice and tell explicit-provider installs about it once * Render the Nous free tier as free tier on auth status, auth list, hermes status and portal info, short-circuit billing copy for it, and skip the keepalive when there is no refresh token * fix(auth): free tier is set up where nothing is configured: resolver last rung and first-run check Both the provider resolver's terminal rung and the CLI first-run check now try to set up the free tier before declaring nothing configured. On a fresh install the first command lands in chat on nous/welcome; a failed setup still falls through to the existing guidance. * Add hermes auth upgrade: sign the free tier into a Nous account while keeping its connectors The device-code flow runs as usual, with a promotion intent registered on the portal between the code request and the token poll so the account that approves the code inherits the free tier's connectors. The promotion status decides the outcome: only a completed one is followed by the token grant, which is persisted over the free-tier singleton and the shared store. Declined, superseded, retired and busy outcomes each print their own plain copy, and a retired identity is cleared so the next use sets up a fresh one. User-facing text never names the free tier's internals. * Show the Nous free tier as one picker row with nous/welcome and hide it when nous.guest is off * fix(auth): upgrade opens the consent page for this sign-in; one mint attempt per process; forced free tier wins the first-run check The browser leg of hermes auth upgrade now prints and opens the promotion claim URL with the claim code, not the generic device page. A failed mint is attempted once per process so several bootstrap sites cannot hit a closed gate or a 429 twice; a retired credential resets that so re-minting still happens. HERMES_FORCE_GUEST is honoured ahead of the first-run provider check. * fix(auth): pin the welcome model on the selected route, not on profile state; background setup retries after a failure A credential-pool entry can select a paid Nous key while the profile singleton is still the free tier. The model pin now keys on the resolved endpoint (welcome host) in agent init and /model, and the pin in model normalization is removed since it had no route to look at. A failed background identity setup releases its latch so a later attempt in the same process can try again. * fix(auth): decide the Nous model together with the route on every credential-pool swap The credential pool can move a Nous agent between the welcome host and the portal host after init. One helper, pin_model_for_route, now runs at init and inside every pool swap, so the welcome host always carries nous/welcome and a paid endpoint always keeps the caller's model. * fix(auth): apply the route model policy on every wire mode during a pool swap; release the setup latch if the thread cannot start * fix(auth): free-tier lifecycle takes profile then shared lock, reconciles with the shared store, persists the mint before exchanging, and clears only the identity that died The shared store is the identity of record for a Hermes root: a profile holding a stale free-tier identity adopts a sibling's newer sign-in instead of keeping the guest, and never overwrites the shared account. Locks are taken in the documented order (profile, then shared). A minted credential is stored as soon as create succeeds, so a rate-limited or timed-out exchange does not lose it and trigger a second mint. Retiring a dead credential removes only that credential from both stores. Guest exchange uses the resolver's canonical portal URL. * fix(auth): a credential rotation never rewrites the conversation model; connectors honour the off switch and replace a retired free-tier credential The welcome host serves one model, so a rotation onto it is refused for any conversation on another model instead of silently switching that conversation to nous/welcome (the model pin applies only when a route is first chosen). The connector token path now treats the free tier as absent when nous.guest is false, including cached tokens, and shares the one dead-credential rule with inference: a retired identity is replaced once rather than returning its stale token. * fix(auth): plain login never imports the free tier as OAuth credentials; the gateway startup line reads persisted state only A free-tier identity in the shared store is not an OAuth credential to offer for import; a real sign-in replaces it. The gateway's startup notice now answers provider precedence from persisted state (no token refresh at boot), so an expired free-tier token cannot stall the online message.	2026-09-11 03:45:31 +05:30
Justin Bennington	8b2b83a906	fix(providers): pin all Actual routes to chat completions (E-1047)	2026-09-10 14:56:55 -04:00
Justin Bennington	d7b0a72c2a	fix(providers): route Actual through chat completions (E-1047)	2026-09-10 14:56:55 -04:00
Teknium	d9ca9c974d	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. Two sources, same invariant as passwords (the code goes to the page over the supervisor socket and never enters model context): - a TOTP seed on the login: local vault `otp_secret` (RFC 6238, stdlib, verified against the RFC test vectors), 1Password `op item get --otp`, Bitwarden `bw get totp`. Nobody is asked. - no seed: the surface prompts "Verification code for {site}"; the user types what their phone/email/app shows. Enter on empty / Skip declines and the tool returns code_declined ("do not ask again this turn"). no_code_field tells the model the site wants a passkey / hardware key / app approval: hand it to the user's device and wait for navigation. Per-digit OTP boxes (maxlength=1 pattern) get one digit each in DOM order. Surfaces CLI: sudo-style panel, code shown as typed (not a secret worth masking, typos must be visible), Enter submits, ESC/empty skips. Desktop: "Verification code for {site}" card via vault.code.request / vault.code.respond (gateway), owner-routed like the other vault prompts. Settings → Passwords & Logins: optional "Authenticator key" field on the add form (base32 or otpauth:// link); items with one show a "2FA auto" badge. `hermes vault add` asks for the same optional key. browser_vault_fill's result now says what to do next ("if the site asks for a verification code, call browser_vault_enter_code with this handle"). Six locales. Verified live (real model, local 2FA site that checks the TOTP; CLI PTY): A. login saved with authenticator key → signed in through 2FA, zero prompts, code/password absent from the transcript B. login without key → code panel → user types code → signed in C. panel dismissed → agent stops and explains, never asks in chat Unit: RFC 6238 vectors, seed normalisation, mint-without-asking, per-digit spread, decline, no-code-field; Desktop card test (owner routing, trim, Skip).	2026-09-10 11:48:01 -07:00
Teknium	77e55b4d1f	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.	2026-09-10 11:18:16 -07:00
Teknium	438a313500	docs(honcho): document a2aSessions and per-author writes on the site page	2026-09-10 10:45:57 -07:00
Teknium	98d11c95f4	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.	2026-09-10 10:35:07 -07:00
Teknium	c8998c3957	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.	2026-09-10 10:35:07 -07:00
Teknium	dedc99ec6c	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.	2026-09-10 10:35:07 -07:00
Teknium	5aa9e7f033	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.	2026-09-10 10:35:07 -07:00
Teknium	92e0de0ac4	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.	2026-09-10 10:35:07 -07:00
Teknium	cde0ad0edd	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	2026-09-10 10:35:07 -07:00
Teknium	103fe14cb4	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.	2026-09-10 10:27:07 -07:00
Teknium	7e0b5cd235	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.	2026-09-10 09:11:00 -07:00
Teknium	2feb546828	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.	2026-09-10 09:07:35 -07:00
Teknium	248ff2d3e8	feat(desktop): one row per plugin; desktop halves are app-level copies, never profile-scoped ... Capabilities → Plugins is now a single table: one row per PACKAGE, with a Desktop column (this app) and an Agent column (the selected profile). A package with both halves is one row, never two; the kind badge is inferred from what it ships (plugin.yaml → agent, plugin.js → desktop). The desktop half of a unified agent+desktop package no longer loads from the profile-shaped `plugins/<name>/desktop/` folder. Electron copies that half into `~/.hermes/desktop-plugins/<name>/` beside a `.hermes-package.json` marker (package name, source, origin repo/sha) and keeps it in sync: newer source → re-copy, package uninstalled → copy removed, hand-installed standalone folder of the same name → never overwritten. The renderer scans exactly one root, so a pane can never appear, disappear, or re-scope when the user switches profiles — the same switch reads the same value everywhere. Why a copy rather than scanning every profile: two profiles can carry the same package at different SHAs; a scan has to pick one silently. One copy, one source of truth, stamped with where it came from. - plugin-packages.ts: pure merge of desktop records + agent rows → rows - plugins.manage list reports `has_desktop_half` so the pairing is explicit - Install dialog (local backend): the desktop half is materialised from the installed package instead of cloning a second standalone copy; remote backends keep the separate clone. Target path now names the real profile folder for non-default profiles. - "Install here": a desktop half whose agent half is missing in the selected profile pre-fills the dialog from the marker's origin; disabled with an explanation for hand-copied folders with no origin. - Profile selector moves into the Agent column header; hidden with 1 profile - Rescan/Update reconcile the copies BEFORE rescanning (ordering bug) - Drop the dead `agentPluginsRoot` IPC; docs updated (desktop.md, SDK, bot-mode.md, hermes-desktop-plugins reference) Live-dogfooded on a headless Electron with two profiles and a real file:// git package: install both halves, profile switch ×3, Install here into the second profile, v2 update via `hermes plugins update` → chip text changes on Rescan, uninstall from both profiles → copy and row gone, broken plugin row, cold restart, sash drag/reset, legacy Settings → Plugins redirect.	2026-09-10 08:19:55 -07:00
Teknium	ff93f0ee9b	fix(desktop): desktop plugins are app-level, not per profile; catalog gets a drag sash; Accent Picker moves to its own repo ... Three things Teknium hit on the merged Plugins page: 1. Desktop plugins vanished on profile switch. `fs-ipc.ts::localPluginsRoot` resolved `<HERMES_HOME>/profiles/<active>/desktop-plugins` for a named Desktop profile, so a disk-installed plugin only existed under the profile it was installed from. Desktop plugins extend the app, not an agent; the root is now `<HERMES_HOME>/desktop-plugins` regardless of profile, gateway or remote machine (`electron/desktop-plugins-root.ts`), with a one-time migration that lifts any per-profile folders into the app root (root copy wins on collision). Agent-plugin and logs roots stay profile-scoped. On the page, the profile selector now renders INSIDE the framed Agent plugins block as its header, and Desktop plugins sit outside that frame, so the scope boundary is visible without reading the blurb. 2. The catalog viewport could not be resized. It gets the same top-edge drag sash as the Skills hub picker (persisted height, double-click resets, clamped so the lists above keep real height; iframe pointer-events off while dragging). 3. Accent Picker, a theme-authoring toy shipped off by default, is removed from the bundled set and published as a standalone desktop plugin at https://github.com/NousResearch/hermes-desktop-accent-picker (same source, esbuild-bundled plugin.js importing only the three loader-resolvable specifiers). Docs point there.	2026-09-10 08:19:55 -07:00
Teknium	8092f0e8ee	fix(desktop): leaving HUD mode always gives the app window back (macOS) ... Symptom (Discord/X report, macOS): exit HUD mode and the small HUD window stays on screen while the main window never regains focus; the toggle now reads the wrong state, so there is no in-app way out. Three defects in the HUD lifecycle, all in the main process: - closeHudWindow() detached the window's 'closed' listener before calling win.close(). close() is a REQUEST that waits on the renderer's unload handlers, so a HUD renderer that never answered left an always-on-top window with no teardown owner and no close broadcast. The 'closed' handler now stays attached and is the single teardown path; a bounded requestHudClose() (electron/hud-close.ts) destroys the window after a 1.5 s grace if the renderer never lets go. - ⌘W inside the HUD was routed to the MAIN renderer's close-active-tab (installPreviewShortcut is wired on every chat window), so it closed a tab in the hidden app window and left the HUD up. ⌘W in the HUD now runs closeHudWindow(), the same path as the exit button. - restoreMainWindowFromHud() was a bare show() and only armed when the main window was isVisible() at HUD-open time. On macOS isVisible() is false for an occluded window (Electron folds occlusionState in), so the app never came back when the HUD was opened over another app, and show() alone does not make the window key. The restore now arms on a live main window and routes through focusWindow() (restore → show → focus). Closes #88513 (credit: PR #90489's diagnosis). Renderer: the handoff now also requests composer focus on the close broadcast, so the app window gets the keyboard, not just the session. Docs: ⌘/Ctrl+W added to the HUD exit list.	2026-09-10 08:19:13 -07:00
Teknium	6d89c1afde	feat(plugins): pin a plugin to a commit from Desktop, and show pins in every list ... Only the CLI could install a plugin at an exact commit (`--ref <sha>`); the Desktop "Install from Git" dialog, the TUI gateway `plugins.manage install` method and the dashboard `/agent-plugins/install` endpoint all called `_install_plugin_core` without a ref, so a team that wanted everyone on the same private-plugin commit had to leave the app for a terminal. - `dashboard_install_plugin(ref=)` threads the pin to `_install_plugin_core`; the 40-hex validation and HEAD verification are unchanged. The gateway method and dashboard body accept `ref`. - Desktop dialog gains an optional "Pin to commit" field (custom sources only, client-side 40-hex check disables Install on anything shorter). - `plugins.manage list` rows carry `pinned_sha`; the Desktop plugins tab shows a `pinned @ <sha8>` badge and `hermes plugins list` prints `git pinned@<sha8>` in Source, so a team can eyeball that everyone runs the same commit.	2026-09-10 05:09:15 -07:00
Victor Kyriazakos	49ef015ca3	fix: join delegated work before finite chat exits	2026-09-10 05:02:41 -07:00
kshitijk4poor	4a76e99f87	docs(cron): drop stale mirror-scope wording left by the home lane ... - `_target_matches_origin` docstring still claimed fan-out targets are "deliberately NOT mirrored" and mirroring is origin-only; that has been false since origin_fallback landed and is doubly so with the home lane. Point to `_target_mirror_eligible` for the policy instead. - cron.md DM-only bullet said "origin DM session"; the config comment in the same change already says "target DM". Align. - Remove two `_expand_routing_tokens` unit assertions bolted into the eligibility test; the `" ALL , slack "` parametrize covers expansion end-to-end through `_resolve_delivery_targets`.	2026-09-10 15:32:47 +05:30
Victor Kyriazakos	22356075f1	fix(cron): make user-written bare-platform home targets continuable ... A managed cron with `deliver: "slack"` (no captured origin) delivers to the Slack home channel, but the brief was never mirrored into that session and the in_channel seed never fired: bare-platform targets resolved with no `_resolved_from` provenance, so `_target_mirror_eligible` treated them like `all` broadcast expansions. - `_resolve_delivery_targets` derives `from_broadcast` from the raw token and passes it to `_resolve_single_delivery_target`; a user-written bare platform token is tagged `_resolved_from: "home"`, `all` expansions stay untagged (fan-out is never continuable). - `_target_mirror_eligible`: `home` eligible under the same flags as `origin_fallback` (per-job attach_to_session wins, else cron.mirror_delivery). - `_MIRROR_PROVENANCE_RANK`: `home` == `origin_fallback` so token order through dedup cannot strip eligibility. - Docs, tool schema text, cron/gateway AGENTS.md updated; existing exact-dict pins carry the new key. Squashed from PR #101819 (commits 5fe612c9, 65e36926, 10e0af1d, f2cc4639): they predate the cron/scheduler.py -> scheduler_delivery.py split and do not cherry-pick individually onto current main.	2026-09-10 15:32:47 +05:30
Teknium	6271d772d2	docs: Telegram Quick setup on Desktop and the Messaging restart banner	2026-09-10 02:48:21 -07:00
Teknium	61afcde8f9	refactor(desktop): one Plugins surface — Capabilities → Plugins owns agent + desktop plugins, install, and the catalog ... Plugins were split across two pages that each showed half the picture: Settings → Plugins listed desktop plugins plus "Install from Git" and a pointer saying agent plugins live elsewhere; Capabilities → Plugins listed agent plugins plus the catalog picker but knew nothing about desktop plugins. A user asking "what extends my Hermes and where do I add more?" had to visit both and still could not see the whole set in one place. Capabilities → Plugins is now THE plugins page: - Agent plugins section (scoped to the profile selector) with the "Install from Git" button in its header — installs target the scoped profile, not whichever one is active. - Desktop plugins section beneath it (same for every profile), with the folder/rescan controls and the "agent half missing here" drift chip, whose repair also lands in the SCOPED profile. - The catalog picker underneath, unchanged. Settings → Plugins is removed. `/settings?tab=plugins[&plugin=…]` and the existing `?tab=mcp` redirect share one table (`settings/moved-tabs.ts`) so old bookmarks and palette links land on the same row on the new page. Command palette: plugins moved from the Settings group to the Capabilities group; installed-plugin rows deep-link to `/skills?tab=plugins&plugin=…`. Dead `settings.plugins.agent.*` and `settings.nav.plugins` i18n keys dropped; docs and in-code pointers say Capabilities → Plugins.	2026-09-10 02:30:50 -07:00
Teknium	9886f6e53b	feat(plugins): install plugins from private git repos using the user's stored credentials ... `hermes plugins install owner/private-repo` failed for every private repository even when the same user could `git clone` it from their shell: the hardened `noninteractive_git_env` disables credential helpers, askpass and global config (so a hostile repo can't make our plumbing prompt or hang), which also blocks the user's own stored credential. The result was "could not read Username" or a 60s hang on a GUI askpass, with no hint about how to authenticate. New `hermes_cli/git_credentials.py` resolves a credential up front from sources the user already owns — GITHUB_TOKEN/GH_TOKEN (profile-scoped), `gh auth token`, then `git credential fill` against their configured helpers with prompting disabled (any host) — and hands it to git as a one-shot `http.<origin>/.extraheader` via the GIT_CONFIG_* env block. Nothing lands in the URL, `.git/config` or install metadata. The same path covers `plugins update`, catalog MCP git installs and profile-distribution staging, which share the same hardened env and the same failure. A private-repo clone with no credential now fails fast with an actionable hint.	2026-09-10 01:00:19 -07:00
brooklyn!	a6102b8d80	docs(desktop): document Radio controls and privacy	2026-09-09 22:57:27 -05:00
Siddharth Balyan	b4d04eb8fd	Connector tools (Gmail, Linear, Notion, ...) are searchable and callable through tool_search for signed-in Nous users (#106842) ... * feat: add session-scoped connector access for onboarding * fix(connectors): availability is the config flag AND the portal entitlement — no free-tier leg The port carried a third availability leg from hermes-magic: a stored guest (free-tier) identity short-circuits the managed-tool entitlement check. That leg reads hermes_cli.anon_auth, which does not exist on hermes-agent main, so connectors_available() raised ImportError inside its fail-closed try and the whole connector surface was silently dark on a plain upstream checkout. On this tree availability is the two-leg AND the design started with: tools.connectors.enabled AND managed_nous_tools_enabled(). The free-tier leg is a hermes-magic concern and belongs in hermes-magic's own delta over this branch, next to the identity it depends on. Its integration test goes with it. * docs(tool-search): connectors section — remote tools through the bridge The squashed port carried the code but not the user-facing docs. Restores the Connectors section of the Tool Search page and the connector-gateway host / CONNECTOR_GATEWAY_URL override on the Tool Gateway page, updated for the manage_connections tool and the pure-connector batch rule. * fix(tool-search): connector tools rank with local tools in one pass instead of taking leftover slots dispatch_tool_search ran BM25 over the local catalog, filled `limit` slots, then appended connector hits only into slots left empty. On a 300-tool catalog no slot was ever empty, so with Gmail and Google Calendar connected "send gmail email" returned five betterstack tools and zero connector tools. The gateway's hits for a query now become catalog entries (connector name, slug words, description as the search text) and join the local catalog for that query's BM25 pass. One ranking, one rarest-token admission rule for both sources, `limit` as the total per query. The merge loop and the separate record builder for connector hits are gone; `_shared_tool_record` serves both sources. The gateway search timeout rises from 8 s to 30 s. One request with six use_cases measured 7 s, so 8 s sat on the edge and cut real answers off; the failure path is unchanged (local-only results, no error to the model). Live, 311 local tools + gateway, before -> after: "send gmail email": 5 betterstack tools -> gmail SEND_EMAIL, CREATE_EMAIL_DRAFT "read google calendar events": 5 betterstack tools -> googlecalendar EVENTS_LIST_ALL_CALENDARS "linear create issue", "betterstack incident": unchanged Benchmark (25 labelled queries): connector recall 0.09 -> 0.82, precision@5 0.18 -> 0.59, false positives on absent intents 17 -> 2. * refactor(tool-search): connector leg into tools/connector_search.py tools/tool_search.py is a facade. The connector leg (gateway hits as catalog entries for tool_search, remote schemas for tool_describe, the connections_in_scope gate) was appended to it by the port. It now lives in its own sibling, tools/connector_search.py, and the facade imports the three entry points: connections_in_scope, connector_entries_by_group, remote_schemas_for. No behaviour change. The tool_describe remote block became remote_schemas_for(names, current_tool_defs, connector_describe) with the same inputs, the same silent-degradation contract and the same injection seam the tests already use. * fix(tool-search): at most 7 queries per call, the gateway's search limit One tool_search call sends all its queries to the connector gateway as one search request. The gateway answers 7 use_cases per request and returns HTTP 502 for 8 or more (measured 2026-09-09, re-measured with one-word use_cases: it is a count limit, not a size limit). With the client cap at 10, a model sending 8 to 10 queries lost every connector hit for that call and saw local-only results with no error. The shared constant splits: _MAX_QUERIES_PER_CALL = 7 for search, _MAX_DESCRIBE_NAMES_PER_CALL = 10 for describe, which has no remote count limit. Eight or more queries now get the existing "too many queries" retry hint before any request is made. No chunking: one call, one request. * fix(tool-search): the model is told that connectors__ names are manage_connections accounts tool_search results carry names like connectors__gmail__CREATE_EMAIL_DRAFT and manage_connections is the tool that checks and connects those accounts, but nothing told the model the two are the same thing. A model that hit CONNECTION_REQUIRED had to infer the fix on its own. The tool_search description gains one sentence making the link, added at assembly only when manage_connections is in the session's tools. Signed out or with connectors off the tool is absent and the description is unchanged, so it never names a tool the model cannot call. This follows the existing rule for cross-tool references (tools/AGENTS.md): they are added dynamically from the session's actual tool set, never hardcoded in a schema. Tool defs are fixed for the life of a conversation, so the description is byte-stable per conversation; this is a one-time prefix change. Live, real get_tool_definitions() against a signed-in home: sentence present. Same home with auth.json removed: manage_connections absent, sentence absent. * fix(connectors): /stop halts a connector batch before the next remote call dispatch_connector_batch runs every remote entry of a tool_call batch in sequence. The executor only checks the interrupt flag between tools, and the whole batch is one tool to it, so a /stop landing during entry 1 of 20 still sent the other 19 to the gateway. The loop now reads tools.interrupt.is_interrupted before each dispatch. Once set, it stops calling handle_function_call and fills every unstarted slot with the loop's existing error-slot shape, code INTERRUPTED and the message "Stopped by the user before this call was made.", so the result envelope stays valid and the counts stay honest. Entries already dispatched keep their real results. Test: three connector calls where the fake client sets the interrupt on the first execute. The client sees exactly one call and slots 2 and 3 carry INTERRUPTED. Red on the base branch, green with the fix. * test(connections): schema assertions become dispatch contracts test_schema_documents_wait_and_its_timeout froze description fragments ("REQUIRED", "can NOT disconnect", "Nous Portal"). A wording edit fails it while a real regression (a disconnect that reaches the gateway) does not. That is a snapshot of prose, not a behaviour contract. Delete it. The requirement that wait needs connectors is already covered by test_wait_requires_connectors. The user-only disconnect boundary is now asserted as behaviour: action disconnect with a connector returns an error and the fake client records no call. That replaces the earlier de-authenticate test, which only checked that the word "dashboard" appeared in the error text. Test count in the file goes from 26 to 25. * docs(tool-search): connector batches are one gateway request per entry The user guide said a connector batch travels as one gateway request. It does not: model_tools_connectors.dispatch_connector_batch re-enters core dispatch per entry, and each entry becomes its own execute request in bridge._run_remote (plus at most one literal-slug retry when the gateway reports TOOL_NOT_FOUND under the conventional slug). The docstrings in tools/tool_gateway/bridge.py and tools/tool_gateway/__init__.py still described the abandoned V1 plan and claimed nothing outside the package imports it. Rewrite those sentences to match the code: one request per entry, in input order, dispatched from model_tools_connectors.py, with the per-entry approval and interrupt behaviour that motivated the split. The guide also still showed the single-call shape tool_call(name, arguments); both places now show the `calls: [{name, arguments}]` array the schema advertises and note that a single local call is an array of one. Docs only, no test. * fix(tools): the between-turns refresh never rewrites the bridge tools The per-turn MCP refresh folds a fresh tool snapshot into the live array with preserve_prefix: order and membership stay, but a name present in both takes the fresh schema. That is right for ordinary tools, whose schema is a constant. tool_search is the one tool whose description is derived from the session: the deferred-tool count, the embedded listing, and, on this branch, whether manage_connections was present. A late MCP server or one failed portal lookup (manage_connections' check_fn fails closed) changed those bytes on the next turn, and every byte after tool_search in the cached prefix was re-prefilled. The array also contradicted itself in that case: the flapping manage_connections was carried forward while the description lost its hint. The bridge entries now keep the bytes they were built with for the life of the conversation. Nothing is lost: tool_search reads the live catalog at dispatch, so tools that arrived late are still found; connector availability is checked at dispatch too. The compaction-boundary rebuild (content_aware, the one sanctioned cache break) still refreshes the description. Consequence: connector exposure in the prompt is decided once, at agent build, by whether the user was signed in then. That is the intended contract. * refactor(tool-search): normalize_tool_call_entries lives with the other argument validation The port appended the tool_call argument parser to the tool_search facade. The family already has tools/tool_search_validation.py for exactly this work (schema validation of deferred call arguments), so the parser moves there and the facade imports it. No behaviour change; the one test that imported it now imports from the defining module. * refactor(connectors): delete the unused batch dispatcher; _run_remote becomes run_remote bridge.dispatch_calls and its helpers (_dispatch_calls_inner, _run_pre_dispatch, _run_local, _error_slot, _maybe_parse_json) and the LocalDispatch / PreDispatch seams had no production caller. Connector dispatch runs through model_tools_connectors: dispatch_connector_batch re-enters handle_function_call once per entry, so scope, hook, approval and middleware policy fire against each composed name inside core dispatch, and dispatch_connector_call hands the single planned entry to the bridge's transport function. Only tests called the batch dispatcher, and they exercised policy seams that production never wires. The transport function is the module's real entry point, so it drops the underscore: _run_remote becomes run_remote, body unchanged. The module docstring now describes the two legs that exist (availability with D32 silent degradation, and run_remote) instead of the injected seams. Imports that only the deleted code used are gone; merge.py is untouched because every export still has a caller. Tests that drove dispatch_calls are deleted where they covered the removed seams (pre_dispatch blocks and rewrites, local_dispatch classification, mixed batches). The literal-slug fallback, the per-entry transport failure, and the hook rewrite reaching the gateway request body are re-targeted at handle_function_call('tool_call', ...) with the fake client swapped in at bridge._default_client_factory, the same seam test_connector_dispatch_policy uses. Each re-targeted test fails when the retry is disabled in run_remote. * fix(connectors): search keeps the twin a colliding name reaches, and says so format_connector_name strips the toolkit prefix, so GMAIL_FETCH_PROFILE and a literal FETCH_PROFILE on gmail both compose to connectors__gmail__FETCH_PROFILE. describe and execute decode that name to the prefixed slug first, so the literal twin is unreachable under it. If a vendor ever shipped both, search could describe the literal under a name that runs the prefixed tool. Search is the one place that sees both twins in one response. It now keeps the twin the name reaches and drops the other with a WARNING that names both slugs, whichever the gateway listed first. Short names stay; no marker, no per-process map, no change to describe or execute. No such pair exists in the live catalog today; the guard turns a silent alias into a logged one.	2026-09-10 02:21:16 +05:30
Siddharth Balyan	cf4b78e91f	fix(tool-search): a query no tool answers returns nothing, not five tools sharing one word (#106676) ... search_catalog admitted every document with BM25 score > 0 and then padded to `limit`. BM25 sums over the tokens a document shares with the query, so on a 300-tool catalog "send gmail email" returned five incident tools that shared only "email", and the discriminating word ("gmail", in no document) had no say. The model read those as the answer. Admission is now the query's rarest token: a document is a result only if it contains the query token with the highest IDF, the one that names the intent. Common verbs ("send", "read", "create") sit in dozens of documents and never gate; vendor and object words ("gmail", "github", "incident") do. A token no document carries admits nothing, and the existing empty-group hint tells the model to retry without it. The name-substring fallback is deleted: it admitted tools that matched no query token at all. Result descriptions are clipped at 500 characters instead of 400. Over 353 vendor tool descriptions, 500 keeps 91% whole and every first sentence (first-sentence max 329); 400 kept 82%. Measured on the live 311-tool catalog with 25 hand-labelled queries: precision@5 0.18 -> 0.43, wrong names returned 102 -> 66, false positives on absent intents 17 -> 13. Live before/after: "send gmail email" went from five betterstack tools to an empty group with the retry hint; "linear create issue" and "betterstack incident" are unchanged.	2026-09-10 02:21:15 +05:30
teknium1	b27c6f7f0d	docs(line): document LINE_EXPIRED_TEXT beside the other postback reply knobs	2026-09-09 11:47:55 -07:00
Teknium	d5926b2494	fix: persist API delegation units once without waking the model	2026-09-09 10:55:32 -07:00