7322 Commits

Author	SHA1	Message	Date
Teknium	f923faa0b8	feat(voice): GPT-Live voice chat mode — a full-duplex voice frontend that delegates to Hermes (Desktop) ... `voice.voice_chat_mode: gpt-live` swaps the desktop's chained STT → turn → TTS loop for OpenAI's gpt-live-1: one voice model that listens while it speaks and has no tools of its own. Every real request it hears becomes a normal Hermes turn on the open chat — any model/provider the session selected, full toolset, memory, approvals — and the voice paraphrases the reply aloud. Backend - tools/voice_live.py: mode/credential/persona resolution and the one server-side step the API needs — POST /v1/live/sessions exchanging the renderer's SDP offer, pinned to client delegation; the OpenAI key never reaches the renderer. Voice persona follows the vendor prompting guide (role, style, labelled delegation policy describing Hermes as the backend). VOICE_LIVE_TURN_NOTE is the per-turn model-input note (transcript in, speakable prose out). - REST: GET /api/audio/voice-live/status (mode + readiness, non-secret), POST /api/audio/voice-live/session (SDP exchange). The offer is passed byte-exact: a stripped trailing CRLF is a vendor 400 "unmarshal SDP: EOF". - prompt.submit accepts surface=voice-live (+ voice_context) beside hud; the note rides the model input via the existing _prepend_note seam, the persisted user row stays the user's words, the system prompt stays byte-stable. - config_defaults: voice.voice_chat_mode (chained|gpt-live), voice.gpt_live.*. Desktop - lib/voice-live.ts: RTCPeerConnection + oai-events data channel owner, transcript accumulation, session.commentary/thinking/instructions appends (500-token chunking), mute, graceful close waiting for session.closed. - hooks/use-voice-live-conversation.ts: same public shape as useVoiceConversation; delegation → prompt.submit(surface=voice-live); tool activity → quiet thinking appends; reply streamed back per sentence; spoken stop phrase ends the chat; a newer delegation interrupts an in-flight turn. - use-composer-voice mounts both engines and latches one at conversation start from the backend-resolved status; gpt-live without a key falls back to chained with a notice. Settings → Voice gets the mode dropdown, voice picker, persona. Live-verified on the worktree desktop build (headless Electron, CDP, synthetic mic): "what is 17 times 23 and which model are you on" → delegation → Hermes (Claude Sonnet 4.5 via OpenRouter) → spoken "391 … Claude Sonnet 4.5 through OpenRouter"; follow-up "double that" resolved from the spoken context → 782; "run uname -r" ran the terminal tool with "Hermes is working: terminal" fed as quiet context → spoken kernel version; "stop" closed the session (reason=close_requested). Chained mode creates no RTCPeerConnection.	2026-09-11 19:14:24 -07:00
Teknium	fafb27ee5c	feat(plugins): on_room_member_activity hook projects Group Chat member runtime events to plugins ... A hosted room member runs on a hidden room_plumbing session with no client transport, so the tool.start/complete, approval.request, message.delta and reasoning.delta frames its turn already emits bottom out at stdio and vanish. Between turn.started and turn.settled in the durable room log a client sees a black box, and community clients (Hermes Crew) cannot render tool cards, approvals or live member status without inferring them from text. One seam in write_json (plus the connector bypass in tool_progress) re-routes those frames, stamped with the session's _hosted_room_task coordinates (room_id, thread_id, member_id, turn_id, task_id, execution_generation), to a new observer hook through the bounded per-consumer queues on_stream_* already use, so plugin code never runs on the token path. Nothing is written to the room log: deltas would exhaust a room's byte budget in minutes and checkpoint replay must stay a pure function of the durable events. The task stamp gains member_id (the driver already knows it; the proof did not carry it). Group Chat keeps execution, scheduling and persistence; plugins own presentation.	2026-09-11 19:04:58 -07:00
Teknium	66adfaee6b	refactor(git): trim safe.directory tests to two invariants, memoise the config read ... Tests: fold the ambient GIT_CONFIG_KEY_n negative and the isolation-still-in-force assertions into the ordering test, and drop the two positive-only cases it subsumes. What remains pins the injected sequence to git's own `config -z --get-all` output and asserts the real trust decision (named repo usable, unrelated cross-owner repo refused). Cost: noninteractive_git_env() runs on every internal git call, including the banner startup probe, and the two `git config` children added ~10 ms per call against ~0.2 ms before. Memoise per process on the inputs that select the config files plus the system/global candidates' mtimes, so an edit to ~/.gitconfig is picked up without a restart (verified live: 128 -> 0 within one process after appending safe.directory).	2026-09-11 19:01:47 -07:00
privacydied	02200f0b65	fix(git): preserve safe.directory ordering and reset markers when carrying it ... Review of #107748 found the carry path serialized the user's trust policy incorrectly, and the mistake could WIDEN trust rather than merely reformat it. safe.directory is an ordered multi-valued protected setting: an empty value resets every entry seen so far. That is the documented mechanism for revoking a system-wide `safe.directory=*` and then naming only the repositories you actually trust. The previous helper broke all three properties that make it work: * read `--global` before `--system` (git's precedence is system, then global) * dropped empty entries via `if entry:`, deleting the reset marker * de-duplicated values, though it is a sequence and not a set Reproduced with real git (2.55.0 here, 2.47.3 by the reviewer). Given system `safe.directory=*`, global `safe.directory=` then `/trusted/only`: real git, user's own policy -> rc=128 (dubious ownership) previous head's sequence `/trusted/only`, `*` -> rc=0 (trust widened) this head's sequence `*`, ``, `/trusted/only` -> rc=128 (matches real git) So a user who had deliberately revoked a machine-wide wildcard silently got it back inside Hermes's internal git calls. That contradicted the "read-only and non-widening" claim the original change rested on. Fix: read scopes lowest-precedence first (system, then global) and replay every value verbatim -- no de-duplication, no dropping of empty reset markers. Read with `git config -z` so a value containing whitespace or a newline stays the one entry git reads it as, instead of being split into several bogus trust entries by splitlines()/strip(). The trailing field of a -z stream is always empty and is discarded; interior empty fields are real resets and survive. Two invariant tests, both proven red on the previous implementation: * the injected sequence equals `git config -z --get-all safe.directory` for the same two config files, asserting git's documented reset shape * an E2E trust decision under GIT_TEST_ASSUME_DIFFERENT_OWNER=1: the named repo stays usable and an unrelated cross-owner repo is still refused, proving the reset still revokes the wildcard 13 passed in tests/hermes_cli/test_noninteractive_git.py, 69 in tests/security/test_gitspawn_config_injection.py and tests/tools/test_checkpoint_manager.py.	2026-09-11 19:01:47 -07:00
privacydied	01a3206e90	fix(git): carry user safe.directory past non-interactive config isolation ... `noninteractive_git_env()` blanks GIT_CONFIG_GLOBAL/SYSTEM to /dev/null so a user's config cannot hang Hermes's internal git plumbing with pagers, hooks or credential prompts. Sound intent, but it also discards `safe.directory` — and git honours that key ONLY from global/system config (it is rejected from repo-level config by design, so a hostile repo cannot self-authorise). Result: every internal git call fails on a repo whose st_uid != geteuid(): $ hermes -w ✗ Failed to create worktree: fatal: detected dubious ownership in repository at '/mnt/nas/py/repo' That hits NFS/CIFS mounts without idmapping, shared checkouts, and containers with a remapped uid. The user's own `git config --global --add safe.directory` is correctly set and their interactive git works — Hermes throws the setting away before git reads it, so the error's own suggested remedy can never fix it. There is no config or env escape hatch: the blanking is unconditional. Reproducer (any repo where the checkout uid differs from the caller's): git rev-parse HEAD # works GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null \ GIT_CONFIG_NOSYSTEM=1 git rev-parse HEAD # dubious ownership Fix: read the user's real `safe.directory` values before the isolation is applied, then re-inject them over the GIT_CONFIG_KEY_n channel, which survives GIT_CONFIG_GLOBAL=/dev/null. Isolation is unchanged — global/system config stay pointed at /dev/null and every hardening override still applies, since a later key of the same name wins in git's config order. Read-only and non-widening: only values already present in the user's own config are carried, so this grants no trust they had not granted. Ambient GIT_CONFIG_KEY_n injection is still stripped first, so a caller cannot launder an attacker-controlled path in this way — covered by a regression test. Tests: three cases in TestNoninteractiveGitEnv — entries carried past isolation, no entries injected when the user configured none, and ambient injection not trusted. All pin GIT_CONFIG_SYSTEM at an empty file, since a real /etc/gitconfig on the test host can otherwise leak entries and mask the assertions. Verified on Arch Linux, git 2.x, repo on an NFSv4 mount (uid 1024 vs caller 1000): `git worktree add` under the patched env returns rc=0 where it previously failed. 80 passed in tests/hermes_cli/test_noninteractive_git.py, tests/security/test_gitspawn_config_injection.py and tests/tools/test_checkpoint_manager.py, including the pre-existing assertions that the isolation stays in force.	2026-09-11 19:01:47 -07:00
Teknium	30e4673776	refactor(models): import openrouter_variant_base from its defining module ... Internal moves get no re-export aliases: models_validate reads hermes_constants.openrouter_variant_base directly and the private _OPENROUTER_VARIANT_SUFFIXES/_openrouter_variant_base shims are dropped.	2026-09-11 16:50:20 -07:00
jakobdylanc	284ee03df1	fix(models): resolve context length for OpenRouter :nitro/:floor routing variants ... `:nitro`, `:floor`, `:exacto`, and `:online` are request-time routing modifiers, not catalog models — OpenRouter's /models lists only the base id, and a variant runs the same model with the same context window. `get_model_context_length()` keyed every lookup on the full suffixed id, so each one missed and the resolver fell through to a generic family default or the 256K fallback: openai/gpt-5.5:nitro -> 256K (real 1.05M) x-ai/grok-4.6:nitro -> 131K (generic "grok" catch-all) anthropic/claude-opus-4.6:nitro-> 200K (generic "claude" catch-all) The window silently shrank, triggering early compression and a wrong /usage readout. f14059fa fixed the sibling half of this bug class in /model validation; this fixes the metadata half. Strip a recognized variant suffix for LOOKUP only, keeping the suffixed id on the wire so the routing opt-in survives. Applied after the explicit config overrides (steps 0b/0c) so a user-pinned value still wins, and before every cache/catalog lookup. Gated on the request actually routing through OpenRouter, so a local Ollama `model:tag` is untouched. `:free`/`:batch`/`:thinking` are deliberately excluded — those ARE distinct catalog SKUs with their own windows, so stripping them would report the wrong number. The suffix set and base-id split move to hermes_constants (import-safe, dependency-free) so the metadata layer shares one definition with hermes_cli.models instead of duplicating it.	2026-09-11 16:50:20 -07:00
Teknium	a6c5b7ada8	fix(serve): SSH-isolated idle-exit keeps the backend alive while a cron job runs ... turn_in_flight read only the dashboard session table; an in-process cron run never registers there, so the watchdog reported "no running turn" and exited mid-job (tool calls then failed with "cannot schedule new futures after interpreter shutdown", the execution was marked unknown, the slot lost). The probe now also consults cron.scheduler.get_running_job_ids — the ledger the gateway shutdown drain already uses. Addresses #107485	2026-09-11 15:28:37 -07:00
Teknium	0e57543908	fix(desktop): cron ticker follows the multiplexer allowlist and stands down for served satellites ... The Desktop/serve backend ticked every installed profile (ignoring gateway.multiplex_profile_allowlist) and gated only on the profile's OWN gateway.pid. A satellite served by the default multiplexer has no pid file, so both tickers raced its fires and the Desktop one won nondeterministically — adapter-less standalone delivery, and the environment behind #107485. Homes now come from profiles_to_serve with the default profile's allowlist (the multiplexer's served set); the per-tick gate also consults named_profile_served_by_running_multiplexer. Addresses #107485, #94590 Co-authored-by: fangliquan <fangliquan@qq.com>	2026-09-11 15:28:37 -07:00
tachyon-r	32c538851a	fix(desktop): yield single-profile cron to its running gateway ... (cherry picked from commit db92ff258f0138a251b2c4e14b32f2fa0b7b8d5b)	2026-09-11 15:28:37 -07:00
Teknium	37dcc0a6e8	fix(gateway): a secondary API_SERVER_KEY no longer skips the profile; start/install/status honour the live multiplexer ... Under gateway.multiplex_profiles the default gateway serves every profile, yet four startup/status paths still reasoned from the wrong source: * A secondary profile's API_SERVER_KEY (which the docs REQUIRE for /p/<profile>/ auth) auto-enabled api_server in that profile's config, so _load_secondary_profile_config raised SecondaryPortBindingConfigError and the whole profile was skipped. gateway/config_env.py::_enable_from_env now leaves `enabled` alone for port-binding platforms while a multiplexer loads a NON-default profile (home override + multiplex flag, the same signal gateway.config uses for scoped reads); the credential still lands in extra so the shared listener can authenticate the prefix. Default profile unchanged. * "Is this profile served?" was re-derived from the default config.yaml plus GATEWAY_MULTIPLEX_PROFILES as seen by the CLI process. `hermes -p coder ...` loads coder's .env, so an env-only opt-in on the default profile was invisible (guard never fired, status said stopped) and an allowlist edit flipped the answer before the restart. named_profile_served_by_running_multiplexer now reads the pid-verified default gateway_state.json served_profiles (written by _record_served_profiles) first and falls back to config derivation only when the key is absent. The record helpers live in hermes_cli/gateway_multiplex_served.py. * The served-profile guard ran only inside `gateway run`. `hermes -p X gateway start|install|restart` reached the service manager, whose unit then exited 78 forever (systemd parks it while the CLI prints "started"; launchd KeepAlive respawns every 30 s). The service verbs now run the same guard up front (exit 78, same message) and accept --force; the Desktop /api/gateway/start route returns 409 for a served profile instead of spawning a doomed child. * Status surfaces disagreed: `hermes -p coder status` said stopped, `hermes -p coder cron status` said "cron jobs will NOT fire" while `cron list` said fine, and the default `hermes status` never listed served profiles. Both now route through the probe / the recorded served set. The -p/--profile matcher in _scan_gateway_pids and gateway.status._command_line_belongs_to_profile compares the flag token for equality (`-p ops` no longer claims -- or lets `gateway stop` SIGTERM -- an `-p ops-2` gateway). Docs: multi-profile-gateways.md now describes the start/install refusal, the --force flags, the API_SERVER_KEY behaviour and the single default-home gateway_state.json (the per-profile runtime_status.json claim was wrong). Fixes #100397 Addresses #89726 #97360 #71344 (cherry picked from commit d002c1864a7b6a22c53758b16b7b0cc79aea2edf)	2026-09-11 15:27:23 -07:00
Teknium	a9838c2100	fix(multiplex): tool and memory-provider env reads stay inside the routed profile ... Under gateway.multiplex_profiles, os.environ holds the DEFAULT profile's .env; a secondary profile's values exist only in the per-turn secret scope. Every reader below still read os.environ/os.getenv at call time, so a secondary profile's turn silently used the default profile's value. Credentials (F6): FIRECRAWL_API_KEY (read_file hosted OCR), OPENVIKING_API_KEY, mem0-OSS OPENAI_API_KEY, MODAL_TOKEN_ID/SECRET and BROWSER_USE_API_KEY presence gates, and the xAI video plugin's os.getenv("XAI_API_KEY") fallback AFTER the scoped resolver had already missed — the exact fallback-after-miss shape gateway/AGENTS.md forbids. Deleted, not re-scoped: the resolver is the scope. Identity / tenant (F7): MEM0_USER_ID/AGENT_ID/HOST/MODE, SUPERMEMORY_CONTAINER_TAG, RETAINDB_PROJECT, OPENVIKING_ACCOUNT/USER/AGENT (and the whole layered() env read), HINDSIGHT_BANK_ID/MODE/retain shaping, HERMES_HONCHO_HOST. A raw read put a secondary profile's memories into the default profile's account/bank/ project/tenant and recalled them back into the default's turns. Each now uses get_secret with the provider's own per-profile default on a miss. Endpoints (F8): OPENAI_BASE_URL (aux custom runtime + direct-alias expansion), XAI_BASE_URL/HERMES_XAI_BASE_URL (aux OAuth), NOUS_INFERENCE_BASE_URL (#65941, both the aux builder and hermes_cli.auth_nous._nous_inference_env_override), GATEWAY_PROXY_URL (same UnscopedSecretError-only fallback shape as GATEWAY_PROXY_KEY three lines below), FIRECRAWL_API_URL, BROWSERBASE_BASE_URL, SUPERMEMORY/RETAINDB/HONCHO/HINDSIGHT URLs. The keys beside them were already scoped, so a secondary's key was sent to the default profile's proxy or host. Targets / display (F11): WEIXIN_HOME_CHANNEL (message posted into the default's chat), HERMES_LANGUAGE, and agent/i18n's process-wide lru_cache of display.language — now keyed by HERMES_HOME. Outbound webhooks: hooks.outbound[].secret_env resolved from os.environ while the gateway registers each profile's targets inside that profile's scope, so a secondary's deliveries were signed with the default's secret or left unsigned. Agent-cache eviction: _spawn_release_thread started a bare threading.Thread, so commit_memory_session -> provider on_session_end ran with an EMPTY context. The thread now runs copy_context() and, for the unscoped housekeeping sweep, enters the owning profile's _profile_runtime_scope resolved from the session key (agent:<profile>:...). The pressure batch does the same per key. session_search (#82903): agent/inline_tool_executors.py::_session_search forwarded every schema argument except `profile`, so a gateway agent could never select a named profile's store. Forwarded; the ownership-scoping design in #87779/#87847 is a separate design call and is not attempted here. Live repro (/tmp/mux_audit/fix-tool-memory-reads/repro.py): 28 FAIL on origin/main -> 0 FAIL with this change; 10 new invariant tests red on base. Fixes #82903 Fixes #65941 Fixes #99121 Addresses #87779 Co-authored-by: webtecnica <75556242+webtecnica@users.noreply.github.com> Co-authored-by: Michael Versluis (Berry) <michael@wve.nl>	2026-09-11 15:26:46 -07:00
Teknium	6806a38084	fix(goals): GoalManager borrows the registry's shared state.db handle ... hermes_cli/goals.py cached a bare SessionDB() per HERMES_HOME. The path was right per profile, but it was a SECOND writer connection beside the gateway's registry handle for the same file — its own token-writer thread and close-time checkpoint the registry knows nothing about (the #90837 corruption shape), doubled per profile under multiplexing. This is the same topology #100682 removed from the API server. Acquire through hermes_state_registry and drop lost-race references with release_or_close.	2026-09-11 15:26:09 -07:00
Teknium	939e45c91d	chore: release v0.21.2 (2026.9.11)	2026-09-11 12:20:08 -07:00
Teknium	0dcadf6f41	revert: remove Collective Wisdom V1 (#94266) ... Reverts the in-tree org skill-marketplace: hermes_wisdom package, three model tools, CLI/gateway/desktop/dashboard/Telegram/Slack surfaces. Later non-Wisdom work on shared files (guest onboarding i18n, dashboard startup schema, Slack adapter, tui_gateway) is kept; Wisdom-only call sites and config were stripped from those files.	2026-09-11 11:54:49 -07:00
emozilla	5764ae3168	fix(local-models): keep automatic recommendations GPU-resident ... Stop recommending a system-RAM spill when no curated model fits resident. Preserve explicit model selection and the existing resident quality/speed ranking, including the separate unified-memory policy. Require a recommendation for automatic quickstart, expose Browse when none exists, and rename Configure to Let me choose. Keep policy copy and reason keys consistent across the four translated local-model sections. Cover automatic refusal and explicit spilled setup against one budget, plus the Browse, Download and Use interactions in the desktop pane.	2026-09-11 12:43:21 -04:00
Teknium	fdd32f81d4	fix(web): report a corrupt state.db as a throttled 503 status instead of a traceback per poll ... The dashboard polls /api/analytics/usage and /api/analytics/models every few seconds. When state.db is malformed the read raised straight through the handler, so uvicorn logged a full traceback at ERROR on every poll — one fleet host wrote ~520K identical journal entries in 24 h. Wrap both analytics handlers in `corrupt_store_as_status`: a corrupt-image sqlite3.DatabaseError (is_malformed_db_error) becomes a 503 with an explicit `state_db_corrupt` payload pointing at `hermes doctor`, and the warning is gated per store path via `{path: monotonic}` (>=300 s), then debug. Busy/locked and every other error propagate unchanged, and the file is never renamed or quarantined from the dashboard — repair stays with `hermes doctor` / `hermes sessions repair`. `_session_db_path_for_profile` is split out of `_open_session_db_for_profile` so the router can name the store without opening it. Refs #96591 Reported-by: #96591	2026-09-11 06:37:27 -07:00
jango	5a2f512390	fix(cli): exit non-zero from sessions repair --check-only on an unhealthy store ... `hermes sessions repair --check-only` printed the corruption reason and exited 0, so scripts and the console wrapper gating on the status read a broken state.db as healthy. Return 1 from the CLI handler (main.py already sys.exits a truthy return) and from the console handler, where `_capture_output` turns the status into a ConsoleCommandError carrying the printed reason. Salvaged from PR #103321 (the check-only reporting part only; the probe rewrite and connection-tracking changes were not taken). Refs #63386.	2026-09-11 06:37:27 -07:00
liuhao1024	3d167a8271	fix(doctor): name structural state.db corruption honestly and route it to sessions recover ... `hermes doctor` reported every write-health-probe failure as "state.db FTS write corruption" and `--fix` ran the FTS repair ladder — rebuild, REINDEX, sqlite_master surgery + VACUUM — on the damaged file. When the damage is structural (canonical tables/indexes), none of those rungs can fix it, each one writes to the torn file in place, and the operator is then told to "restore from the backup copy beside state.db": a `.malformed-backup` that is a snapshot of the same corrupt image. `hermes sessions recover`, the tool that actually rebuilds canonical rows into a fresh file, was never mentioned (#88587; the 1.7 GB field incident lost days to it). Discriminate before mutating. hermes_state_repair.integrity_damage_is_structural maps `PRAGMA integrity_check` output onto the file: a `Tree N` id resolved through sqlite_master.rootpage, an index named in `row N missing from index X`, or a `Freelist:` line is structural unless the object is a Hermes-owned messages_fts* table/shadow (full-matched, so a user lookalike such as archive_fts_data is never swept into the rebuildable set). state_db_has_structural_damage runs it read-only on a fresh connection; an integrity_check that RAISES under the walk (torn root page) is structural too — no FTS-only fixture does that while sessions/messages read cleanly. doctor's state check consults it first: structural damage becomes a manual issue naming `hermes [-p <profile>] sessions recover --source <this db> --inspect-only` (profile pinned, #105887) and explicitly warning off the .malformed-backup; nothing is mutated and no backup is written. FTS-only damage keeps the existing in-place repair path. Verified against real fixtures: a torn `sessions` root page (before: "FTS write corruption", --fix wrote a 1:1 malformed-backup and failed; after: structural, recover guidance, no writes) and the 16-byte DEADBEEF messages_fts_data stomp (still repaired in place via rebuild_fts). Salvaged from PR #88604 (liuhao1024) onto the split doctor_state.py; the classifier lives beside the repair ladder in hermes_state_repair so the ladder itself can consult it next. Fixes #88587	2026-09-11 06:37:27 -07:00
TaoMasterCoder	10777823fe	fix(sessions): salvage a page-1-header-damaged state.db in the lost_and_found lane ... A SIGKILL mid-write (OOM killer, #106667) can leave state.db with a garbage page-1 header. SQLite refuses the file outright ("file is not a database", SQLITE_NOTADB) and the sqlite3 shell's .recover opens the file like any other client, so the lost_and_found lane failed with the same rc=26 twice although every data page after the header survived. The #106587 quarantine now preserves such a file as state.db.notadb-<ts>-<pid>.bak; this makes that preserved file recoverable with `hermes sessions recover --source <bak> --allow-partial`. When both .recover attempts fail with "not a database", zero the 100-byte header of the lane's private snapshot copy and rerun them. .recover trips only on the magic check and infers page size and layout from the pages themselves, so a zeroed header is enough; a spliced donor header (the PR's original mechanism) instead advertises a database size / freelist that contradicts the file and yields "database disk image is malformed" on a direct open — verified live on a 139-page fixture, which also showed the zeroed header recovers 60/60 sessions and 300/300 messages whether the damage covers 100 bytes or the whole first page. The user's file is never written; the report carries `sqlite3_cli.header_zeroed` and a warning about the WAL boundary. Live repro (sqlite3 shell 3.53.1 on PATH, header overwritten with random bytes): BEFORE "page-level .recover salvage failed: ... file is not a database (26)"; AFTER "Recovered 60 sessions and 300 messages", source md5 unchanged. Salvaged from PR #102808 (intent; trimmed from 302 to ~40 source LOC by dropping the donor-header/page-size sweep and the redundant preopen probe — the shell's own refusal is the detector). Independent review on the PR by @strzhao. Refs #106667 Refs #106587 Reported-by: TaoMasterCoder Cross-referenced-by: kshitijk4poor	2026-09-11 06:37:27 -07:00
Teknium	8a9f9eca2e	fix(recovery): seed a damaged rowid edge from min()/max() before the INT64 domain ... When the leftmost (or rightmost) leaf of a table b-tree is damaged, the edge probe `SELECT rowid ... ORDER BY rowid ASC LIMIT 1` walks the table tree and raises, and _salvage_rowid_bounds fell back to INT64_MIN. The gallop from the surviving edge cannot cap that side either (every probe crosses the damaged leaf), so bisection burned the entire 10,000-query budget moving the bound inward by a few thousand rowids out of 9.2e18 and the table was lost — a 4-row gateway_routing table in #98050, sessions + session_model_usage in #100313. `SELECT min(rowid), max(rowid)` is answered by the planner from any covering index (every Hermes table has at least the PRIMARY KEY autoindex) without touching the damaged leaf, which is exactly what the reporter verified by hand. Ask it for the missing edge(s) first; only when it fails too does the domain fallback + gallop run as before. Reported under `aggregate_edges` so recovery.json still shows how the bound was obtained. Live repro (real fixture: leftmost `sessions` leaf cell count overwritten, 400 rows): BEFORE bounds low=-9223372036854775808 copied=0 range_queries=10000 query_limit_reached=True status=failed; AFTER low=1 high=400 copied=391 range_queries=40 status=partial (only the damaged leaf's rows are lost). Refs #98050 Refs #100313 Reported-by: Ace-Kelly Corroborated-by: Proff506	2026-09-11 06:37:27 -07:00
Gunwoo Lee	1dcc0b06e2	fix(recovery): skip rows the destination schema rejects during partial salvage ... `hermes sessions recover --allow-partial` walks damaged tables by rowid range and falls back to an exact-rowid lookup for the last cell of a broken range. A phantom row produced by page damage (a `sessions` row with a NULL `started_at`, an `async_delegations` row with a NULL `state`) reads fine from the source but violates the destination's NOT NULL constraint, and the resulting sqlite3.IntegrityError escaped the exact-lookup boundary and aborted the whole recovery — losing every healthy row behind it. Catch IntegrityError at that boundary, count it under `destination_rejected_rows` and record the rowid as a skipped singleton ("destination constraint rejected row: ...") so the run completes, verifies, and the report shows exactly which rows were dropped. Live repro (real fixture: source schema's NOT NULL relaxed via writable_schema, phantom `sessions` row inserted): BEFORE sqlite3.IntegrityError "NOT NULL constraint failed: sessions.started_at" at session_recovery.py recover_exact_rowid; AFTER status=partial copied=3 destination_rejected_rows=1, verified=True. Reporter @i8ei confirmed the same patch recovers the field database (22 sessions / 2,248 messages) in #102240. Salvaged from PR #91413 (rebased onto the _RowidRangeSalvage refactor; test reduced to one invariant). Refs #102240 Reported-by: i8ei	2026-09-11 06:37:27 -07:00
teknium1	496eb13bd7	fix(state): one corrupt timestamp row no longer kills sessions list, export or insights ... SQLite dynamic typing lets a TEXT cell ('not-a-timestamp'), inf/nan or a garbage double (8.4e252 salvaged from a damaged page) sit in a REAL timestamp column. Every reader called datetime.fromtimestamp()/float arithmetic on the raw cell, so ONE bad row raised TypeError/OverflowError out of the row loop and took down the whole `hermes sessions list`/browse table (#102399), all three exporters — JSONL/MD, QMD, HTML (#102352) — and `hermes insights` (#99959). Fix the class with ONE helper, hermes_cli.timefmt.coerce_epoch(): a stored cell becomes float epoch seconds inside a sane 1970..2103 window or None after a WARNING that names the session id. Every reader routes through it — relative_time (list/browse/resume picker), format_epoch (prune/candidates tables), the three exporters' timestamp formatters, insights' _get_sessions/_day/period range — so a bad row renders as '?'/'N/A'/raw text for that one cell and the command completes. Write side: hermes_state_messages._coerce_timestamp (append_message, append_messages_batch, import) and the import path's started_at now use the same window, so a new out-of-range timestamp falls back to now() instead of being persisted — new bad rows cannot be written by Hermes. Reported-by: #102399, #102352, #99959 reporters; kokhlo's insights analysis pointed at every reporting site, not just line 860.	2026-09-11 06:24:54 -07:00
Sora-bluesky	f1ee8e0f39	fix(cli): release SessionDB handles when deleting a profile ... delete_profile already force-closes holographic memory_store.db in this process, but the shared SessionDB registry kept state.db open. Recreate then failed with a replaced/locked database. Close every shared handle under the doomed directory, same contract as MemoryStore.release_all_under. Co-authored-by: Cursor <cursoragent@cursor.com>	2026-09-11 06:24:11 -07:00
Teknium	c9b71ebaf7	fix(dashboard): startup schema reconcile opens state.db read-only first ... The dashboard's `_eager_reconcile_own_session_db` did an unconditional writable `acquire()` at every startup. When the gateway shares that state.db the dashboard became a second long-lived writable SessionDB owner: a close-time WAL checkpoint plus a possible FTS rebuild in `_init_fts`, the two-writer vector behind the corruption reports in #107688 and #100896 ("5 live SessionDB handles" precursor, gateway + dashboard both holding the WAL). Route the startup reconcile through `_open_session_db_at_path(..., read_only=True)`, which already bootstraps a missing store and heals a stale/malformed schema through exactly ONE writable open before reopening read-only. A healthy store now gets zero writable opens from the dashboard while the #79531/#80037 "bring schema current before the first poll" contract is kept (existing heal test unchanged). Live repro (healthy store, count writable SessionDB.__init__ calls from the startup worker): before=1 after=0. Reported-by: #107688, #100896 (@kokhlo diagnosis) Refs #107688 #100896	2026-09-11 06:21:48 -07:00
Halldrix	b02f3aa00b	fix(doctor): refuse the WAL checkpoint while a live writer holds state.db (#103339) ... doctor --fix ran a raw sqlite3.connect + wal_checkpoint(PASSIVE) with no holder guard. Under a running gateway that second connection joins the live WAL and its close-time handling is the second-writer corruption class #103339 tracks. Route the checkpoint through live_writer_holds_db and skip with an actionable finding when the database is held. [Salvage note: the original PR also flipped the repair probe's DatabaseError branch to fail closed; that hunk is dropped here because it refuses every header-destroyed DB (the exact class repair exists for) — the probe's own connect raises before the EXCLUSIVE/BEGIN statements ever run.]	2026-09-11 06:21:48 -07:00
Siddharth Balyan	0e927c914d	Guided first launch behind HERMES_GUEST_ONBOARDING: intro, guided chat, first task in default (NS-848, PR B1) (#107958) ... * feat(desktop): port guided onboarding substrate Add seeded session creation, transcript directives, profile routing, and the shared window and pane primitives needed by the guided flow. Keep later-step mounts deferred and exclude provider selection and retry machinery. * refactor(desktop): anti-slop cleanup for substrate Assemble seed parameters in the existing create helper and use the owning transcript attribute type. Read the guaranteed gateway and connection contracts directly to remove runtime type probes and unchecked assertions. * test(desktop): create-overrides invariants Verify that reasoning and title overrides do not select a provider or model. Empty overrides and seeds add no parameters. * feat(desktop): port first-run cinematic window Play the cinematic behind the guest onboarding launch flag using bundled Collapse and JetBrains Mono. Give the native window its own controller and restore the app on skip, renderer deadman or native watchdog. Drop the perf scenario because it depends on the removed replay hook. Guided chat kickoff and app-shell gate wiring remain with their later steps. * refactor(desktop): anti-slop cleanup for cinematic Preserve audio and canvas behavior through named types and inferred results. Split the viewport node and frame drawing to keep control flow bounded. Cut comments that only repeat the code. * feat(desktop): add onboarding gate and answers stores Track cinematic, guided chat, handoff and completion in one phase record. Queue the guide after the intro and share pending kickoff work between callers. Keep existing saved answers while dropping retired preferences. Leave intro seen-state ownership with the cinematic store. * feat(desktop): port guided onboarding chat Add guided setup cards, runbooks, machine context, and onboarding presence. Connect transcript rendering and first-build progress to the desktop behind the onboarding flag. Leave session kickoff and handoff execution for the next step. * refactor(desktop): anti-slop cleanup for guided chat Keep directive and layout lookups typed. Remove unsafe test casts and isolate onboarding transcript calculations without changing the flow. * feat(desktop): connect guided onboarding to durable first-build handoff Start the guide only after its profile backend confirms bootstrap readiness. Seed or adopt the welcome chat, then transfer the first build to default with a durable receipt and explicit retry. Wire cinematic completion, screen stand-down, layout growth and progress check-ins. Save agreed preferences before creating the build and release prompt slots after storage refusal. * refactor(desktop): anti-slop cleanup for onboarding handoff Reuse the gateway request and error contracts. Isolate guide adoption and snapshot validation while preserving receipt recovery and reasoning overrides. Validate persisted receipt fields at the JSON boundary without coercion. Keep corrupt identities rejected and retain only the permitted test mocks. * fix(desktop): guided chat review fixes Wire the native machine probe so guided setup can suggest a name and offer the right first task. Restore the comments that explain the flow boundaries. The directive registration uses the launch flag to preserve ordinary chat. Ruling 6 folds active.ts into assembly to keep activity ownership together and removes the second greeting source so the seeded and visible greetings agree. * fix(desktop): handoff review fixes Probe the guide backend before switching profiles so a readiness refusal keeps classic onboarding on the current backend. Restore list-valued personalization coverage and routing rationale. Remove the obsolete setup status fixture. * chore(desktop): onboarding script cull and rehearsal recipe Document a temporary-state rehearsal using the existing onboarding flag and optional portal stand-in. Keep the main scripts unchanged and retain window growth for the guided chat. * fix(connectors): reject incomplete catalog responses * feat(gateway): scope connector controls to the owning session * feat(desktop): connect apps through native session-owned controls * feat(desktop): gate connector cards and enable free-tier access Use the launch flag before mounting connector controls so classic transcripts add no status requests. Allow existing free-tier identities through the read-only tool gateway gate and test the owning-profile RPC path with A’s launch gate. Keep authorization links out of previews. * style(desktop): format connector translations Apply Prettier to the connector copy blocks while preserving upstream translations and free-tier wording. * refactor(desktop): anti-slop cleanup for connector card Use the transcript JSON contract and concrete RPC parameters. Preserve malformed-value filtering at one string boundary and make the fixture and row types explicit. Keep connector execution and cancellation behavior unchanged. * feat(desktop): detect initial language from the OS Use the native machine locale when no supported language is saved. Preserve explicit choices and leave inferred languages out of config. * refactor(desktop): anti-slop cleanup for initial locale detection Keep unvalidated config values at the existing validation boundary. Pass no saved choice after that boundary has ruled it out, preserving locale precedence. * test(desktop): onboarding port test set Make native window tests reject duplicate IPC handlers and isolate disabled onboarding. Assert the active gate mock when onboarding re-enables. Keep the test set limited to behavior carried by the port. * fix(desktop): recover failed guide kickoff and reveal once The review found that a failed guide create stranded the solo shell and draft profile, and solo boot faded an already visible window a second time. Restore the prior route and layout, release onboarding through its existing phase record, and surface create failures. Let the film own the reveal while solo boot animates the visible resize. * fix(desktop): preserve transcript ownership across cards and handoff The review reproduced answers submitted to the focused chat, repeated questions disabled across sessions, handoff recovery using foreground identity, and mount-dependent progress history. Target each card’s own composer, scope settlement to its message and session, carry the issuing guide through handoff, and derive progress from its transcript with streaming activity. Reuse the existing owner ladder for exact and profile-only routes. * fix(gateway): preserve connector ownership with profile routing The review found that shared-primary profile metadata was rejected before connector dispatch, while desktop controls treated a missing registry id as missing ownership. Accept profile only as routing metadata and keep the live transport as authorization. Resolve card ownership through the existing exact/profile ladder, retaining ambient routing only for the single-backend case. * fix(desktop): resolve plugin roots and gate the Basic layout The review found that the first plugin build was seeded with a different installation’s fixed path, and the director ruled that flag-off layouts must match main. Resolve the running desktop’s plugin root before seeding a plugin build and register Basic only when onboarding is enabled. Keep the runbook wording and the ordinary four layout presets intact. * fix(desktop): clear review-fix slop findings The slop gate flagged an undocumented layout-data assertion and unknown-return types in the new test selectors. Record the layout registry invariant and preserve each selector’s return type. The only remaining production finding is the accepted connector-tools baseline. * fix(desktop): detect the OS language on a fresh install The review found that the merged English config default prevented the desktop from probing the OS language on a fresh install. Add an opt-in saved-values read so an absent choice remains distinct from saved English. Preserve default-valued English only for explicit language saves; unrelated settings saves must not turn a merged default into a language choice. Older backends ignore the new query options and keep returning merged English, preserving their existing desktop behavior. * test(desktop): make the flag-off layout registry test deterministic The flag-off test awaited the full controller import, pulling in the UI graph and installing application watchers just to read layout presets. That import took 9.5 seconds locally and timed out in the director's run. Move the existing trees and registration into a small layout-presets module. Production and the synchronous test use the same flag-gated registration, without starting the controller in the test. Keep the real registry invariant and dispose the test's contributions after completion. * fix(desktop): keep the transcript parser and ::ask behind the onboarding flag Register the guided chat's question card only with onboarding enabled. Restore main's whole-paragraph parser and contribution rendering when the flag is off, including its streaming prose behavior. Keep segmentation for the guided flow until B4 decides the parser's wider use. Restore main's two parser test files so its existing product and plugin contracts remain the flag-off check. * test: drop the onboarding and connector tests pending a later ticket Apply the director's ruling to remove B1's added test files and restore main's existing suites. Keep only the gateway route-reader mock contract that main's profile tests need against the shipped activation behavior; their cases and assertions stay intact. The flow's shape is not settled and B3/B4 rewrite it. The connector layer will also be reworked. The live CDP run is the flow check until a follow-up ticket brings tests back. --------- Co-authored-by: brooklyn! <brooklyn.bb.nicholson@gmail.com>	2026-09-11 15:45:43 +05:30
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
Teknium	9ce7547faf	fix(update): bound network git in hermes update and prune shallow grafts on apply ... - _git_run(network=True) now carries a 300s timeout; a dead-stalled fetch (HTTP/2 to GitHub on some networks, black-holed proxy) becomes a failed run whose stderr names the stall instead of an update pinned on 'Fetching updates...' forever (#93759, #95777). Local git stays unbounded. - The apply path prunes stale .git/shallow grafts alongside its existing lock/tmp_pack cleanup, so installs that already accumulated grafts from past depth-1 checks (#105951: 57 entries) heal on their next update, not only on --check.	2026-09-11 02:06:32 -07:00
liuhao1024	5bfa389e8a	fix(cli): prune stale shallow grafts left by depth-1 update checks (#105951) ... Every 'git fetch --depth 1' in 'hermes update --check' (and the past banner passive checks, before #107648 moved them to the GitHub API) appends the fetched tip to .git/shallow as a new graft and git never removes the previous one, so a long-lived shallow installer checkout accumulates one graft per check (57 observed). The stale grafts break merge-base and push 'hermes update' into the orphan-divergence reset path with a rescue ref on every run. prune_stale_shallow_grafts() now runs after each successful depth-1 fetch in 'hermes update --check' and clears the grafts already accumulated by past checks: it keeps only the boundaries still protecting referenced tips (HEAD, FETCH_HEAD, every ref tip) and atomically rewrites .git/shallow, restoring the original file if the trimmed set breaks history walking. The dropped commits are already unreachable; their objects are left for git gc. Rebased onto main after #107648: the banner.py hook is dropped (the passive check no longer git-fetches); the update --check prune and the cleanup of already-accumulated grafts are kept. (cherry picked from commit 6174837fc5b9f4cc3d4d46dc1b2d9a2f6b83c120)	2026-09-11 02:06:32 -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
kshitijk4poor	c2d01f1012	fix(desktop): key the page under the stamp its rows already carry ... A custom HERMES_HOME (outside the profiles tree) reported `profile: null`, so the tail entry landed under profile '' while the session's owner hint — built from list rows that _serving_profile() stamps "default" — looked up 'default'. Two identities for one backend; the exact-key lookup missed and "Show earlier" stayed hidden for the Desktop's own sandboxed and HERMES_HOME-overridden installs (electron/main.ts resolveHermesHome). The messages endpoint now returns the same _serving_profile() stamp the list rows carry, so the Desktop keys a page under the owner it already routes the session by; the inline resolver and its function-body import go away. On the renderer, the ambient profile used for backends that predate the field is captured at request time alongside the connection, so a profile switch mid-read cannot re-key the page.	2026-09-11 13:08:19 +05:30
Robin Fernandes	d45842d206	fix(desktop): preserve older history pagination across scopes	2026-09-11 13:08:19 +05:30
kshitijk4poor	2423385c05	refactor(serve): one place maps "process gone" to orphaned in the watchdog ... The inner ProcessLookupError handler around the marker probe made the outer one reachable only through an injected pid_exists that raises (gateway.status._pid_exists never does). Keep the single mapping; the degrade-to-liveness fixture no longer models a stderr the probe now classifies as a missing process.	2026-09-11 13:03:40 +05:30
kshitijk4poor	e7eed649a6	fix(serve): only "no such process" from ps means the Desktop parent is gone ... The stderr sniff also matched "not found", which BSD ps prints for an unsupported column ("ps: lstart: keyword not found", rc=1, verified on macOS). That would have classified a healthy parent as dead and os._exit'd the backend — the fail-unsafe direction the watchdog must never take. Keep the explicit missing-process message only; the macos_only test now pins the "keyword not found" case as a plain OSError. The standalone ProcessLookupError test (already green on main) folds into the degrade test.	2026-09-11 13:03:40 +05:30
salch-cred	3e72aef744	fix(serve): reserve ProcessLookupError for known missing process signals	2026-09-11 13:03:40 +05:30
salch-cred	2489f15040	fix(serve): ensure parent-death watchdog detects exited Desktop parent (#80204)	2026-09-11 13:03:40 +05:30
emozilla	28388947f8	fix(desktop): preserve local provider identity across new chats ... Report a routable provider in session.info instead of the resolved custom billing class. The desktop carries that identity into new chats without an endpoint, so losing llamacpp could send a local model to a cloud API. Recover managed identity from the ownership-checked endpoint through the existing custom-provider lookup. Bind metadata recovery to the session's profile, preserving named endpoint precedence, pending selections and remote compute metadata. Cover new-chat and resume routing under a cloud default, conflicting profile mappings, and negative endpoint-ownership cases.	2026-09-11 02:49:36 -04: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
kshitijk4poor	64fe13a647	fix(sessions): retire-capture integrity - backups skip capture dirs whole; short reads fail the capture ... - hermes backup excluded *.db-wal by suffix but not the retired-wal capture dirs, so it would ship the capture's main-image copy while dropping the captured -wal that is the artifact's point; exclude <name>.retired-wal-* dirs whole (they must move as manifest+image+wal unit). - _copy_range treated a short read as success, yielding a truncated copy with a valid manifest while the unlinked inode still dies at exit; raise RetiredGenerationCaptureError and clean the .part file. - _quarantine_reason docstring no longer claims close() checks replaced before generation loss (close evaluates loss first and skips quarantine when lost).	2026-09-11 11:14:56 +05:30
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
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
Nick Seelert	89fb1d028e	fix(mcp): retain profile secret scope during discovery ... (cherry picked from commit f344095fcf16c5d154ef2d207cce9b13339bf2e4)	2026-09-10 18:12:39 -07:00
Teknium	2b4deeb32b	fix(auth): key sibling per-process credential memos by profile home under multiplex ... Same class as the resolve_nous_access_token memo: three more process-wide memos carried a credential resolved under one profile's HERMES_HOME override into another profile's turn for their TTL. - hermes_cli/nous_billing.py::_token_cache (30s (token, base) memo for the charge poll loop) was a single unkeyed slot -> dict keyed by hermes_home_key(); invalidate_cached_token() clears the dict. - agent/moa_loop.py::_runtime_cache carried api_key/base_url/api_mode keyed only (provider, model) for 5 min -> (hermes_home_key(), provider, model). - agent/auxiliary_client.py::_client_cache_key had no profile component, so callers that omit api_key (pool / Nous auth.json paths) could be handed a client built with another profile's bearer -> hermes_home_key() leads the key. WHY hermes_home_key(): it reads the per-turn HERMES_HOME override the multiplex gateway sets (falling back to the env var), and it is symlink-stable, so the memo key is exactly the credential home the resolution itself read from. Profiles stay independent islands; the default-profile process env never leaks into a secondary's turn. Tests: one invariant per site, proven red on origin/main.	2026-09-10 18:11:25 -07:00
pierrenode	173105ce6f	fix(auth): scope the resolve_nous_access_token memo to the active profile ... resolve_nous_access_token()'s 5s startup-burst memo (#76930) cached the resolved Nous Portal access token in a single module-level slot keyed by nothing but wall-clock time. The underlying resolution is profile-scoped: _auth_file_path() reads get_hermes_home(), which checks the context-local _HERMES_HOME_OVERRIDE ContextVar before falling back to the HERMES_HOME env var — gateway/run.py and tui_gateway/server.py set that override per-profile for multiplex concurrency. In a multiplex gateway serving two profiles with different authenticated Nous accounts, if profile A's context resolves a token and profile B's context calls resolve_nous_access_token() within the next 5 seconds, profile B received profile A's cached token — used to authenticate against the managed tool gateway / relay self-provisioning under the wrong account. Key the memo by str(get_hermes_home()) instead of a single slot, so each profile's context reads only its own cached token. The lock around read/write is unchanged; only the cache's shape moved from a single (timestamp, token) tuple to a dict keyed by resolved home. (cherry picked from commit 9d8846b88cfd2ea74c6958d5f8f28a50880dda75)	2026-09-10 18:11:25 -07:00
Teknium	942973ae90	fix: every Bedrock client rebuild lands on the startup wire (Claude SDK, Converse region, guardrails) ... Follow-up to 564aef2946 (Mantle SigV4 on /model). The same class of bug covered the other two Bedrock wires and two more rebuild paths: - Claude on Bedrock (anthropic_messages): startup builds an AnthropicBedrock SDK client (SigV4 via boto3). /model, fallback-to-Bedrock and fallback restore built a plain Anthropic client with api_key="aws-sdk" against bedrock-runtime → 401/403. - Converse models (bedrock_converse: Nova, DeepSeek, Llama): only agent_init set _bedrock_region / _bedrock_guardrail_config. After a rebuild the transport fell back to us-east-1 and guardrail_config=None, so eu-/ap- users hit the wrong region and configured Guardrails silently dropped. switch_model also built a pointless OpenAI client against bedrock-runtime. Introduce bedrock_adapter.bind_bedrock_runtime(agent, base_url, api_mode) as the one place that puts an agent on a non-Mantle Bedrock wire, and call it from agent_init (replacing the two duplicated bodies), _build_switched_client, _rebuild_primary_client and _swap_fallback_clients. try_recover_primary_transport had a hand-copied version of _rebuild_primary_client's ladder (and would have hit the same gap); it now calls the shared helper. The region/guardrail parsing that lived in agent_init and runtime_provider_backends is now bedrock_region_from_runtime_url / bedrock_guardrail_config in the adapter. Live probe on origin/main across switch_model, restore_primary_runtime and _swap_fallback_clients for both wires: 0/6 correct before, 6/6 after.	2026-09-10 18:08:16 -07: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