63 Commits

Author	SHA1	Message	Date
Siddharth Balyan	afc3b7c6f3	feat(connectors): one backend-owned connection operation, with a setup card on Desktop, TUI and CLI (#111008) ... * feat(connectors): the desktop connects apps through one backend-owned operation Re-based onto main after #109517, #110368, #110574 and #110843 landed as squash merges (e0ef0eb9c3, d105376b21, ee2f5629b8, 1ab32b212b): the branch's history no longer shared a base with main, so this is the PR's exact delta against +3762/-1470, identical to the branch tip 05d7f2d3d5. The fifteen commits it carried, in order: --- feat(connectors): the wire follows the connector contract (six-state status, required toolkit metadata, connectionId on mint) Hermes types exactly what the contract page writes: /tmp/magic/CONTRACT-TOOLKIT-METADATA.resolved.md (carriers: portal PR2 `sid/connection-api` for the enum and account rows, the portal contract branch on top of it for the list metadata). No optional-for-compat fields, no fallback branch, no seven-state word left in the tree. A gateway that does not speak this contract fails validation loudly. Wire (tools/connectors/gateway/wire.py): `ConnectionStatus` is the six values, `pending` covering the vendor's INITIALIZING and INITIATED; `ConnectorListItem` requires title, description, https iconUrl and authKind, and carries activeConnectionId when the session binds an account; `ConnectorListResponse` types a page whole with its total; `ConnectorAccount` and `ConnectorAccountsResponse` type the account routes; a mint result names its connectionId on `initiated` and never on `failed`; CONNECTION_REQUIRED carries connectUrl and connectionId together or not at all; `account` exists on the execute call and is never sent while multi-account is off. Client: `list_connectors(search, connected)` refuses a search under three characters before any request and parses every page whole; `list_accounts` and `account_status` read the account routes, 404 `connection_not_found` is None and 429 raises `RateLimited(retry_after)`. Watcher: the target keeps the account id the mint named and the toolkit's title and icon from one list read before the card is emitted; `_status_for` is the one seam between the watcher and the gateway's status source (the list walk today; the per-account route replaces that body only). `pending` and a missing status move nothing; revoked and inactive are failed. Desktop: `ConnectorRow` is the strict list item; `ConnectorRowSeed` is what a tool call's args can say; `connection.request`/`update` targets carry `connection_id`, `title`, `icon_url`; the mark ladder is glyph, vendor icon as a plain image, favicon, monogram. Tests run red first: wire rejects the retired words and the missing metadata; client search minimum, execute omits account, account_status 404/429; managed targets carry the metadata and the account id, a pending row moves nothing; the logo ladder order; the store passes the fields through. --- feat(connectors): onboarding connect-first rides the connection operation The guided first build had its own connector surface: a 2 s connectors.list poll loop, an auto-open of every minted link, a hidden "[setup] links opened" note that painted as a user bubble, CONNECT FIRST rows in the transcript, and a "Start with N apps connected" composer pill that sent the go signal early. Delete all of it. The build session's first manage_connections connect now shows the same card as any chat, and the settled tool result is the go signal. Deleted: store/first-build-connectors.ts, assistant-ui/first-build-connectors.tsx (nothing rendered it any more), lib/first-build-start.ts, onboarding-chat/start.tsx, the first-build session markers in handoff-receipt.ts, the connectionRows / latestConnectorPart helpers they were the last readers of, and the five strings only they used. The runbook (setup-profile.ts::connectFirstRunbook) now describes the operation's real contract: one connect call with every picked slug, one card with a row per app, blocks until settled, a per-app result of connected / skipped / not_connected. No wait, no "Start with", no "already active" branch (the result never carried it), and no offer to re-mint: Try again and Continue live on the card, and a Continue means the user moved on. Tests (red first): the runbook names one connect call and its per-app result and never the retired model actions; the no-account rule survives an empty pick. --- feat(connectors): the registry is keyed by profile, every watch read is bounded by the deadline, connectionId is optional, connect and execute carry returnTo and op Registry (P1-14): tools/connectors/live.py keys an operation by (profile home, session key). Two multiplexed profiles can carry the same timestamp-based session key; the tool thread opens under its turn's profile override and the RPC side names the session record's profile home, the default profile resolving to the process home on both sides. Watch reads (P1-8 residual): list_connectors takes a per-page timeout and the watcher bounds each read by the operation's remaining deadline (floor one second), so a stalled gateway page cannot hold the operation past its deadline. Contract follow-up from the portal handoff (/tmp/magic/HANDOFF-HERMES-PR3-PORTAL-CONTRACT.md): connectionId on a mint result and on CONNECTION_REQUIRED is plain Optional (a no-auth toolkit answers active with none; a failed mint answers with neither link nor id); a target without one has nothing to watch. Connect and execute requests carry returnTo (hermes-desktop | hermes-desktop-dev | portal) and op, so the vendor's done page can send the browser back to the app; the call sites and the deep-link handler follow in the next commit. Tests, red first: two profiles share a session key without seeing each other; each watch read shrinks with the deadline; the client honours a per-page timeout; the optional id; the two request fields. The fakes' list_connectors accept the timeout keyword; two wrapper spies that did not were the cause of a 300 s hang under the per-file harness. --- feat(connectors): an MCP target runs on the shared connection operation manage_connections ran MCP targets as a renderer errand: the desktop card ran the catalog lookup, the install and the OAuth flow, then told the backend what had happened, and every surface without a card got `unavailable` plus two terminal commands. That left the outcome in the renderer's word, and left the model unable to connect an MCP server anywhere but the desktop. The backend now owns the work, the way it already owns a managed connector. `prepare` starts the OAuth flow in process and points the browser at the backend's own callback route; an install that still needs credentials waits pending and publishes their names as `required_env`; `observe` reads the flow or the install worker on every tick. The worker itself moved out of tui_gateway/mcp_oauth_sessions.py into tools/connectors/mcp_oauth.py, and that module now calls it, so the Capabilities tab keeps its RPC session table. The card may only say approved, skipped or continue: a claim of any other state moves nothing. With that, `renderer_flow` and the `unavailable` state have no producer left and are gone from the contract. Off the desktop there is no card, so the action runs at once and the result carries the authorization URL for the user to open. Try again reaches the same work: `_reissue` dispatches on `target.kind`, so an MCP row re-runs its own install, enable or OAuth instead of minting a managed gateway link. (cherry picked from commit fa0438c4121807604e7c983ba42b901314a1305b) --- feat(connectors): the MCP card projects the operation instead of running the flow The MCP setup card used to own the work: it called the catalog, ran installMcpCatalogEntry, polled the action, drove the OAuth window, and then told the backend what had happened through connection.respond. That made the renderer a second authority on target state, so an install that finished after the window closed, or a card that never mounted, left the operation with a state nobody could correct. PR3 moves that work to the backend, so the card has one job left: show the operation and send the user's consent. McpSetupPending now renders request.targets the way ConnectorOffer renders them: one row per target, one verb by (action, state), Continue below the shell. Install and Enable send {status: 'approved'} and nothing else; an authorize row opens the link the backend minted, with no OAuth RPC of its own; a running install holds its verb with the busy mark; a failed row sends connectors.connect {reconnect: true} on the open operation, the same call the managed card makes. The owner lookup and that call are now shared helpers on connector-tool.tsx rather than a second copy here. ConnectionTargetOutcome loses connected / initiated / failed: those were the renderer reporting state, which it no longer may do. ConnectionActor loses renderer_flow for the same reason. ConnectionOperationTarget gains required_env, the credentials an MCP install is still waiting for; the card renders a field per entry under the pending row and holds Install until every required one has text, so the values travel with the approval instead of through a separate catalog call. (cherry picked from commit 2e42ad19f63e41f274a87199d07eb99a7c995cbe) --- fix(connectors): the toolkit metadata leaves the wire; the vendor logo is derived from the slug Sid cancelled portal PR3 (the toolkit metadata on the list item) on 2026-09-14, so the fields the contract commit typed as required come off the wire: no title, description, iconUrl, authKind or activeConnectionId on the list item, no total on the page, no search or connected query, no title or icon_url on a target snapshot. The list item is exactly what portal #1220 emits. The desktop derives the vendor logo from the toolkit slug instead (`connectorIconUrl`, https://logos.composio.dev/api/{slug}; the gateway slug is the vendor slug, checked for every lead-order pick), rendered as a plain image because the host sends no CORS header. The title stays `connectorTitle(slug)`. The mark ladder is unchanged: glyph, derived vendor icon, favicon, monogram. Everything else in the contract stands: six-state status, optional connectionId on mint results and on CONNECTION_REQUIRED, returnTo and op, the account routes. The contract commit's message still names the metadata; this commit is the correction. --- fix(connectors): an MCP target survives the card's Continue, and the model is not sent to an action that refuses it The review of the MCP backend found eight defects; each one is a test first. - The off-desktop note told the model to confirm with action 'status', which refuses MCP names outright. It now says the authorization finishes in the background and the tools arrive on the next turn. - The card's existence is a property of the session. A missing callback no longer routes a desktop session down the off-desktop path, where the model would be handed a live link. - A second failure of a backend attempt was published with actor 'user'. ``refresh`` takes the actor, so the frame says who produced the text. - Continue on the RPC thread can settle the operation between any read of a target's state and the transition that follows it. A settled operation has a frozen result, so the lost move is dropped; an IllegalTransition no longer escapes into the tool result. The same rule covers a worker whose outcome arrives late and a Try again that arrives after Continue. - Try again on an install carried no credentials, so the second install ran with an empty env. The approved map is kept on the runner (never on the target: target fields are serialised to the model) and reused. - An approval that does not cover a required credential no longer reaches the worker, where ``install_entry``'s prompt would block on stdin forever; the row waits for the card's fields instead. - ``enable`` writes ``mcp_servers`` under the scope and lock the dashboard's toggle route uses, so the two read-modify-write paths in one process cannot drop each other's write. - Several authorize targets start their flows together and share one wait; one wait per target kept the card empty for minutes. - The off-desktop operation is in no session's registry, so it now emits no connection.update. Try again is also refused for a target the transition table cannot move back to 'initiated' (an MCP target has no move out of 'expired') and for an operation that settled during the call. The contract test that froze the Actor enum is replaced by two behaviour tests: no actor but the backend watcher can connect an MCP target, and the card's word never moves one. (cherry picked from commit 081c16412b48667758a77a7e7c29eaf2be6a93dd) --- fix(connectors): the watcher reads one account route per target, and every frame carries its seq The watch loop walked the whole toolkit list once per tick to learn whether one target had connected. That read costs a vendor call per page, cannot tell one account from another, and forced `awaiting_new_attempt`: after a forced reconnect the list still reported the OLD account `active`, so the row had to be disbelieved until it read as something else once. The gateway now serves `GET /v1/connectors/accounts/{connectionId}`, so each pending target reads its own account: the id the mint named, one read per target per tick at 1 Hz (the route's bucket is 180/min per principal), each bounded by the operation's remaining deadline. A 429 parks that one target until its Retry-After passes and leaves the others reading. A 404 is "not yet" until the deadline. A target the mint gave no account for has nothing to read, so it is not read. A forced reconnect watches the new account, which is why `awaiting_new_attempt` and its two tests are gone. `mint` and `run_remote` now name where the browser should come back to (`returnTo`, plus the operation id on a mint), so the vendor's done page can hand the user back to the desktop app that asked instead of stranding them on a web page. Only the desktop registers that URL scheme, so no other surface sends either field. `connection.update` frames were built by re-reading the operation after the lock was released, so a second writer could give an older frame a newer state and the renderer could not tell which frame was last. Every write now advances a monotonic `seq` and takes its snapshot under the same lock, and the emitter sends that snapshot; a renderer that keeps the highest seq per operation can drop a frame that arrives out of order. `connectors.operation.wake` lets the desktop's deep-link return ask for a read now instead of at the next tick; it only shortens the wait and trusts nothing else in the link. (cherry picked from commit f5423cf72302b92b26c043495184ad6426fa2b36) --- fix(connectors): the desktop card follows the operation, and says so out loud The MCP card was a second implementation of the connector card with the review's defects: it painted for any request on the session, kept its controls after the operation settled, offered an approve verb while the backend was still minting an authorize link, and re-enabled Install when the RPC returned rather than when the state frame moved the row. A second click in that window sent the consent twice. The renderer now reads the operation's `seq`: an update or a status frame whose sequence is not greater than the one already applied changes nothing, and a resume snapshot neither revives a settled card nor puts back a row a newer frame has moved. Without it the transport's ordering decided what the user saw. `hermes://connections/done?op=…` brings the user back from the browser to the session that opened the operation and wakes its watcher, so the row moves at once instead of at the watcher's next tick. Only the op id is used; the link's status moves no row. Each row's mark and cue are one polite live region, so a row that flips is heard and not only seen, focus follows the row the backend moved while the card holds it, and the waiting mark stops spinning under reduced motion. (cherry picked from commit 7c30d252556d7d496ddb354b50bcecc41bceef27) --- fix(connectors): the renderer types seq as the wire carries it The watcher commit made `seq` a required field on every operation frame. The desktop store still declared its own optional `seq` so it would compile against a backend that predates the field; that backend no longer exists on this branch, so the hedge is dead code and the fixtures were short one field. The store now reads `seq` from the shared types, and the fixtures count the way the backend does. The repeat-frame test asserted the whole request keeps its reference. With a real rising `seq` the request must change; the invariant the test guards is that the target row keeps its identity so open credential inputs do not remount. --- fix(connectors): a URL that arrives after the shared wait still lands on its row The shared prepare wait failed every row still pending when it ran out, while that row's own thread was still waiting on the provider. When the URL arrived a moment later the thread's move raised inside the daemon thread, the link was lost, and Try again started a second flow. The wait now bounds only how long prepare blocks; a row still pending afterwards is left to its own thread, which is the only writer of that row and ends with the URL or the flow's own failure. The comment on the approved credentials said every target field is serialised to the model; it is not (the snapshot names its keys). The reason they live on the runner is that they are secrets and the runner's life is exactly the operation's. --- fix(connectors): the review findings the operation must survive before the fold The MCP prepare threads and the install worker started with an empty context, so a named-profile turn's home override never reached them: the flow resolved the process home's `mcp_servers` and stored the token there. Each thread now runs in a copy of the calling thread's context. `connection.respond` had the same gap on the RPC thread: an approval ran the enable, which writes config.yaml, with no profile bound, so the flag landed in the launch home. The handler binds the session record's profile the way `_connector_rpc` does; `config_write_scope(None)` keeps that override, so the enable needs no change. The watcher raised out of the tool when a per-target Skip landed while that target's read was in flight: the operation stayed open with `live` closed, and every later answer got 4004. A read for a row that is no longer live is dropped at debug; only a refusal on a live row is still a contract violation. The same skip from the card raced a row the backend had just connected and aborted the rest of the answer; a skip for a resolved row is ignored and every entry, then the settle check, still runs. A read was bounded by the whole remaining deadline, so a hung gateway held the first read for 300 s and Continue could not return the tool; a read now waits ten seconds at most. A 429 parked only the target that read, but the budget is the principal's, so the next target's read in the same tick spent it again: every live target waits out the one Retry-After. The MCP surface rule read the platform alone, so a desktop call without the callback (registry dispatch from execute_code) opened an operation nobody rendered and blocked for the deadline; it now uses the managed rule, surface and callback. A write after settlement advanced `seq` while emitting the frozen frame, so the resume snapshot named a seq no frame carried; the counter stops at the settle frame. A mint that reports `initiated` with no account id logs that the watcher cannot read the row. (cherry picked from commit 587b228016bf8ee2b022e7fa58c2d9f6057809e9) --- fix(connectors): the desktop card holds a verb until the backend answers, and never takes the keyboard from a credential field The review of the desktop card found five defects; each one is a test first. - A resume snapshot was refused whenever the cache held a settled operation, whichever operation it was, so a session that opened a second operation after settling the first never got its card back from a resume. And the refused snapshot handed the caller the settled cache as "the request", so the session was flagged as needing input behind a summary with no controls. Only the same operation can refuse the snapshot now, and a refused one is no pending card. - The focus handoff picked the row's first button, which after pending -> initiated is the disabled working verb; the focus call was a no-op and the keyboard landed on the document body. It picks the first control that can take focus, else the row. It also moved focus out of a credential field the user was typing in whenever another row moved; it leaves an editable alone. The "focus Continue once every row resolved" branch was dead (Continue unmounts the moment nothing is unresolved), so it and its ref plumbing are gone. - The done link navigated to a settled operation's session and rejected when the wake RPC did (4004 once the operation left the live registry). A settled request is ignored, and a refused wake is nothing: the wake only shortens the wait, the watcher still ticks. - Install spun forever when the store refused to send the consent (the operation gone or settled under the card): `respondToConnectionRequest` resolves false in that case and the verb was only released in `catch`. - After a partial approval (a required credential missing) the backend answers with a same-state frame whose detail names what is missing; nothing released the verb because it was held until the row's state moved. The row now remembers the seq the click saw and holds the verb only until a frame past it arrives, which is the backend's word on the click whether or not the row moved. (cherry picked from commit 4c534d6e2af979778d9a2423cf97d717edeaa1a9) --- fix(connectors): a skip that loses the race to the watcher is ignored, not raised The skip guard read the row's state and then moved it; the watcher can connect the row between the two, and the refused move aborted the rest of the card's answer. The refusal itself is now the witness: a move refused for a row that is resolved, or on a settled operation, is the same nothing-to-do as a row resolved earlier. Two recording fakes in the managed tests kept their lists on the class; they now start per instance so a lifted fake cannot share reads between tests. --- fix(connectors): a resume that lands behind a newer live frame still reports the pending card The refused-snapshot branch answered "no pending card" for both reasons it can refuse: the operation settled, or a newer frame already moved a row. Only the first is no card. For the second the live card is still open and blocking the turn, so the caller must keep the session flagged as waiting on it. * test(connectors): defer new connection coverage until implementation settles Remove PR-added test cases and their unused helpers while retaining existing tests adapted to the changed connection contract. The three PR-only renderer test files are removed for now. Focused behavioral coverage will be added as the final implementation step before verification. Existing main coverage is not being removed wholesale, and this does not declare the feature merge-ready. * fix(connectors): commit MCP authorization at initialize, save setup values after success The OAuth probe treated one exception as one outcome: any failure after the browser step restored the token snapshot and manager entry, so a server that accepted the token but failed tools/list discarded a completed consent. Now the probe reports whether initialize succeeded (details["initialized"], read from the claimed MCPServerTask). Failure before that point rolls back as before. Failure after it saves the server config, keeps the tokens, and reports tools unavailable through flow.discovery_error; the card can retry discovery without repeating consent. Catalog install wrote the submitted values to .env before install_entry and the probe ran. The values now live in the secret scope for the duration of the install (get_env_value reads through get_secret, so install_entry finds them without a prompt), and .env is written only after the probe returns tools. A failed probe removes the server block and writes nothing. _probe_tool_names returns None on a failed probe instead of an empty list, so failure and a valid empty listing are distinct. Failure text is redacted before it reaches target detail: every value the card submitted for that target is replaced by exact match, then the pattern redactor runs. required_env now carries the manifest's secret and default flags; Target carries the manifest's post_install text as instructions. The wire contract gains secret, default, instructions and discovery_error; generated TS and OpenRPC regenerated. * fix(connectors): one OAuth callback receiver picker for the connection card The card's authorize target built its redirect from the dashboard web server and raised when none was bound in the process, so a standalone hermes --tui session could never authorize an MCP server. The receiver is now chosen in one place (choose_callback_receiver): a pinned pre-registered client keeps the SDK's own listener on the registered port; a client-advertised loopback URI is used as-is and its callback arrives through the mcp.servers.oauth.callback relay; otherwise the backend binds a one-shot loopback listener and feeds it into the flow. The dashboard route stays with the dashboard web page, which cannot bind a port. tui_gateway/mcp_oauth_sessions.py had a second copy of the loopback listener and a _worker that referenced _probe_with_rollback, set_hermes_home_override, reset_hermes_home_override and Path without importing them, so every RPC-started flow raised NameError. Both are deleted; start_flow spawns run_worker directly and uses the same receiver picker. Flow registration is shared (register_flow / finish_flow) so a card-started flow with a client URI is reachable by the relay. Under an SSH session with no client listener the attempt's detail carries the existing paste-the-redirect instructions. Nothing on the card path opens a browser. * feat(desktop): setup-form modal for MCP connection cards The connection card rendered an MCP server's setup fields inline: every field as a password input, no default value, no instructions. A URL such as the n8n MCP server URL was typed blind, and the manifest's setup text never reached the user. Two components carry the form now. SetupFieldList renders the ordered fields the backend declares (a plain field as text prefilled with the manifest default, a secret field masked and empty). SetupFormDialog composes it with a one-line title, the manifest instructions, an inline error for a failed attempt, and Cancel / Connect. The row's Install action opens the dialog when the target has fields; Connect sends {status: approved, env}; Cancel sends {status: skipped}. A failed attempt keeps the dialog open with the draft intact. The draft lives in the dialog component only; nothing reaches the store or the resume snapshot. Once the backend publishes the authorization URL the dialog shows it as text with an Open in browser button. Nothing opens a browser on a state change: the Try again path on both cards used to open the re-minted link at once; it now waits for the row's update frame and the user's click. The store types gain the wire's secret, default, instructions and discoveryError fields and normalise them; a connected target with discoveryError renders as authorized with tools unavailable. * feat(tui): connection card in the Ink TUI The Ink TUI had no client for the connection operation: connection.request, connection.update, connection.respond and the pending_connection resume snapshot were unhandled, so a manage_connections call in a TUI session could only print a link through the model. connectionOperationStore.ts holds the backend snapshot: a request opens only for a new operation id, an update applies only to the live operation with a higher seq, a settled update freezes the id so a late request frame cannot reopen the card. The gateway event handler feeds it; session resume hydrates it from pending_connection. connectionSetupOverlay.tsx renders one callout in the prompt zone: a one-line title, the manifest instructions, every field (plain rows prefilled with the default, secret rows masked), then a Connect / Cancel selector. Connect sends the draft through connection.respond; Cancel skips the active target. When the backend publishes the authorization URL the callout shows it as text under "Press Enter to open in browser"; Enter is the only thing that opens it. A failed attempt unlocks the fields with the draft kept. An accepted secret renders as "Set" and is never echoed. A target authorized without tools shows that state and Continue. The overlay joins the existing input-owner set in overlayStore so typing and other prompts are blocked while it is up. * feat(cli): connection panel in the classic CLI The classic hermes CLI passed no connection_callback, so a manage_connections call could only print an authorization link through the model and could not take a setup value at all. The CLI now renders the connection operation as a prompt_toolkit panel, on the same queue mechanism as the clarify panel: the agent thread's callback opens the panel, blocks until the first decision, then returns so the operation's watch loop runs; every later state reaches the panel through ConnectionOperation.on_change (installed only when no gateway hook is set, restored on close). Panel: one-line title, the manifest instructions, one row per field (plain rows prefilled with the default, secret rows masked in the input buffer and rendered as "Set" once accepted), then Connect / Cancel. Connect sends the draft through apply_answer; Esc skips the active target; Ctrl-C sets the tool-thread interrupt so the operation settles as interrupted. Once the backend publishes the authorization URL the panel shows it with the target detail and "Press Enter to open in browser"; Enter is the only thing that opens it. A failed attempt unlocks the fields with the draft kept; an authorized target without tools offers Retry discovery / Continue. Up/Down move between rows, Left/Right toggle the action, and the panel joins the blocking-overlay guards so chat input, history and voice stay out while it is up. The single-query (headless) mode passes no callback, as it does for clarify. * feat(connectors): register a connected MCP server and report its tools in the result After a successful install or authorization the target carried the probe's tool names and the model was told the tools "become available on your next turn". MCP tool schemas are deferrable by construction, so nothing about them lives in the sent tool array; a server registered in the scoped registry is callable through tool_describe/tool_call in the same turn. The operation now registers the server (register_mcp_servers under the owner's home scope) once authorization is committed, records the registered names on the target, and the settled result carries a tools_listing block in the deferred-catalog format plus a note that the tools are callable now. A registration failure keeps the target connected with tools: [] and a sanitized discovery_error. agent.tools and the system prompt are untouched; the between-turns refresh updates the catalog block as before. The card gate no longer asks for the desktop platform. Every surface that renders the card attaches a connection callback (Desktop, the Ink TUI, the classic CLI); registry dispatch and messaging sessions attach none and keep the link result. Pre-commit rollback in probe_with_rollback used restore(only_if_absent=True), which skips the rollback when a token file exists. On a first-ever authorization the only file is the one this attempt wrote, so a token the resource rejected was kept. Live E2E (controlled provider answering 403 to the issued token) showed the row fail and the token survive; the rollback now restores the snapshot outright, and the same run shows the token file removed. * fix(connectors): install an OAuth catalog entry through the card's own flow The card's install ran install_entry and then a plain probe. For an OAuth entry that probe has no card flow around it: in the desktop backend it failed at once ("non-interactive environment and no cached tokens"), and in the classic CLI it saw a TTY, opened a browser by itself and drew install_entry's curses tool checklist over the panel. Since a probe failure is now an error, the failed install was rolled back with _remove_mcp_server, and authorize refuses a server that is not configured. A clean home had no path to a connected OAuth entry, which is 55 of the 65 catalog entries. Found by the live three-surface run. An install now builds the entry's configuration in memory (card_install_config: no prompts, no probe, no checklist; a prior tool selection or the manifest's curated filter applies). An OAuth entry starts the same flow authorize uses with that configuration and the setup values in the attempt's secret scope, so the row reaches the URL step, and the configuration and the setup values are saved together when initialize accepts the token. Every other entry is probed in memory and saved after the server answers. A failure writes nothing, so a failed reinstall keeps the previous configuration, and the failed row asks for its fields again so the card can reopen the form over the draft it kept. * fix(agent): make a server connected in this turn callable in this turn tool_describe and tool_call resolve names inside the agent's toolset selection, which is fixed when the agent is built. A server that manage_connections had just registered was therefore "not found" for the rest of the turn whose result calls its tools available, and stayed out of the next turn's catalog too. The live Desktop run showed it: the result listed mcp__fx_oauth_fields__echo and the tool_describe that followed answered not_found. The executor now adds the MCP servers the call connected to the selection. Only the selection changes; agent.tools does not, so the sent tool schema bytes stay the same. A selection of None (every toolset) and the no_mcp sentinel are left alone. * fix(cli): reopen the connection form when a required field is still empty When the backend refuses an answer because a required field is missing it keeps the row pending and names the fields. The panel mapped that frame to its waiting phase, which draws the detail line and nothing else, so the user saw "waiting for FX_API_KEY" with no fields and no buttons until the 300 s deadline. The panel now returns to the form on the first missing field, over the draft it kept. * test(connectors): the no-card path is the one with no callback attached The card gate is "a connection callback is attached" since the classic CLI got its own panel. This test still attached one under platform "cli" and expected no card, so it opened a real operation, waited out the 300 s deadline and failed. It now drives the path that has no card: no callback. * fix(connectors): order a cancel against the commit and stop deleting a working grant Found by the live runs on Desktop, the Ink TUI and the classic CLI. A user's skip did not stop the OAuth attempt. With the worker parked in the token request, the row settled "skipped" and the token was written 33 s later. A skip now cancels the attempt, and one lock orders that cancel against the commit: the attempt is either canceled with the earlier tokens restored, or committed and kept. When the commit won, the skipped row says the authorization was kept. An interrupted turn cancels its attempts the same way. Every attempt began by deleting the saved tokens, so retrying discovery for an authorized server demanded consent again, and a cancel in between left no grant at all. The card's flow now connects with the saved tokens first, with no browser step; only when they do not work does it replace them. The RPC session surface keeps the old behavior because its caller waits for an authorization URL. A second Connect from the form a failed row reopened was dropped without a frame, which left the Desktop dialog with Connect loading and Cancel disabled until the deadline. An approval on a failed or expired row is now a retry with the new values. The reported tool names came from the registration call, which returns nothing for a server the process already holds. A retry after a failed listing therefore said "no tools" while the server had them. The names are read from the registry, and a parked server is woken first. An authorization that commits after its card closed by deadline was never registered, so the next turn still could not reach it. The runner keeps such attempts, and the between-turns refresh adopts the ones that were approved. An error with no message reached the user as a class name ("CancelledError"). The tool description still said a server's tools arrive on the next turn. * fix(desktop): let an OAuth install open its link, and keep the form's draft An install of an OAuth catalog entry with no setup fields reached the URL step and gave the user nothing to click: an initiated install was always drawn as a disabled spinner, and the only other place the link is shown is the setup dialog, which opens for entries with fields. That is most of the catalog. An initiated row that carries a link now offers Open, whatever the action. The setup dialog reset its draft whenever the field list changed identity. The backend sends a fresh list with every frame and an empty one while an attempt runs, so a failed Connect erased what the user had typed. Fields now only fill in what the draft lacks, and closing the dialog drops the draft. The settled summary dropped the "tools unavailable" fact, and the live row offered a Try again for that state which the gateway refuses for a connected target. The summary keeps the fact and the row offers no dead control. * fix(tui): keep the typed draft when a Connect fails The overlay reset its draft whenever required_env changed identity, and every backend snapshot delivers a freshly parsed array. A failed Connect therefore came back as a form with the default region and an empty secret. The draft now resets per target only, and a snapshot's fields fill in what the draft lacks. * fix(cli): show the URL step and start an install that has no fields The panel applied the user's answer and then set its phase to "waiting". The backend applies the answer on the same thread and its change hook had already set the next phase, so the URL step of an OAuth install and the reopened form for a missing field were both overwritten, and the card sat on "Waiting…" until the deadline. The waiting phase is now set before the answer is applied. A pending install or enable with no fields opened in the waiting phase, which sends no approval, so the flow never started. It now opens on Connect/Cancel. A target that already carries its link opens on the URL step. Connect on a failed row re-ran the attempt without the values now in the draft; it sends them. The authorized-without-tools phase offered a "Retry discovery" that a connected target cannot run inside the same operation; it offers Continue. * fix(connectors): a newer OAuth attempt replaces the older one for the same server A card that closed by deadline leaves its worker waiting on the browser for up to 300 s, and a tampered callback leaves one waiting too. A retry or a new operation for the same server then ran beside it: both wrote the same token files, and the older one's rollback could write over the newer attempt's grant. The newest attempt per home and server is recorded. Starting one cancels the older attempt, takes over its pre-attempt snapshot so a later failure still restores the state from before either, and the older attempt's rollback leaves the files alone. * fix(desktop): label an install's link control "Open in browser" The control that hands an install's authorization link to the browser reused the action's verb, so the row showed "Install" before the click and "Install" again at the link step, told apart only by the cue. It now reads "Open in browser", the label the setup dialog already uses for the same act. Authorize keeps its verb. * docs(mcp): describe the setup card on the desktop, the terminal UI and the CLI The MCP guide said the chat install exists only in the desktop app and that the CLI relays commands. All three surfaces now show the same card: fields, Connect or Cancel, an authorization link the user opens, one save when the server has accepted the token, and tools the agent can call in the same turn. The tools reference gains the result fields (tools, tools_listing, discovery_error) and the no-card behavior of an OAuth install. * fix(cli): keep the layout hook callable without a connection widget The CLI panel commit added connection_widget to _build_tui_layout_children as a required keyword. That method is the documented override point for wrappers, and five existing tests (extension hooks, prompt stash, subagent dock) call it without the new argument, so CI failed with a TypeError. The argument is now optional, like the other widgets added after the hook was published; a missing widget is left out of the layout. The settled tool result also carried the target's setup instructions. Those are the card's text for the user, and a catalog entry's notes can predate this flow ("restart your session so the tools are loaded"), which contradicts a result that says the tools are callable now. The model-facing result drops them; the card payloads keep them. This restores test_connector_local_batches. * fix(connectors): wait for an in-progress registration before reporting a server's tools Found with the real Vercel MCP server. Saving the configuration wakes the config watcher, which starts its own connect for the new server. The operation's registration call then skips the server as "already connecting" and returns at once, so the card settled "connected" with no tools, and the 214 tools were registered three seconds later. With no names in the result the model searched, found the hosted connector of the same vendor and asked the user to connect that instead. The registered names are now read once the registration has finished: while another task is connecting the server the read waits (30 s at most), a parked server is woken once, and a server that finished registering with no tools is still a valid empty list.	2026-09-21 10:04:32 +05:30
teknium1	265e68d784	fix(auth): one primary_failure_wording() helper labels quota vs auth failure at all three fallback surfaces ... - hermes_cli.auth.primary_failure_wording(exc) -> (log, user) phrase; reused by cli_agent_setup_mixin._resolve_fallback_runtime, runtime_provider's fallback logger and the TUI gateway/Desktop _resolve_runtime_with_fallback (#117482 sibling: 'Primary auth failed' for a 429 on the gateway surface). - Drop the dead credentials_rate_limited kwarg at the post-turn exit site (the flag is only True when _ensure_runtime_credentials returned False). - Fold the new tests: 2 parametrized production-path tests + 1 gateway test.	2026-09-20 16:23:22 -07:00
teknium1	75430ff290	refactor: one fallback notice call, label chosen up front ... Fold the duplicated render_notification branches into a single call and re-point the source-slicing test marker at the flattened block.	2026-09-20 16:23:22 -07:00
686f6c61	89096ba56c	fix(cli): treat credential-resolution 429 as quota, not auth ... A Codex quota wall at startup was labeled "Primary auth failed" and exited 1, so Kanban counted a failure and operators went looking for a bad token. Use is_rate_limited_auth_error() for the fallback notice and EX_TEMPFAIL (75) when HERMES_KANBAN_TASK is set.	2026-09-20 16:23:22 -07:00
teknium1	c30b750ad2	fix(cli): release the old agent's clients before dropping it for a rebuild ... Interactive CLI sites that set self.agent = None (/personality, /reasoning, /fast, model/route/credential change, first-run setup, MoA one-shot) now go through _retire_agent(), which calls agent.release_clients() first: on the codex_app_server route the app-server child belongs to the instance and was orphaned for the CLI process lifetime (#72548).	2026-09-19 09:43:20 -07:00
teknium1	e63da95318	fix(cli): auth.json-only login with a benched credential is explained, not sent to the wizard ... Two gaps from review of #113720's fix: 1. A profile logged in via auth.json (active_provider: nous) with no model.provider in config.yaml resolves as "auto". The ladder's OAuth rung swallowed the AuthError for "auto" and fell through to the keyless OpenRouter fallback, so the startup probe returned (False, None) and the first-run wizard ran anyway. The ladder now catches the AuthError in _ladder_rungs, still falls through for "auto", but stamps the swallowed error on a keyless fallback as `auth_error`; _probe_runtime_credentials returns it so the notice names the real failure. 2. The gate itself lived only in cli.py::_tui_print_startup and was untested at the seam (reverting cli.py left the suite green). It is now one mixin method, _maybe_offer_first_run_setup (tty check → probe → explain → offer), called from _tui_print_startup, and both tests drive that method with stdin.isatty patched True and _offer_first_run_setup asserting it is not called. Tests: the benched-credential test now covers the gate and the cooldown headline wording; the blank-install control is folded into the new auth.json-only test.	2026-09-18 10:24:15 -07:00
teknium1	90a6c48037	fix(cli): cooldown notice leads with the wait and names its cause, not a re-login ... A live cooldown is a wait, not a lost sign-in. The startup notice for a benched credential led with format_auth_error's "Run `hermes model` to re-authenticate" — the destructive suggestion #113720 is about — and the cooldown line hardcoded "after a failed refresh" although STATUS_EXHAUSTED is also written for 429/402. Now, when the pool reports a pending next_available_at, the cooldown line is the headline, the provider error follows as plain text without the re-auth hint, and the cause is derived from the benched row's last_error_code/last_error_reason (rate-limit or quota response / failed token refresh / HTTP <code>). A dead (quarantined) sign-in still gets the `hermes auth add` line.	2026-09-18 10:24:15 -07:00
teknium1	d98b1480b9	fix(cli): a benched or signed-out credential prints its reason instead of the first-run provider wizard ... `_runtime_credentials_ready()` collapsed "nothing is configured" and "the configured credential is unusable right now" into one False, so a profile whose only Nous credential was benched by a failed refresh (or quarantined DEAD) was told "No inference provider is configured yet" and offered the provider picker — re-running setup on an OAuth provider with single-use refresh tokens can rotate the grant away from the session that was working (#113720). The readiness probe now returns the resolver's exception too (`_probe_runtime_credentials`). At CLI startup only the resolver's `no_provider_configured` verdict reaches the wizard; any other failure is explained by `_explain_unusable_credentials`: `format_auth_error(exc)` plus, from the provider's pool, "cooling down ... re-enters rotation in about Nm" or "sign-in was lost (<reason>); run `hermes auth add <provider>`". An actually-empty profile still gets the wizard. Fixes #113720 Supersedes #113732 (@whyyagswhy): its `_inventory_other_providers()` gate returns False for a Nous-configured profile, so the reported Nous case would still have reached the wizard, and it printed no reason. Co-authored-by: Yagna Vudathu <yagnavudathu@gmail.com> Co-authored-by: ahrazzle <ahrazzle@users.noreply.github.com>	2026-09-18 10:24:15 -07:00
teknium1	4a15e049fd	fix(cli): re-resolve reasoning after every startup model move, not just the auth fallback ... _resolve_cli_reasoning's invariant is that every path moving self.model re-resolves reasoning_config before the agent build. The previous commit covered only the auth fallback swap; the custom-entry runtime.model swap, the provider-default fill and the provider normalization in _ensure_runtime_credentials, plus the first-run picker re-sync in _offer_first_run_setup, still left the launch model's effort in place. Hoist a single re-resolve to the end of _ensure_runtime_credentials (guarded on the model actually changing since entry and on no explicit --reasoning), which also covers the fallback path since that is its only caller; add the same guarded call after the first-run picker re-sync, which runs before _ensure_runtime_credentials sees the move.	2026-09-18 09:35:49 -07:00
teknium1	8e1b4216b5	fix(cli): startup auth fallback re-resolves reasoning effort through the CLI chokepoint ... _resolve_fallback_runtime swapped requested_provider/model after the primary's AuthError but left reasoning_config at the launch model's effort, so the first request to an always-thinking fallback model (zai/glm-5.3-flash with a reasoning_overrides entry) went out with the primary's `medium` and 400'd. Kanban workers hit it on every spawn since each is a fresh `hermes chat`. Route the swap through `_resolve_cli_reasoning`, the CLI-level chokepoint that /model, /new and --resume already use (77f5de23dd), instead of an inline try/except-pass copy: it reads the same in-memory CLI_CONFIG startup resolved the primary against, so nothing can fail and the swap is never at risk. Keep the `_explicit_reasoning_config` guard from #113497: an explicit `--reasoning` is the user's intent for this run and outranks the fallback model's config (kanban passes it per task the same way). Test: one real-HermesCLI invariant, parametrized over the two cases (fallback override applies; explicit flag survives), replacing the SimpleNamespace stub test. Docs: fallback-providers.md. Co-authored-by: Konstantin Khlopkov <konstantin.khlopkov93@gmail.com> Co-authored-by: Kevin Rajan <7121943+kvnloo@users.noreply.github.com>	2026-09-18 09:35:49 -07:00
KoNit-K	0781f4458f	fix(cli): re-resolve reasoning config after fallback	2026-09-18 09:35:49 -07:00
kshitijk4poor	66a29c3e9d	docs: correct the free-tier narrative the removal left behind ... The keyless free tier is gone, but five comments and two test docstrings still described its routing rung: the resolve_runtime_provider ladder docstring listed a step that no longer exists, and both target_model call sites plus their regression tests explained themselves in terms of a `*-free` default being routed to the keyless Zen relay. They now state what the code actually does (the model-keyed rungs pick the relay and api_mode). Also drops the two comments that only narrated the removal (_OPENCODE_FREE_EXCLUDED_MODELS' history, and an orphan note in auxiliary_client._resolve_api_key_branch).	2026-09-18 15:40:37 +05:30
Victor Kyriazakos	cd3de040ab	feat(notifications): opt-in suppression of user-channel warning notifications ... Squash of the 54 commits on victor-kyriazakos:feat/user-channel-warning-suppression (PR #112302, head f45c640e55) so the contributor's authorship survives a rebase-merge; the commits interleave with a cron delivery-ledger rework that the salvage removes in follow-up commits, so per-commit cherry-picks were not practical. Adds display.suppress_warning_notifications (global + per-platform, default false): one resolver (gateway/warning_notifications.py), BasePlatformAdapter.emit_warning / emit_media_warning / warning_text, a notification_category classification carried through wakes, queues and persistence, and render/present boundaries for CLI/TUI.	2026-09-18 01:43:35 +05:30
teknium1	931b5ff9e7	fix(opencode): every credential-resolution surface keys off the model it will send; family heal only for built-in providers ... Closes the remaining atoms of #112600. A) The CLI startup path already passes `-m` as target_model (c358a6fba0), but its siblings still resolved credentials against config's `default`: the CLI auth-fallback rung, `--resume` credential re-resolution, the gateway provider-override helper (channel overrides, persisted /model switches, API-server provider refresh), the gateway fallback chain, the TUI /model switch-from runtime and ACP agent construction. With a `*-free` default the OpenCode free-tier rung fired first and a Go-only model was built against the keyless Zen relay ("Model mimo-v2.5 is not supported"). Each now passes the effective model; `_resolve_runtime_agent_kwargs_for_provider` grows an optional `target_model` and the two test stubs of it accept the kwarg. B) normalize_opencode_base_url rewrote the /zen vs /zen/go segment for ANY provider matched by opencode_provider_family, including custom providers merely named after a family (`opencode-go-bridge`, #85589) whose relay the user declared explicitly in `providers:`. The family heal now applies to the built-in canonical providers only; custom prefix-named providers keep their per-model api_mode routing and /v1 handling. Documented in the providers guide. C) Same function: the official-host check uses parsed.hostname (a port no longer defeats the heal) and only the path is edited, so query/fragment round-trip instead of being dropped. Fixes #112600	2026-09-17 08:59:22 -07:00
teknium1	c358a6fba0	fix(cli): resolve runtime credentials for the model the CLI will send ... _ensure_runtime_credentials called resolve_runtime_provider without target_model, so the ladder's model-keyed rungs saw config's `default` instead of the -m model. With a `*-free` default the OpenCode free-tier rung fired first and `hermes -m mimo-v2.5 --provider opencode-go` was routed to the keyless Zen relay, before the family heal in this PR could run. Pass self.model (set in HermesCLI.__init__ before the lazy resolve), matching model_switch and the API server, which already pass target_model. Part of #112600	2026-09-16 16:54:57 -07:00
teknium1	23036e20a6	fix(ux): plain-language, actionable user-facing messages (core) ... Squashed integration of the user-facing message audit for this surface set. Full per-finding receipts: /tmp/ux-audit/lanes/*-receipt.md (campaign artifacts).	2026-09-15 04:12:13 -07:00
teknium1	aa75d3724f	fix(stream-json): verbatim text deltas, closed protocol on init failure, per-call tool keys ... - on_text_delta dropped whitespace-only deltas, so concatenating the `text` events no longer reproduced the answer (a newline between paragraphs was lost). Only None/"" (the turn-end sentinel) is skipped now. - The emitter was attached only after credentials + agent init succeeded, so a missing key or unknown provider exited 1 with an EMPTY stdout and the provider error rendered through ChatConsole (stdout). The emitter is now built before _ensure_runtime_credentials/_init_agent; that path closes the protocol with init + a failed `result` (exit_code 1, error) and the credential error goes to stderr whenever stdout is machine-readable (tool_progress_mode == "off", i.e. -Q and stream-json). - _tool_started was keyed by tool name, so concurrent same-name calls clobbered each other's start time; key on tool_call_id when the caller passes one and surface it on tool_use/tool_result. Live: `hermes chat -q … --format stream-json` with no provider and with a dead custom base_url both yield pure JSONL (`system` + `result`, exit 1).	2026-09-15 03:53:13 -07:00
Carl Taylor	075a256597	fix(skills): auto-load resolves once per agent and dedupes against -s ... The system prompt must stay byte-stable for the life of a conversation: `_auto_load_skills_result` is seeded in `_SESSION_STATE` and filled on the FIRST prompt build only (HERMES_IGNORE_RULES captured then too), so model switches, compression and static-prefix restoration reuse the exact rendered bytes rather than re-reading config or skill files. CLI: auto_load renders in the existing background `--skills` preload thread (real session id for ${HERMES_SESSION_ID}), `-s` names dedupe against the auto-loaded canonical names via `build_preloaded_skills_prompt(excluded_loaded_names=)`, the activated skills line shows auto_load first, and the lazily built agent is seeded with the pre-resolved bytes. `--ignore-rules` skips auto-load with the rest of the auto-injected context. Re-implementation of #74060 by @ctaylor86 against current main.	2026-09-15 03:34:20 -07:00
teknium1	f1d5c99fe5	feat: background-process completions paint a compact title, not the raw notification wall ... Subagent completions already got this: the model receives the full `[ASYNC DELEGATION …]` text while the CLI/TUI/Desktop paint a one-line "Subagent Task Completed: <goal>" event. Background-process completions (`terminal(background=True, notify=True)`) still echoed the entire `[IMPORTANT: Background process proc_… completed normally (exit code 0). Command: … Output: …]` block as if the user had typed it. Generalise the delegation mechanism: `TimelineNotification` (formerly `SubagentNotification`) carries `display_kind` + `display_text`; `ProcessNotificationBatch` renders a `process_complete` one with a `process_completion_display_text` title ("Background Process Finished: <cmd>", "Background Process Failed (exit 1): <cmd>", "N Background Processes Finished"). The TUI gateway stamps the same kind/metadata on the synthesized turn and emits the title on `status.update`; Ink and Desktop project `process_complete` rows as timeline events (Desktop keeps the raw output behind the existing expandable async-result row). Model content is byte-identical to before.	2026-09-13 14:35:32 -07:00
bixycler	70d0f556d7	fix(branding): use the Caduceus ☤ (U+2624), not the Rod of Asclepius ⚕ (U+2625) ... Every inline glyph — CLI banner/status bar/response labels/goodbye, setup and doctor boxes, gateway update prompts, WhatsApp reply prefix, TUI theme, locale strings and the docs — used ⚕, the staff of Asclepius (medicine). Hermes carries the Caduceus ☤. The ASCII-art logo was already correct. Mechanical swap across 60 files (no logic change); both glyphs are East-Asian-width Neutral so no layout shifts. Skins that set their own `response_label` / `goodbye` are unaffected. Direction from PR #7064 (@bixycler), the earliest of #7064 / #9611 / #15574, redone against current main. Fixes #9565	2026-09-12 08:25:54 -07:00
Teknium	876e444e4e	fix(cli): open the session store through the state.db registry, not a bare SessionDB() ... The classic CLI froze for ~0.7-2s between the banner and the first prompt. py-spy + strace on real PTY startups showed the main/REPL threads inside refuse_deleted_wal_generation -> _iter_proc_fd_targets: a second full SessionDB open. _init_session_store built a bare SessionDB(); a moment later the goal/loop/heartbeat managers acquired the same state.db through hermes_state_registry from the REPL thread, which is a different handle, so the whole open ran again — including the /proc-wide deleted-WAL sidecar scan (~4.4k readlinks). Each readlink drops and re-takes the GIL while the startup threads (plugin discovery, MCP, skill sync, banner git) are busy, so an 11ms scan stretched to 1.3s per pass, and the second pass landed exactly where the prompt should have appeared. Route the CLI's handle (init + the two re-open sites) through the registry so every in-process consumer shares one writer. One scan per startup; live A/B on the same box, interleaved x6: banner->prompt gap 0.37s mean -> 0.15s mean (plain), 1.77s -> 0.39s under strace. The registry release path replaces close(), so /quit, /snapshot restore and /handoff keep their semantics.	2026-09-12 05:13:50 -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	a2db110ccc	feat(auth): Nous free tier: free inference and connectors out of the box, one command to sign in (#105258) ... * feat(auth): Nous free tier core: anonymous identity minted on first use, welcome inference, shared-store scoping A fresh install with no provider sets up a free Nous identity (anonymous auth method of the nous provider) instead of forcing the setup wizard. The identity is persisted through the same path a real login uses, so the resolver ladder is unchanged. Two seams differ: token acquisition re-exchanges the anon credential (no refresh token), and routing pins the welcome host's single model nous/welcome. One identity per shared store; nous.guest: false turns the free tier off. * test(auth): free tier core contracts: lifecycle, resolver precedence, exchange seam, model pin * docs(user-guide): free tier and signing in New page explaining what a fresh install gets before any key or sign-in (free inference on nous/welcome plus connectors), how the free tier coexists with a user's own API key, how to sign in with hermes auth upgrade and keep connectors, how to turn the free tier off with nous.guest, what hermes logout does in each state, a troubleshooting table, and a plain privacy note. Wired into the Using Hermes sidebar. * fix(auth): logout leaves the free tier alone and clears the shared store for a real Nous account Logging out of the free tier is a no-op: it is not a login, so nothing is cleared and the user is told they were never signed in. Logging out of a real Nous account now also clears the cross-profile store, so a profile logout is not silently re-adopted on the next boot. * fix(model): switching off the free tier points at signing in, never hops providers * Name the free tier in the gateway startup notice and tell explicit-provider installs about it once * Render the Nous free tier as free tier on auth status, auth list, hermes status and portal info, short-circuit billing copy for it, and skip the keepalive when there is no refresh token * fix(auth): free tier is set up where nothing is configured: resolver last rung and first-run check Both the provider resolver's terminal rung and the CLI first-run check now try to set up the free tier before declaring nothing configured. On a fresh install the first command lands in chat on nous/welcome; a failed setup still falls through to the existing guidance. * Add hermes auth upgrade: sign the free tier into a Nous account while keeping its connectors The device-code flow runs as usual, with a promotion intent registered on the portal between the code request and the token poll so the account that approves the code inherits the free tier's connectors. The promotion status decides the outcome: only a completed one is followed by the token grant, which is persisted over the free-tier singleton and the shared store. Declined, superseded, retired and busy outcomes each print their own plain copy, and a retired identity is cleared so the next use sets up a fresh one. User-facing text never names the free tier's internals. * Show the Nous free tier as one picker row with nous/welcome and hide it when nous.guest is off * fix(auth): upgrade opens the consent page for this sign-in; one mint attempt per process; forced free tier wins the first-run check The browser leg of hermes auth upgrade now prints and opens the promotion claim URL with the claim code, not the generic device page. A failed mint is attempted once per process so several bootstrap sites cannot hit a closed gate or a 429 twice; a retired credential resets that so re-minting still happens. HERMES_FORCE_GUEST is honoured ahead of the first-run provider check. * fix(auth): pin the welcome model on the selected route, not on profile state; background setup retries after a failure A credential-pool entry can select a paid Nous key while the profile singleton is still the free tier. The model pin now keys on the resolved endpoint (welcome host) in agent init and /model, and the pin in model normalization is removed since it had no route to look at. A failed background identity setup releases its latch so a later attempt in the same process can try again. * fix(auth): decide the Nous model together with the route on every credential-pool swap The credential pool can move a Nous agent between the welcome host and the portal host after init. One helper, pin_model_for_route, now runs at init and inside every pool swap, so the welcome host always carries nous/welcome and a paid endpoint always keeps the caller's model. * fix(auth): apply the route model policy on every wire mode during a pool swap; release the setup latch if the thread cannot start * fix(auth): free-tier lifecycle takes profile then shared lock, reconciles with the shared store, persists the mint before exchanging, and clears only the identity that died The shared store is the identity of record for a Hermes root: a profile holding a stale free-tier identity adopts a sibling's newer sign-in instead of keeping the guest, and never overwrites the shared account. Locks are taken in the documented order (profile, then shared). A minted credential is stored as soon as create succeeds, so a rate-limited or timed-out exchange does not lose it and trigger a second mint. Retiring a dead credential removes only that credential from both stores. Guest exchange uses the resolver's canonical portal URL. * fix(auth): a credential rotation never rewrites the conversation model; connectors honour the off switch and replace a retired free-tier credential The welcome host serves one model, so a rotation onto it is refused for any conversation on another model instead of silently switching that conversation to nous/welcome (the model pin applies only when a route is first chosen). The connector token path now treats the free tier as absent when nous.guest is false, including cached tokens, and shares the one dead-credential rule with inference: a retired identity is replaced once rather than returning its stale token. * fix(auth): plain login never imports the free tier as OAuth credentials; the gateway startup line reads persisted state only A free-tier identity in the shared store is not an OAuth credential to offer for import; a real sign-in replaces it. The gateway's startup notice now answers provider precedence from persisted state (no token refresh at boot), so an expired free-tier token cannot stall the online message.	2026-09-11 03:45:31 +05:30
Teknium	b88e6776f4	fix(cli): hold agent status lines until the streamed response box closes ... Subagent completion notices ("✓ [set 7 · 2/2] … (2175.14s)"), background process notices and spinner print_above text are emitted from worker threads through agent._print_fn. In the interactive CLI that was bound straight to _cprint, so a notice landing while a reply streamed was printed between two paragraphs inside the response box. _print_fn is now HermesCLI._agent_status_print: while a response or reasoning box is open the line is parked in _held_status_lines and released right after the box footer; outside a box it prints immediately as before. Gateway, ACP and TUI printers are untouched (they never bound _cprint).	2026-09-09 15:20:13 -07:00
Teknium	fd3565deec	fix: remove dedicated user-facing output cap controls	2026-09-07 06:15:43 -07:00
Teknium	72719c7c1b	fix: show task-first subagent completion notices in CLI and TUI	2026-09-07 01:23:34 -07:00
Teknium	eeb7671e69	simplify(compat): hermes_cli small facades — drop 7 re-exports/aliases (+relay_runtime alias module), repoint 12 callers/tests	2026-09-03 13:05:57 -07:00
Teknium	e83816a4d1	review-fix(comments): restore lost #NNNN rationale comments across non-test source (mechanical sweep, condensed, code unchanged) ... For each issue anchor present in BASE 63279301bc non-test .py and absent on HEAD, the BASE comment/docstring block was re-attached at the HEAD location of the code it explained (matched by the distinctive code line / enclosing def). Sentences already covered by an existing HEAD comment were deduped; the issue number always survives. Insert-only: no code lines changed.	2026-09-03 09:44:26 -07:00
Teknium	3494f7cf23	refactor(hermes_cli): AST-neutral closer hugging across r3-17 slice files	2026-09-02 23:58:31 -07:00
Teknium	c6f75a32ec	refactor(hermes_cli): unify resume state restore, fold trivial locals and module docstrings in g6 files	2026-09-02 22:42:56 -07:00
Teknium	48ef059a6c	refactor(hermes_cli): dedupe decision-message printing, width-probe loop, plugin dedupe via dict	2026-09-02 22:35:44 -07:00
Teknium	da6991f8f5	refactor(hermes_cli): extract recap-entry collection, compact docstrings, squeeze intra-function blanks across g6 files	2026-09-02 22:27:53 -07:00
Teknium	84f1bc5819	refactor(hermes_cli): tuple routing compare, debounce-timer helper, pack signatures across g6 files	2026-09-02 21:56:08 -07:00
Teknium	fa67526f38	refactor(hermes_cli): extract fallback-runtime/compression-chain/recap helpers in cli_agent_setup_mixin	2026-09-02 20:41:02 -07:00
Teknium	150ee2a35d	refactor(cli): simplify CLI mixins (billing, agent-setup, commands) — dedupe helpers, dispatch tables, god-method splits ... hermes_cli/cli_billing_mixin.py (1566 -> 1173): shared _modal_choice / _step_up_remote_spending / _print_org_line / _print_portal_line / _print_total_spendable / _try_usage_model / _billing_patch_auto_top_up; copy tables for charge-failed / charge-error / upgrade-status. hermes_cli/cli_agent_setup_mixin.py (962 -> 787): _current_runtime + _route_signature (3 sites), _compression_descendant (2 sites), resume event/skin tables, _load_resumed_history_late lifted out of _init_agent; fixes latent undefined 'logger' in _resume_history_limit_error. hermes_cli/cli_commands_mixin.py (4175 -> 3634): _end_current_session + _sync_agent_to_session (/resume + /branch), _print_side_result_panel (/bg + /btw), _queue_prompt_turn (/learn /plan /init), _toggle_target + _command_arg (/footer /timestamps /focus /voice /wake), _print_diff_body, _summarize_paths, _split_scope_flags + _scope_outcome (/reasoning /fast); dispatch tables for /cron flags + subcommands, /busy, /fast, /voice; /browser, /cron, /goal god-methods split into helpers. Docstrings/comments compacted by hand; rationale kept.	2026-09-02 13:29:44 -07:00
Teknium	c7e2e0b779	feat(fast): bounded /fast auto|cold windows behind one route-aware gate ... Adds two bounded fast modes on top of the static /fast toggle, default OFF: - `auto`: every user turn opens a `agent.fast_auto_seconds` (default 60s) window; requests inside it carry the provider fast param, later tool-loop requests fall back to standard pricing. - `cold`: the same window, but only on the first turn of a session (no prior user/assistant/tool history). agent/fast_mode.py holds the whole policy: `begin_turn()` at the run_conversation ingress arms `agent._fast_until`; `effective_request_overrides()` is consumed in the ONE place request_overrides feed the transports (build_api_kwargs), so the fast param is a per-request kwarg only. System prompt, tools and messages are untouched — the prompt cache is preserved. resolve_fast_mode_overrides() is now the single gate for static and bounded modes and accepts provider/base_url: OpenRouter, Nous, Copilot, Azure, Bedrock and custom base_urls never receive service_tier/speed (#34308's route gating). Both existing callers (CLI turn route, gateway turn route) and the TUI config.set path pass the route. Surfaces: config `agent.service_tier: auto|cold` + `agent.fast_auto_seconds`, `/fast auto|cold` in CLI, gateway (picker gains both entries), TUI/desktop config.set; status shows the mode; web dashboard select lists the real values. Docs: configuration.md Fast Mode section with mode table + cost note, slash-commands, cli-config.yaml.example, locale strings for the two picker entries. Salvages #89991 (bounded fast modes) and #34308 (route gating). Fixes #64785, #74730. Co-authored-by: Eva <239388517+100yenadmin@users.noreply.github.com> Co-authored-by: kbaicai <kbaicai@qq.com>	2026-09-02 05:33:13 -07:00
Teknium	52f359a011	fix(sessions): Desktop resume of a heavily-compacted chat no longer fails with 4130 ... Desktop's cold resume (defer_history + omit_messages, transcript paged over REST) only ever holds the live tip segment in memory, but session.resume bounded it against the FULL compression lineage (sessions.max_resume_messages, default 20000). A Bot Chat with 85 compaction segments / ~29k lineage rows behind a ~700-row tip was refused at 20001, sent zero model prompts, and sat on "Waking up default…" forever — the healthiest possible session shape, rejected by a guard sized for in-memory materialization. - hermes_state: one `_resume_lineage_ids` definition shared by the resume readers (get_resume_conversations, get_ancestor_display_prefix) and the guard (assert_resume_safe / get_resume_message_count). Guard grows `tip_only=` and names the scope it counted; the branch-aware lineage the readers already used is now what the guard counts too (a /branch copy was being counted against its parent's rows). - tui_gateway session.resume: deferred, omit_messages and lazy resumes are bounded by the tip; only the full in-memory lineage resume keeps the lineage-wide bound. Deferred hydration falls back to tip-only history when the lineage exceeds the limit instead of loading the rows the guard refused. - CLI mid-setup tip-only path routes through the same guard instead of borrowing assert_export_safe. - docs: sessions.max_resume_messages / max_export_messages documented with the per-surface scope. Live repro (real SessionDB fixture, 85 segments / 29,226 lineage rows / 666 tip rows, real tui_gateway.server.handle_request): before — deferred resume -> 4130; after — ok, hydrated history=666 prefix=0; the non-deferred full resume still returns 4130 on the same fixture.	2026-09-01 22:14:33 -07:00
liuhao1024	db2fd5f59a	fix(cli): answer clarify headless in single-query turns ... hermes chat -q wired the interactive prompt_toolkit clarify callback unconditionally, but a -q turn never builds the prompt_toolkit application — the modal can never be painted or answered, so the turn polls its response queue until agent.clarify_timeout expires (default 3600 s, 0 = unlimited). The gateway, cron jobs, the kanban dispatcher and inter-agent wakeups all deliver work as -q turns. Route the single-query case to a headless callback at the agent-construction site that already knows _single_query_mode, mirroring _oneshot_clarify_callback on the -z path (#94943; third member of the family after #86909 and #88013).	2026-08-31 10:09:42 -07:00
AlexFucuson9	f5adeed3dc	fix(cli): guard empty message text in _display_resumed_history ... text.splitlines() returns [] for empty strings. Accessing msg_lines[0] then raises IndexError, making session resume crash when the session contains a message with empty or whitespace-only text (e.g. reasoning-only turns, tool-only assistant messages). Guard with `or [""]` in all three branches (user, assistant_last, regular assistant) so an empty message renders as a blank line. Fixes #59265 Co-authored-by: AlexFucuson9 <AlexFucuson9@users.noreply.github.com>	2026-08-22 03:59:28 +05:30
Teknium	803397ecc3	feat: wall-clock run budget — wrap-up injection at 80% and deadline-scaled stale timeouts (agent.run_budget_seconds / --run-budget)	2026-08-19 16:32:17 -07:00
Teknium	bc5805c35f	fix: compare base-URL hostnames, not substrings, in provider-identity checks ... Port of the bug class from earendil-works/pi#7933 (DeepSeek base-URL detection matched by raw substring, missing case variants and matching lookalike URLs). Hermes had the same class at five sites: - cli_agent_setup_mixin.py: keyless-custom-endpoint detection treated any URL containing the OpenRouter host substring (path segment, lookalike domain) as OpenRouter, and missed case variants of the real host. - models.py validate_requested_model: same substring check for routing an openrouter provider with a custom base_url to the custom catalog. - runtime_provider.py: local-endpoint autodetect matched the string localhost anywhere in the URL, including remote hostnames containing it. - gateway/run.py: /status endpoint display, same local-host substring. - agent_runtime_helpers.py: Nous Portal cache-layout detection matched the nousresearch substring anywhere in the URL. All sites now use the existing base_url_host_matches / base_url_hostname helpers (exact host or subdomain, case-insensitive). Regression tests proven to fail against the old predicates.	2026-08-14 20:47:13 -07:00
kshitij	cdd0a26031	fix: restore session model on resume instead of falling back to config default ... Two bugs caused resumed sessions to use the config default model instead of the model the session was actually using: 1. CLI /model switch didn't persist the new model to the session DB row. The gateway calls update_session_model() after a /model switch, but the CLI path only updated in-memory state and the agent's runtime — it never wrote the new model to the sessions.model column. So the DB row always kept the original model from session creation. 2. Resume didn't restore model/provider from the session DB row. _preload_resumed_session and _init_agent restored CWD and YOLO from session_meta, but never read session_meta['model'] back into self.model/self.provider. So even if the DB had the right model, resume would use whatever was in config.yaml. Fix: - _handle_model_switch / _apply_model_switch_result: call update_session_model() after a session-scoped /model switch (skipped for --once and --global), mirroring the gateway's behavior. - New _restore_session_model() method: restores model/provider from session_meta on resume, with provider/base_url/api_mode from model_config.gateway_runtime. Also swaps the running agent in-place for mid-chat /resume. - Call _restore_session_model() from all three resume paths: _preload_resumed_session, _init_agent, and _handle_resume_command. - Track _explicit_model_override flag so -m/--model on the CLI overrides resume (user intent wins). Cleared on /new.	2026-08-14 02:15:22 +05:30
embwl0x	5a10537b24	fix(sessions): stabilize legacy reset lineage on resume	2026-08-13 23:45:21 +05:30
Teknium	55f9e472a0	perf(cli): sub-400ms warm startup — probe-mode check_fns, lazy MCP SDK, banner snapshot, parallel worktree add ... Cold CLI time-to-banner was ~1.8s (hermes) / ~2.8s (hermes -w). The banner path was paying for work the session doesn't need before first input: - aux availability probes built REAL OpenAI/httpx clients (openai import ~0.3s + SSL context) just to answer check_fns. New aux_probe_mode() returns a cache-excluded stub; resolution policy unchanged. - tools/mcp_tool imported the mcp SDK (~260ms, mcp.types pydantic model construction) at module import even with zero MCP servers configured. SDK import is now lazy behind _ensure_mcp_sdk(); _MCP_AVAILABLE is a find_spec probe so every existing gate/test keeps its semantics. - banner blocked 500ms on the update-check prefetch; now waits 50ms and defers the warning line to a daemon thread (prints above the prompt). - banner recomputed get_tool_definitions + skills scan + git state every launch; now snapshotted to ~/.hermes/cache/banner_snapshot.json keyed on (config.yaml, .env, checkout rev, toolsets) and replayed on warm launches with a background refresh. Agent tool list is still computed fresh. - _resolve_active_context_length probed the Nous portal /models (~200ms network) per launch; the tool-search gate now prefers the on-disk context cache when present. - schema reconciliation re-executed SCHEMA_SQL in a scratch SQLite DB (~85ms) per SessionDB(); the reference parse is now disk-memoized by DDL hash (live-DB diffing still runs every startup). - bundled-skills sync (~120-170ms rglob/hash) moved off the startup path to a daemon thread; plugin discovery starts in the background and every synchronous consumer joins via discover_plugins(). - hermes_cli.auth imported httpx eagerly (~30ms); now a lazy proxy that test monkeypatching still reaches (setattr forwards to the real module). - fast chat launch: unambiguous 'hermes'/'hermes chat' invocations skip building all ~40 subcommand parsers (bails to full dispatch on anything else, incl. container mode). - -w path: git worktree add runs with checkout.workers=8 (0.6s→0.2s) and overlaps HermesCLI construction; --skills preload runs in the background and is folded in at agent init (finalize_preloaded_skills, same fail-loud contract for fully-unknown skill lists); stale-worktree prune moved off the banner path. Warm results (PTY time-to-banner, 5-run): hermes 1.80s → 0.38-0.40s; hermes -w -s hermes-agent-dev --yolo 2.82s → 0.57-0.69s.	2026-08-10 10:40:19 -07:00
kshitij	a8ccd52123	refactor(sessions): accurate scope wording for tip-only resume rejections ... SessionResumeTooLargeError said 'across its lineage' even when the CLI mid-setup path counted only the tip segment; the exception now takes a scope phrase.	2026-08-08 13:36:08 +05:30
kshitij	5b4b9bbf77	fix(sessions): tip-only resume guard on the CLI mid-setup path; fail open on guard errors ... The mid-setup CLI resume path loads only the tip session's rows, so gate it with a tip-only count instead of the full-lineage count (which over-rejected heavily-compressed sessions). Transient guard failures (locked DB, adaptor stores) now log and proceed instead of blocking resume with a new error.	2026-08-08 13:36:08 +05:30
kinsolee	c750d5354a	fix(sessions): prevent oversized transcripts from exhausting memory	2026-08-08 13:36:08 +05:30
kshitij	4eabb595f0	fix(agent): finish the #80622 bug class — sibling predicates, refund ordering, prompt carve-out, honest skip response ... Follow-ups on top of the salvaged #80696 fix (review findings): - Sibling sites: rollback.restore, gateway /retry, CLI /retry and /undo N, and both CLI resume turn counters now use is_user_originated_turn so legacy-persisted standalone handoffs (durable role=user, no display_kind) can never be truncation targets or counted as user turns (#80622 suggested regression 4, dispatcher-wide). - Site-1 guard: hoist the api_call_count decrement + iteration-budget refund above the break so a skipped turn no longer leaks a budget unit and finalize_turn logs the true call count (matches the ollama early-exit and the site-2 sibling). - Site-2 guard: run the handoff guard BEFORE reanchoring so a restored user ask is what the anchor lands on, not a stale pre-restore index. - SUMMARY_PREFIX: add the mid-tool-loop carve-out the code-side guard already implements, so a literal-minded model doesn't halt an in-flight exchange after in-place compaction. - Skip path returns a short compaction status instead of replaying the previous turn's answer (finalize_turn would append it as a fresh assistant row — duplicate prose in transcript and delivery).	2026-08-07 19:44:35 +05:30
Teknium	ef9f6effaf	fix(cli): persist YOLO mode across --resume ... A session's YOLO bypass lived only in the in-memory tools.approval._session_yolo set (or the process-frozen --yolo env var), so resuming a session in a fresh process silently reverted the user's /yolo ON — dangerous commands started prompting again. Persist a yolo_mode flag in the session row's model_config JSON and restore it on every CLI resume path: - SessionDB.set_session_yolo() merges the flag into model_config (same lineage-preserving merge as update_session_runtime_lock); SessionDB.session_yolo_enabled() reads it back, false on any parse failure. - /yolo toggle persists ON and OFF through the new helper; the compression/branch session-id rotation carries the flag onto the continuation row. - --yolo launches record the flag at session creation (agent_init), and a /yolo toggled before the lazily-created row exists is carried into the creation-time model_config (_ensure_db_session). - HermesCLI._restore_session_yolo() re-enables the bypass on startup --resume/-c, the deferred init path, and mid-chat /resume, with a visible '⚡ YOLO mode restored from session' notice. No-op under a frozen process-wide --yolo and never enables on absent/garbage flags.	2026-08-02 20:30:06 -07:00
Teknium	d7522118ef	fix(cli): route keyless first run into provider onboarding instead of a broken chat ... A completely unconfigured install previously booted into a working-looking chat (banner showed model 'unknown'), accepted a message, spun ~30s, then failed with 'Set OPENROUTER_API_KEY' — a provider the user never chose — and never offered setup. - HermesCLI.run() now probes provider readiness at startup (TTY only) and offers the shared provider picker (hermes model flow, which fronts Quick Setup / Nous Portal OAuth) when nothing is configured. Decline is respected; picker state re-syncs into the live CLI so the next turn works without a restart. - New silent probe _runtime_credentials_ready(): no printing, no state mutation; handles keyless local endpoints and callable bearer providers. - The empty-api-key error is provider-aware: names the actual resolved provider and points at 'hermes model' / 'hermes setup' instead of hardcoding OPENROUTER_API_KEY. - Banner: unconfigured installs render 'no model configured — run /model' in red instead of the silent 'unknown' model slug. Consumer-onboarding audit finding #2 (sev 5), Aug 2026.	2026-08-01 15:34:16 -07:00