chore: sync upstream (24098 commits behind) - #6
Merged
Merged
Conversation
…ning prompts The no-reasoning discard branch in _process_batch_worker continued before writing any JSONL row, so run(resume=True) — which filters solely via _scan_completed_prompts_by_content over batch_*.jsonl — never saw discarded prompts and re-ran them at full cost on every resume. Write a tombstone row on discard, exclude tombstones from the trajectories.jsonl merge, and report discarded_no_reasoning in final statistics. Salvaged from NousResearch#93542. Fixes NousResearch#93527
…bstones Complete the NousResearch#93527 fix: the tombstone now carries the human prompt text via _entry_prompt_text (handling flat prompt, ShareGPT, and chat-style shapes), _scan_completed_prompts_by_content counts discarded rows as completed instead of only reading ShareGPT conversations, and the merge step reports excluded tombstones in the combined-count summary. Adds a dedicated regression suite covering the tombstone round-trip, the all-discarded-batch resume path, and merge exclusion. Salvaged from NousResearch#93579 (issue reporter's PR), building on NousResearch#93542. Fixes NousResearch#93527
…started (NousResearch#93406) collect_fleet_versions() swallows every probe exception via logger.debug() and returns whatever accumulated — which can be an empty list. print_fleet_version_matrix([]) returns False (no rows to report), so the update exits 0 with "success" even though no gateway was actually verified. After the restart phase touches live gateways (restarted_services or killed_pids is truthy), an empty fleet snapshot means verification failed, not that everything is healthy. Treat it as incomplete so the receipt records "partial" and the exit code is 1. Fixes NousResearch#93406
…ness signals (NousResearch#93406) The NousResearch#93410 guard keyed on (restarted_services or killed_pids), which never fires on Windows: _pause_windows_gateways_for_update / _resume_windows_gateways_after_update populate neither list, so a healthy resumed Windows gateway still yielded zero fleet rows and exit 0. Hoist the decision into _fleet_probe_expected_runtimes(), keyed on every pre-update liveness signal: - restarted_services / killed_pids (POSIX restart bookkeeping) - _pre_restart_gateway_pids non-empty or None (unreadable pre-state, same fail-closed contract as _restart_phase_failure_is_incomplete, NousResearch#78574) - pre-update plan inventoried >=1 runtime - Windows pause/resume token carries profiles or unmapped entries Gate the 2.0s settle sleep on the same condition so a resumed Windows gateway gets its settle window before the probe. The guard keys only on zero-rows-despite-expected-runtimes; non-empty snapshots (including 'unknown'-state rows) are still judged solely by print_fleet_version_matrix. Regression tests cover: empty snapshot + plan runtimes -> incomplete; empty snapshot + genuinely idle -> success; Windows-resume token path -> fail-closed + settle sleep wiring. Builds on RelaxJonh's NousResearch#93410. Fixes NousResearch#93406
…rable The re-exec'd venv child spawned by _reexec_dependency_sync_off_windows_shim completes every update step — the receipt records success / "completed at command boundary" — but then hangs in interpreter shutdown on a leftover non-daemon thread, freezing the PowerShell window for minutes after "Update complete!". On the hand-off path only (HERMES_UPDATE_REEXEC=1), after the receipt is finalized, the update lock released, and stdio restored, flush and os._exit(code) instead of unwinding — the same treatment NousResearch#79040's cron workaround applies. SystemExit codes (including early refusals) propagate to the hard exit; real exceptions keep the normal raise path so tracebacks still print. Non-hand-off invocations are untouched: the marker env is set solely when the shim spawns the child. Fixes NousResearch#93581
…ry ENOENT Two failures on a Windows desktop install relaying to a remote gateway (NousResearch#93590): 1. waiter_command embeds the reply path in generated python -c source with !r. repr escapes each backslash, but the Windows execution layer folds \\ back to \, so \U in C:\Users\... parses as a unicode escape and SyntaxErrors the whole waiter script. Raw-string literals keep the folded single backslash a literal; POSIX paths have no backslashes so the prefix is a no-op there, and \' inside a raw literal still cannot terminate the string, keeping the NousResearch#93091 injection defense intact. 2. local_delivery_command hardcoded "hermes", relying on PATH — absent in service contexts (systemd units, desktop launchers, non-login SSH shells), so delivery died with ENOENT. It now resolves the CLI next to this gateway's own interpreter (venv bin/Scripts sibling, hermes.exe on Windows) with a bare-name fallback. The NousResearch#93091 per-profile turn-lock recognition in bot_mode_dm now matches the CLI element by basename (split on both separators) so resolved absolute paths still take the lock instead of silently bypassing it. Fixes NousResearch#93590
CI runners have a real hermes sibling next to the venv python, so local_delivery_command now resolves an absolute path there — the exact argv filters in the retry-policy fakes and the relay-methods pins must match by basename instead of the literal "hermes", mirroring the _delivery_lock matcher.
… decoding on delivery subprocess Salvage hardening on top of NousResearch#93601 (with NousResearch#93597 covering the same core mechanisms) for NousResearch#93590: - _hermes_cli(): after the venv-sibling check (hermes.exe on win32), try shutil.which('hermes') before the bare-name fallback, so environments with a PATH but no venv sibling resolve exactly what an interactive shell would. Platform test switched os.name -> sys.platform ('win32') per repo convention. - tui_gateway/methods_bot_relay.py deliver: pin encoding='utf-8', errors='replace' on both subprocess.run sites — without them the child's UTF-8 output is decoded with the locale codec (cp1252/GBK on Windows), mangling non-ASCII replies or raising on undecodable bytes. - Regression tests: shutil.which resolution step, bare-name fallback with which=None, and encoding-pin assertions in the deliver transport test. Refs NousResearch#93590, NousResearch#93597, NousResearch#93601
…Research#93518) pty_ws already fell back to the per-channel active-session file when a /chat WS connects with no ?resume= param, replaying the whole session into the PTY, but the frontend only pinned xterm's viewport to the bottom when resumeParam came from the URL (NousResearch#59591). The implicit path had no way to learn a replay was happening, so the viewport stayed at the top of the scrollback. pty_ws now sends a one-off JSON control frame naming the session id it resolved from the active-session file, before any PTY bytes; PTY output itself always arrives as binary frames, so this is unambiguous on the wire. ChatPage tracks an `effectiveResume` value seeded from resumeParam and updated when this control frame arrives, and the existing follow-scroll/sanitizer/hydration logic keys off it instead of the URL param alone. Fixes NousResearch#93518.
…latch the UI frozen After a liveness-probe-triggered reconnect on a remote gateway, attemptReconnect() awaits desktop.getConnection() and resolveGatewayWsUrl() with no timeout. If either stalls (e.g. main process wedged mid-revalidation even though the backend itself is reachable), the `reconnecting` guard never clears, so every later scheduleReconnect()/attemptReconnect() early-returns forever and the UI stays stuck in "reconnecting" until the app is restarted. Bound both awaits with a 20s timeout so a stall rejects instead of hanging; the existing catch/finally already clears the guard and resumes backoff on rejection. gateway.connect() keeps its own separate connect timeout. Fixes NousResearch#93454
…h#93454) attemptReconnect() awaited desktop.revalidateConnection?.() unbounded, immediately before the two IPC calls the previous commit wrapped in withTimeout(). A wedged revalidation after a liveness-probe trip - the exact trigger NousResearch#93454 and this file's own comment describe - hung that await forever, so the reconnecting guard never cleared and the prior fix never got reached. Wrap it in the same 20s withTimeout() (still swallowing the result via .catch, matching its existing best-effort semantics) and extend the regression test to hang revalidateConnection() specifically, proving getConnection() and the socket still proceed once the stall times out.
…waits too (NousResearch#93454) Follow-up to the reconnect-loop fix: the same unbounded ticket-mint await exists on the soft gateway-switch path and the initial boot() path. Bound both with the same withTimeout/RECONNECT_ATTEMPT_TIMEOUT_MS so a wedged IPC round-trip fails into the existing retry paths instead of hanging the switch or the 'Starting Hermes…' screen forever.
…is deleted botRosterMeta() calls botConnectionRoute() for every sourceScoped/remoteSource row to look up its metadata. That's a passive display lookup, but botConnectionRoute() throws whenever connectionId can't be resolved -- which is exactly what a stale group-chat roster row looks like once its connection is deleted (its persisted descriptor keeps remoteSource: true but loses connectionId). Since botRosterMeta() is called for every member on every group-chat render, opening a group that still references a deleted connection threw on render and crashed the pane's error boundary in a loop that survived app restarts (the poisoned row is in Local Storage). botConnectionRoute()'s fail-closed throw is correct and stays for its actual callers -- routing a real request to a bot (requestForBot, session creation, etc., covered by remote-routing-races.test.mjs). botRosterMeta() now catches that throw and treats the row as having no resolvable route, same as a bot with no meta at all, instead of letting it blow up rendering. Fixes NousResearch#93492
botConnectionRoute() stays the strict, throwing dispatch path for real routing (requestForBot, session creation). botRosterMeta() is passive display code and previously reached that throw through a bare catch, which would have swallowed any unrelated failure the same way. It now calls a new non-throwing resolveBotConnectionRoute() and branches on a typed resolved | owner_removed | not_scoped status instead. Adds witnesses for the split: the typed statuses themselves, that strict dispatch still fails closed on an orphaned row, and that an unrelated failure while resolving meta for a live route still propagates instead of being swallowed.
Root cause of NousResearch#93492: deleting a cloud/remote connection disposed its gateways (store/gateway.ts) but never touched the persisted 'group-chats' storage, so every member descriptor referencing the deleted connection stayed behind as a poisoned row (remoteSource: true, connection gone) that render-path route lookups tripped over forever. Subscribe to the connection registry's 'removed' lifecycle push (window.hermesDesktop.connections.onChanged, feature-detected — older Electron mains don't emit it) and annotate every persisted group-chat member owned by the deleted connection. Rows are marked (sourceMissing/sourceReachable), never silently deleted: the member keeps its identity and panes render the existing degraded 'Gateway removed' botSourceStatus state. Writes ride updateGroupChat so the durable record keeps its full shape, and the listener unbinds on plugin dispose.
…rate Rows poisoned before the removed-connection sweep existed (their connection was deleted while an older Desktop ran, so no lifecycle push ever swept them) are what made NousResearch#93492 survive app restarts. After the persisted 'group-chats' hydrate, run a pure annotate pass over the rooms: - a descriptor that lost its connectionId (route unresolvable — the exact shape that threw on render) is always marked; - a descriptor whose connectionId is absent from the live connection registry is marked only when the registry could actually be read — an unavailable registry must not read as 'everything is orphaned'. Marked rows keep their identity and degrade to the existing 'Gateway removed' state; nothing is deleted.
Audit of the remaining unguarded botConnectionRoute() callers a pane render can reach (NousResearch#93492 follow-up to the botRosterMeta split). Each now uses the non-throwing resolveBotConnectionRoute() and degrades on an owner_removed row instead of throwing into the pane's error boundary: - botWorkspaceOwnerKey / setBotsWorkspaceOwner: sidebar visibility listener, Bots home open, and roster context menus recompute these on passive UI edges; an orphaned selection now yields the name-keyed owner and the blocked workspace target. - durableGroupChatMembers: rebuilt on every group send over the whole seated roster; one orphaned member no longer aborts the room update, and a swept member's degraded mark now survives the rebuild. - useModelOptions: hook body runs during render; the query is disabled for an orphaned row and the picker paints its error/disabled state. - AdvancedProfileConfig: dialog falls back to the bot's own name scope. Strict dispatch callers (requestForBot, session creation, deleteBot, duplicateBot, ensureBotMetadata, routines) intentionally keep the fail-closed throw — remote-routing-races.test.mjs still asserts it. Adds orphaned-connection-members.test.mjs covering the removed-connection sweep, the hydrate annotate (with/without a readable registry), the degraded 'Gateway removed' rendering of swept rows, and every guarded caller.
…pace pane
React.lazy(() => import('./syntax-diff')) only has its pending state
covered by Suspense. When the dynamic import rejects (e.g. a packaged
app whose renderer window resolves to the app.asar copy of dist/ while
the chunk exists only in app.asar.unpacked, NousResearch#93479), the rejection
throws past Suspense to the nearest error boundary, which is the whole
workspace ContribBoundary. One missing highlighter chunk then blanks
the entire chat transcript instead of just the diff falling back to
the plain colored DiffBody, the way markdown-text.tsx already isolates
this failure class for markdown.
Wraps LazySyntaxDiff in a local ErrorBoundary that renders DiffBody on
catch, so a failed highlight chunk degrades in place.
…derer index when packaged The renderer index resolver tried APP_ROOT/dist/index.html — inside app.asar when packaged — before the app.asar.unpacked copy that asarUnpack (dist/**) ships and that resolveWebDist() already prefers for the embedded dashboard. Loading the asar-internal index is how lazily imported chunks (syntax-diff-*, shiki-*, mermaid-embed-*) end up fetched from a path that cannot serve them, killing the workspace pane (NousResearch#93479). Reorder the candidate ladder to prefer the unpacked web dist when packaged, following the unpackedPathFor/resolveWebDist precedent. All window loaders (main, overlay, quick) share resolveRendererIndex, so one reorder covers every surface. Dev behavior is unchanged: outside an asar both candidates collapse to APP_ROOT/dist and keep the original order.
missingRendererAssets only checked the module refs index.html itself names (<script type=module> + modulepreload), so a torn install whose boot-critical files were intact but whose lazy chunks were gone passed the generation check and died minutes later on the first React.lazy() route with 'Failed to fetch dynamically imported module' (NousResearch#93479: syntax-diff-*, shiki-*, mermaid-embed-*). Walk the generation's module graph: for every present JS chunk, parse its inline __vite__mapDeps filename table (the lazy-import manifest Vite bakes into each chunk) and check those files too, transitively and cycle-safe. resolveRendererIndex now skips a lazy-chunk-torn candidate in favor of the intact copy instead of shipping a delayed crash. Tests cover the mapDeps parser (definition table vs index-only call sites, CDN refs), the exact NousResearch#93479 tear shape, transitive/cyclic walks, and the torn-vs-intact preference end to end.
…time Per-session rate limiting only counts consecutive strike windows, so a pattern that recurs at a cadence just above WATCH_MIN_INTERVAL_SECONDS (e.g. a service restarted repeatedly over a day) never trips the existing strike-limit disable — each match lands in its own clean cooldown window. Every one of those matches still forces a full-context agent turn, which stalls the event loop on large sessions (NousResearch#93513). Add WATCH_LIFETIME_MAX_HITS: once a session has delivered this many watch_match notifications over its whole life, disable watch_patterns and fall back to notify_on_complete, reusing the existing disable path.
…ounting, Nth-delivery promotion, docstring Follow-ups on top of the cherry-picked NousResearch#93532 cap: - Regression tests: suppressed (in-cooldown) matches must NOT consume the lifetime budget; the cap trips exactly at the Nth DELIVERED match and promotes to notify_on_complete with the watch_disabled summary queued right after the final match. - Extract _emit_lifetime_watch_disabled() and emit the summary even when the global breaker drops the final match, so the user always learns why watching went quiet (parity with the strike-limit path). - Mention the lifetime cap in the terminal tool docstring (the schema text was already updated by NousResearch#93532). Refs NousResearch#93513
…ntial-pool key A malformed OPENROUTER_API_KEY in ~/.hermes/.env (truncated paste, wrong provider's key) passed has_usable_secret's length/placeholder check and was returned by _resolve_api_key_provider_secret before the credential-pool fallback was ever reached, producing opaque '401 Missing Authentication header' errors even when a valid pool entry existed (NousResearch#93593). - Add KNOWN_PROVIDER_KEY_PREFIXES (openrouter: sk-or-) and skip env values that mismatch a declared prefix, logging a WARNING naming the env var and expected prefix, then continuing to the next env var / pool fallback. - Iterate credential-pool entries (peek first, then entries()) instead of only peek(), so one malformed pool entry doesn't block a valid one. - Providers without a declared prefix are fail-open: unknown key formats are never rejected. Valid env keys still win over the pool (precedence unchanged). Fixes NousResearch#93593
…NousResearch#93469) The pricing snapshot could only express flat per-million rates, so gemini-3.1-pro sessions with prompts over 200k tokens under-counted input 2x ($2 vs $4/M) and output 1.5x ($12 vs $18/M). - Add optional tier fields to PricingEntry: tier_threshold_tokens, input/output/cache_read_cost_per_million_above (None = flat, falls back to base rate per-field). - estimate_usage_cost selects the above-threshold rates for the WHOLE request once usage.prompt_tokens (input + cache read + cache write) exceeds the threshold, matching Google's billing semantics. - Populate gemini-3.1-pro (4.00/18.00/0.40 above 200k; alias gemini-3.1-pro-preview inherits) and gemini-2.5-pro (2.50/15.00 above 200k). - Flat entries are untouched: no threshold means no behavior change. Reported and tier-field shape designed by @tornike14 (NousResearch#93469). Tests: below/at threshold unchanged, above-threshold tiered whole-request pricing, cache-read tier rate and base-rate fallback, preview alias, flat entries unaffected.
…r connection per tick The bot relay's drain loop RPCs every registered connection through requestGatewayForAgent's per-request lease. With no other consumer holding the route, the refcount hit 0 after every tick and the pooled secondary was disposed — a fresh WebSocket dial + teardown per connection every 4s, flooding the gateway logs with connect/disconnect pairs (NousResearch#93594). Two changes, both directions from the issue: - Retained relay-route secondaries: retainGatewayForRelay pins a route's pooled socket with a counted retention (never clobbering the foreground 'retained' flag) for the relay's active lifetime, reusing the existing scheduleReconnect/full-jitter machinery on drops. The plugin pins each registered connection once via the new feature- detected host.retainProfileSocket door, reconciles pins with the current connection set on every drain, and releases everything in stopBotRelay/dispose. Local routes (null/'local') are exempt so the idle reaper can still reclaim spawned local backends. The live-work pruner also respects the pin. - RELAY_DRAIN_INTERVAL_MS 4s -> 30s: the push path (NousResearch#93091, bot_relay.outbox.pending) carries envelope latency, so the poll is purely a backstop — 30s matches LIVE_SESSION_STATUS_BACKSTOP_INTERVAL_MS. Tests: relay-push-drain updated to the new backstop semantics; new gateway-relay-retention.test.ts proves one socket construction across 5 drain ticks (vs 3 constructions for 3 unretained ticks) and that release/prune/local-exemption behave; new relay-socket-retention plugin test pins the pin-once / release-on-departure / stop-releases contracts.
Cron runs finish unwatched by design, so counting them in $unreadSessionCount turned the titlebar badge into a permanently-lit cron run counter (NousResearch#93552). The badge now counts regular + messaging sessions only; cron unread state stays visible on the sidebar cron section rows, and 'Mark all as read' (markAllSessionsRead + ackAllSessionsRead, which iterates cron rows) still clears them. Fixes NousResearch#93552
…ight splits Every opened file registered its preview pane with dock dir 'right', so each open split a new zone off the right edge — three file opens made three ever-narrower columns (NousResearch#93610). The first preview still opens its own zone docked beside main; every subsequent preview now anchors to an existing preview-tile pane with dir 'center', so it stacks as a tab in the same preview zone. Covers files, artifacts, and the Browser tab alike (all flow through openPreview/$previewTabs); session tiles are untouched. Fixes NousResearch#93610
Use Hermes timezone-aware timestamps for retained events and turn messages. Pass the public timestamp field supported by hindsight-client 0.6.1 and cover the final serialized request field.
Adds an optional occurred_at (ISO-8601 date/datetime) parameter to the hindsight_retain tool schema, threaded into the retain item's timestamp field. When absent, the item timestamp defaults to the configured event clock (base from PR NousResearch#82928 by @ragingbulld, authorship preserved) so the Hindsight server can resolve relative time phrases; previously no item timestamp was ever sent and temporal memories landed with null occurred_start/occurred_end. Fixes NousResearch#93568. Salvages NousResearch#82928.
…mming tool_search now takes queries: string[] (searched independently against the same catalog, limit applies per query, default 5 / max 25) and returns the split shape: per-query groups carry tool names only, one shared tools map holds each matched tool's source, description (400-char cap) and required parameter names once. When some queries miss, a single top-level available_sources + hint block replaces the old per-response fallback. tool_describe now takes names: string[] and returns a map keyed by name; unknown names collect in not_found (with the refresh hint) and non-deferrable names keep their per-name spelling-check error in errors, so one bad name no longer fails the whole call. Duplicates dedupe silently. The shared tokenizer now applies Snowball stemming (english, exact-pinned snowballstemmer) at both index and query time, closing the measured plural/singular miss where 'issues' failed to return create_issue. The inline BM25 is unchanged. Stemmer instances are thread-local (they carry mutable parse state and bridge dispatch can run on parallel tool-call threads). New config knobs under tools.tool_search: max_queries / max_describe_names (default 10 each, floor 1, no upper clamp) bound the per-call array inputs; over-cap calls error so the model repairs in one round-trip. No backward compatibility with the single query/name shapes, by decision. scripts/analyze_livetest.py renders both shapes since transcripts on disk may predate this change.
…input The parallel determinism test warms _stem's lru_cache after ~11 distinct stems, so almost no iterations reach the underlying stemmer and a shared (non-thread-local) instance survives it. New test bypasses the cache with per-iteration unique tokens via _stem.__wrapped__, so thousands of stems run concurrently: a shared stemmer's mutable parse state fails it within 2,000 calls (verified — the mutant dies 8/8 runs; healthy runs stay green).
Two interaction seams between the NousResearch#92693 salvage (merged as NousResearch#95050) and this branch: the source-label indexing test now compares in token space (the stemmer shortens 'catalogsource' to 'catalogsourc'), and the unregistered-core-name describe test forces the unregistered condition via monkeypatch instead of depending on which sibling test file imported model_tools first.
Follow-up to the salvaged NousResearch#94296: the two guards covered the repair and confirmed-update branches, but when cua-driver is enabled yet not installed at all, control still reached _run_cua_driver_installer() and an automatic 'hermes update' would launch the interactive install.ps1 anyway. Add the same defer before the installer run, keep POSIX behavior unchanged, and give the confirmed-update message a natural fallback when latest_version is unknown.
First hover still waits 200ms so a sweep does not flash a trail. After a tip has opened, the next trigger within 300ms opens instantly.
…ent chat by default Background processes started by subagents (task_id sa-*) route their notify_on_complete / watch_pattern notifications to the parent conversation (b95ec1c) because anything outliving the child needs a durable consumer. In practice these 'npm ci finished' walls are noise mid-conversation — the child's consolidated delegation result is the deliverable. - New config key delegation.surface_child_process_notifications (default false = suppress). Flag true restores the previous behavior exactly (delivery with subagent attribution line). - drain_notifications drops (never requeues) completion/watch_match/ watch_disabled events whose task_id starts with 'sa-' when the flag is false, logging at debug with session_id+task_id for diagnosis. Requeueing would pin them forever — children never drain notifies. - async_delegation events are NEVER suppressed (they ARE the result). - watch_disabled emitters now carry task_id so sa- sessions' safety events follow the same suppression as their other events. - Config read errors fall back to the default (suppress) and never crash the drain loop. - Docs: delegation.md + configuration.md.
…ndows An updater binary spawns 'hermes update' while holding the update marker with its own PID. A checkout that predates the HERMES_UPDATE_HANDOFF_PID env fix (8c76fe1) and the ancestor-pid fallback runs its pre-pull update_lock.py, reads that marker as a live foreign update, and exits 2 — and the updater deliberately skips its retry for exit 2, so the refusal loops forever: the update being refused is the one that ships the fix, and the failure screen's Retry re-enters the same state. Detect the case with a raw marker read (live_marker_owner deliberately maps self-ownership to None, so it cannot answer this), drop our own claim, and retry the child once with the marker absent. The guard re-removes on Drop (idempotent) and the desktop is already gone at this point, so nothing races the brief marker-free window. Fixes NousResearch#75788 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…nt live_marker_owner semantics Main's live_marker_owner has adopted self-owned markers since 160586f/dbc2a9c8e (NousResearch#74761), so the cherry-picked comment's claim that it 'maps self-ownership to None' is stale. The raw read is still the right tool — the heal needs the single fact 'does the marker name our PID' without age/liveness policy folded in.
… windows-latest Rust lane The heal decision is extracted into should_heal_self_marker_refusal() so the contract is testable: heal ONLY on exit 2 + a marker naming this process. Five tests pin it — self-owned heals, foreign owner (real live sibling process) never heals, missing/garbage marker never heals, non-exit-2 never heals, and the full acquire -> refuse -> drop-claim -> retry-precondition lifecycle with a real UpdateMarkerGuard. windows-rust-e2e.yml mirrors the wine2e pattern: fires only on wine2e-rust/** pushes, runs the crate's cargo test --lib on windows-latest (the shipping platform). The permanent Linux lane stays authoritative for the unix-gated pipe-drain fixtures.
…flows run from the pushed branch and never need to live on main
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Use config.yaml for the Ollama timeout
For CPU-only Ollama users following this guide, this writes a behavioral timeout to ~/.hermes/.env, even though the commit now supports providers.<id>.request_timeout_seconds in config.yaml. The legacy environment override is process-wide rather than profile-aware, and the guide incorrectly says there is no config key; replace this example and the later duplicate with an Ollama provider configuration example, including the translated copy.
AGENTS.md reference: AGENTS.md:L102-L107
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The check-attribution gate scans merge-base(origin/main, HEAD)..HEAD, which for this sync PR covers ~24k upstream commits (June 8 -> Aug 26). 17 upstream author emails had no mapping (upstream maps them via their own fork of this mechanism; our fork's contributors/emails/ had none of them). - 5 auto-resolved via scripts/audit_pr_attribution.py --fix (GitHub email search or verified bare-noreply local part) - 12 resolved manually with gh api users/<login> verification where the auto-resolver could not (including cataclysmstudios@gmail.com -> POWERFULMOVES, the fork owner's commit email, and the NousBot local-agent committer variants) Login disambiguation notes are recorded as comments inside each mapping file. audit_pr_attribution.py now reports: all emails on this branch mapped.
This reverts commit 1e8a69f.
The check-attribution gate hardcoded 'git merge-base origin/main HEAD' as the scan root. That is wrong twice over on this fork, which has two long-lived bases (main for upstream syncs, PMOVES.AI-Edition-Hardened for the submodule pin): 1. Hardened-base PRs scanned the entire upstream delta embedded in hardened (~24k commits at the Aug 2026 sync) and demanded mappings for upstream authors who have never contributed to this fork. 2. Sync PRs to main scanned all upstream commits the sync brings in — again upstream authors, not fork contributors. Fix (both in the workflow and in scripts/audit_pr_attribution.py, which the gate says to keep in sync): - Scan root is now the PR's actual base branch (github.event.pull_request.base.ref; falls back to main on push events). - --first-parent: only the branch's own commit line counts. Upstream history arrives via a sync merge's SECOND parent and is excluded; fork-authored commits (including conflict-resolution commits after a sync merge) remain on the first-parent line and are still counted. Verified locally by simulating both PR shapes: - feature PR off hardened -> exactly the fork's 2 patch commits - sync PR to main -> only merge + carry-forward commits Upstream contributor emails are attributed in upstream's tree and do not belong in this fork's contributors/ directory (the 17 mappings added in 1e8a69f were reverted in c2cd76c; only the fork owner's own commit email mapping remains, and Mavis@pmoves.local from PR #4).
…rection + explicit refspec
Self-review (delivery agent) with the diff treated as hostile:
P1: BASE_REF was interpolated inline via ${{ github.event.pull_request.base.ref }}
into the run: shell — the classic Actions expression-injection pattern. base.ref
is event-controlled; the workflow header itself warns this workflow runs
PR-controlled code. Moved to env: indirection so the value never touches the
shell parser as code.
P2: 'git fetch origin $BASE_REF' left refs/remotes/origin/$BASE_REF existence
to opportunistic ref updates. Explicit refspec
+refs/heads/$BASE_REF:refs/remotes/origin/$BASE_REF guarantees resolution.
Semantics unchanged: same scan root (PR base branch), same --first-parent
range, verified earlier against both real PR shapes.
Owner
Author
CI Review — contributor-check.yml gate fix (the fork's only CI delta vs upstream)Reviewed per the Findings & dispositions:
Conclusion: the CI-sensitive delta is reviewed and safe. With dcfd943 applied, adding |
1 task done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Syncs fork
mainwithupstream/main(NousResearch/hermes-agent), bringing the fork from the 2026-06-08 sync point to upstream tipb742be711(~24k commits — the fork's June sync base sat far behind upstream's own history; the practical delta is upstream June 8 → Aug 26).Follows the established pattern of #1, #2, #3.
Why now
check-attributionon PR #5 (pmoves-bootstrap un-strand onto hardened) computesmerge-base(origin/main, HEAD); with fork main stuck at the June sync, all 42 upstream commits already insidePMOVES.AI-Edition-Hardenedpresent as "new unmapped contributor emails" and the gate cannot pass. Syncing fork main realigns the merge base and lets the hardened PR validate correctly.Changes Made
upstream/main(b742be7) into fork mainscripts/release.py—LEGACY_AUTHOR_MAPis FROZEN upstream; dropped the fork-side dict entries. TheMavis@pmoves.localmapping is carried forward ascontributors/emails/Mavis@pmoves.local(the merge-conflict-free directory mechanism upstream created for exactly this)..gitattributes— union merge: kept upstream's additions and the fork'spmoves_bootstrap/cgp_schema/*.json text eol=lfrule (SHA-256 byte-compare drift guard against the canonical PMOVES.AI schema copy).pmoves_bootstrap/(PR feat(pmoves-bootstrap): CGP consumer + tools_bridge + subscriber stub for Hermes #4's package) untouched and intact.Type of Change
Verification
python3 -c "ast.parse(...)"on resolved release.py — OK.gitattributesretains the pmoves CGP eol rule post-mergepmoves_bootstrap/package files present at merge tip