feat(agent): coding-context posture across CLI/TUI/desktop/ACP by OutThisLife · Pull Request #43316 · NousResearch/hermes-agent

OutThisLife · 2026-06-10T05:08:47Z

Summary

Now that the desktop app has a real terminal pane (#42521), the missing piece is Hermes knowing it's pair-programming and adapting to the surface it's on (CLI / TUI / desktop GUI / ACP). This makes a coding posture base Hermes behavior — every interactive coding surface gets it, not just the GUI.

When Hermes runs on an interactive coding surface inside a code workspace, it now:

Adds an operating brief to the system prompt: trace symbols before editing, batch independent reads/searches into one turn, focused diffs (no drive-by refactors/renames/reformatting), match project conventions, never substitute chat code blocks for tool edits, re-read a file before retrying a failed patch (and escalate to a write_file rewrite after the same region fails twice), fix root causes and the bug class — sibling call paths included — not just the reported site, cap linter-fix loops, verify with tests, never read/print/commit secrets, git is the user's (don't commit/push unasked).
Steers the edit format per model family. The patch tool exposes two modes — mode="patch" (V4A multi-file diff) and mode="replace" (find-and-swap). Matching the format to how a model was trained cuts mistakes and wasted reasoning, so the brief nudges GPT/Codex-family models toward V4A patches, and Claude-family, Gemini, and open-weight coding models (DeepSeek, Qwen, Kimi, GLM, Grok, Hermes, Llama, Mistral, Devstral, MiniMax — whose RL scaffolds use str_replace-style editors) toward string-replacement. Unknown families get the brief's neutral wording. The nudge is a single cached string appended to the brief, and the model id is fixed for the session, so it's cache-safe.
Injects a live workspace snapshot: git root, branch + upstream (ahead/behind), linked-worktree note, dirty/staged/untracked/conflict counts, and the last 3 commits — plus detected project facts that hand the model its verify loop up front: manifests + package manager (lockfile sniff), the exact verify commands (package.json scripts with the right runner, Makefile verify targets, scripts/run_tests.sh, pytest config), and which context files (AGENTS.md / CLAUDE.md / .cursorrules) exist at the root. Marker-only (non-git) projects get the facts snapshot too, just without the git lines. All stat-cheap with size-guarded reads, built once at prompt time.
Prunes non-coding skill categories from the prompt's skill index (cooking / social-media / smart-home / email / …). Discovery-only: skills_list still returns the full catalog, skill_view loads anything, and a footer note tells the model the full catalog exists. Deny-list semantics — unknown/custom categories stay visible; coding-adjacent ones (github, devops, data-science, research, …) are never hidden.

The default posture is prompt-only — configured toolsets are never touched. The strippable toolsets (messaging, smart-home, music, computer-use, …) are off-by-default for everyone anyway, and a user who explicitly enabled image-gen (frontend/game-dev assets) or Spotify shouldn't lose it for being in a git repo.

For users who want a lean schema, the opt-in focus mode additionally collapses the toolset to a new coding set — files, terminal, search, web docs, skills, todo, delegate, vision, browser — plus the user's enabled MCP servers.

Activation

Config agent.coding_context:

auto (default) — prompt-only posture when the surface is interactive AND cwd is a code workspace. Toolsets untouched; messaging platforms never affected.
focus (explicit opt-in) — auto + collapse the toolset to the coding set + enabled MCP servers.
on — force the prompt posture everywhere (incl. non-workspaces).
off — disable entirely.

A --toolsets flag or HERMES_TUI_TOOLSETS pin always wins — focus only fills the default selection. A /coding flip is deferred to a follow-up (takes effect next session, same contract as /skills install vs --now).

Architecture — one seam, many domains

Coding-context is modelled as a frozen RuntimeMode selected from a small ContextProfile registry (coding / general). A profile is data: the toolset to collapse to, the operating brief, the categories to prune, and model_hint / memory_policy seams for future routing/memory consumers. Every domain reads the same resolved object instead of re-deciding "are we coding?":

System prompt → RuntimeMode.system_blocks() (brief + per-model edit nudge + workspace snapshot), injected in the stable tier in agent/system_prompt.py.
Toolset → RuntimeMode.toolset_selection() — non-None only under focus; applied at the two unpinned-default call sites: cli.py and tui_gateway/server.py::_load_enabled_toolsets().
Delegation → subagents inherit the parent's toolset and run through the same prompt builder, so the posture propagates to children for free — no delegate_task change.
Model / memory → declared on the profile as the extension seam; consumers read mode.profile rather than re-probing.

resolve_runtime_mode() is the single entry point; the object is immutable and resolved once per session.

Posture isolation

The coding toolset is marked posture: True in TOOLSETS, and the non-configurable-toolset recovery loop in hermes_cli/tools_config.py::_get_platform_tools() skips posture toolsets. Without this, the recovery heuristic (built for kanban-style platform toolsets) would silently auto-add coding to every platform's resolved toolsets — including messaging. Posture selection belongs exclusively to agent/coding_context.py; per-platform tool config never sees it.

Detection

Under auto/focus, a directory counts as a code workspace when it's inside a git repo OR under a recognised project root (pyproject.toml, package.json, Cargo.toml, go.mod, AGENTS.md, …) — detection walks up to the workspace root, so non-git project dirs count too. Messaging platforms (telegram/discord/slack/…) are never auto-activated.

$HOME dotfiles guard: a git repo rooted exactly at the home directory — or a marker sitting in $HOME (e.g. a global ~/AGENTS.md) — is user config, not a code workspace. Without the guard, every session anywhere under a dotfiles-managed home would silently flip to the coding posture. Real projects under such a home still detect via their own markers/repos; on mode bypasses the guard.

Cache safety

The brief, edit-format nudge, and git snapshot are built once at prompt-build time and baked into the stable system prompt — never re-probed per turn (that would shatter the prompt cache). Detection itself is intentionally not memoized (cheap stat calls) so a long-lived gateway/TUI process can't pin a stale posture. Branch/dirty state drift, so the brief tells the model to re-run git status/git branch before relying on the snapshot.

Sample of the assembled snapshot against this repo:

Workspace (snapshot at session start — re-check with `git` before acting on it):
- Root: ~/www/hermes-agent
- Branch: bb/coding-context → origin/bb/coding-context
- Status: 2 modified
- Recent commits:
    be86382ba docs(agent): correct memoization docstring + clarify TUI config-load asymmetry
    ...
- Project: pyproject.toml, setup.py, package.json, Dockerfile (uv/npm)
- Verify: scripts/run_tests.sh; pytest
- Context files: AGENTS.md

Test plan

scripts/run_tests.sh tests/agent/test_coding_context.py (46 tests) — RuntimeMode seam (resolve, frozen, system_blocks, focus-gated toolset_selection), profile registry, detection (git / manifest / parent-dir / bare-dir / $HOME-dotfiles guard truth table), resolver (auto/focus/on/off + surface gating), prompt-only invariants for auto/on, per-model edit-format steering (incl. Gemini + open-weight families), project facts (package.json scripts + lockfile sniff, Makefile verify targets, run_tests.sh, pytest config, context files, malformed-JSON tolerance, marker-only non-git snapshot), git probe (clean/dirty/branch/worktree/parse).
scripts/run_tests.sh tests/agent/test_prompt_builder.py — skill-index category pruning (top-level + nested categories, disclosure note, cache-key separation between filtered/unfiltered).
scripts/run_tests.sh tests/agent/test_system_prompt.py::TestCodingContextBlock — brief+snapshot present when active, absent when off / without tools.
scripts/run_tests.sh tests/test_tui_gateway_server.py — TUI toolset resolution incl. the env-pin fallback paths, which also assert the posture toolset stays out of per-platform recovery.

Notes for reviewers:

Most of the ty diff warnings on this PR are inference noise from TOOLSETS dict values widening to str | list[str] | bool after the posture: True marker — the affected call sites are pre-existing patterns, and the check is non-blocking by design.

Pre-existing env-dependent failures on main (test_none_when_terminal_cwd_unset, the browser-launch-hint TUI test, provider adapters, LSP) are unaffected by this change.

github-actions · 2026-06-10T05:10:02Z

🔎 Lint report: `bb/coding-context` vs `origin/main`

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 10673 on HEAD, 10658 on base (🆕 +15)

🆕 New issues (15):

Rule	Count
`unsupported-operator`	6
`invalid-argument-type`	5
`not-iterable`	2
`invalid-assignment`	1
`unresolved-import`	1

First entries

tools/delegate_tool.py:520: [invalid-argument-type] invalid-argument-type: Argument to bound method `set.update` is incorrect: Expected `Iterable[Unknown]`, found `str | list[str] | list[Unknown] | bool`
tests/hermes_cli/test_tools_config.py:915: [invalid-argument-type] invalid-argument-type: Argument to `set.__init__` is incorrect: Expected `Iterable[str | Unknown]`, found `str | list[str] | list[Unknown] | bool`
tools/delegate_tool.py:530: [invalid-argument-type] invalid-argument-type: Argument to `set.__init__` is incorrect: Expected `Iterable[str | Unknown]`, found `(str & ~AlwaysFalsy) | (list[str] & ~AlwaysFalsy) | (list[Unknown] & ~AlwaysFalsy) | Literal[True]`
tests/tools/test_discord_tool.py:637: [unsupported-operator] unsupported-operator: Operator `not in` is not supported between objects of type `Literal["discord"]` and `str | list[str] | list[Unknown] | bool`
tests/tools/test_browser_console.py:125: [unsupported-operator] unsupported-operator: Operator `in` is not supported between objects of type `Literal["browser_console"]` and `str | list[str] | list[Unknown] | bool`
tools/delegate_tool.py:128: [not-iterable] not-iterable: Object of type `str | list[str] | list[Unknown] | bool` may not be iterable
tests/tools/test_discord_tool.py:640: [unsupported-operator] unsupported-operator: Operator `not in` is not supported between objects of type `Literal["discord_admin"]` and `str | list[str] | list[Unknown] | bool`
toolsets.py:605: [invalid-argument-type] invalid-argument-type: Argument to `set.__init__` is incorrect: Expected `Iterable[str | Unknown]`, found `str | list[str] | list[Unknown] | bool`
tests/agent/test_coding_context.py:264: [invalid-assignment] invalid-assignment: Property `profile` defined in `RuntimeMode` is read-only
tests/test_toolsets.py:211: [not-iterable] not-iterable: Object of type `str | list[str] | list[Unknown] | bool` may not be iterable
tests/tools/test_discord_tool.py:623: [unsupported-operator] unsupported-operator: Operator `in` is not supported between objects of type `Literal["discord"]` and `str | list[str] | list[Unknown] | bool`
tests/tools/test_video_analyze.py:331: [unsupported-operator] unsupported-operator: Operator `in` is not supported between objects of type `Literal["video_analyze"]` and `str | list[str] | list[Unknown] | bool`
tests/tools/test_discord_tool.py:624: [unsupported-operator] unsupported-operator: Operator `in` is not supported between objects of type `Literal["discord_admin"]` and `str | list[str] | list[Unknown] | bool`
tests/test_toolsets.py:222: [invalid-argument-type] invalid-argument-type: Argument to `set.__init__` is incorrect: Expected `Iterable[str | Unknown]`, found `str | list[str] | list[Unknown] | bool`
tests/agent/test_coding_context.py:7: [unresolved-import] unresolved-import: Cannot resolve imported module `pytest`

✅ Fixed issues: none

Unchanged: 5566 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

Hermes detects when it's running in a coding context — an interactive surface (CLI, TUI, ACP, desktop) sitting in a code workspace (git repo or recognised project root) — and shifts into a coding posture. Outside that (chat platforms, non-workspaces) nothing changes. The posture is modelled as a frozen RuntimeMode selected from a small ContextProfile registry (coding/general). A profile is data: the toolset to collapse to, the operating brief to inject, and seams for model routing and memory. Every domain reads the same resolved object instead of re-probing git/config on its own: - System prompt — RuntimeMode.system_blocks(): an operating brief (gather context before editing, edit through tools not chat, verify with terminal, cap retry loops) plus a live git/workspace snapshot, built once and baked into the stable prompt tier so per-conversation caching is preserved. - Per-model edit-format tuning — the brief nudges each model family toward the patch mode it handles best: OpenAI/Codex toward mode='patch' (V4A multi-file diffs), Anthropic toward mode='replace' (string replacement). The model id rides on RuntimeMode; unknown families keep neutral wording. - Skill index — non-coding skill categories are pruned from the prompt's skill index (discovery-only; skills_list/skill_view still reach the full catalog, with a disclosure note). - Toolset — only under the opt-in 'focus' mode does the posture collapse to the coding toolset + enabled MCP servers; the default posture is prompt-only and never overrides configured toolsets. Activation via agent.coding_context: auto (default), focus, on, off. Subagents inherit the posture for free via toolset inheritance + the shared prompt builder. Detection is not memoized so a long-lived gateway/TUI process can't pin a stale posture across working directories.

The per-model edit-format guidance only addressed editing existing code (patch mode='patch' vs 'replace'), but authoring a brand-new file — write_file, not patch — is a large fraction of real coding work and the nudge was silent on it. Surfaced when building a single-file artifact where the dominant operation was write_file and the steering offered no guidance. Both family lines now lead with "author new files with write_file; for edits to existing code prefer ...". Tests assert write_file appears in each family's brief; unknown families still get neutral wording.

OutThisLife · 2026-06-10T18:59:55Z

Validation: unit + integration tests, plus live dogfood evals

Beyond the unit suite, I exercised the posture end-to-end — both the resolver logic and the actual lived behavior of an agent running inside the posture.

Automated

Unit (tests/agent/test_coding_context.py, 36 tests): resolver truth table (auto/focus/on/off × git/marker/subdir/bare-dir × interactive/messaging surfaces), per-model edit-format family detection, the new-file write_file clause, cache-key participation, and the inert-general-posture invariants.
Integration (driving the real build_system_prompt_parts): confirmed the operating brief + workspace snapshot + per-model edit-format nudge actually land in the assembled stable prompt tier for cli, and are fully absent on telegram (the "knows it's coding, but not all the time" contract). Verified per-family steering: Anthropic → mode='replace', OpenAI/Codex → mode='patch' (V4A), unknown families → neutral wording.
Detection portability: built a throwaway project in /tmp and resolved the posture against it from scratch — proved marker-only detection works without git (package.json alone flips to coding), walk-up detection from a subdir works, the workspace block is correctly git-gated (coding posture fires on a non-git project, just without the snapshot), and a bare dir stays general.

Dogfood evals (agent operating under the posture)

Ran two greenfield builds as a real coding agent inside the posture, then retrospected on whether the harness changed behavior:

The "verify before claiming done" brief line is the highest-value piece by a wide margin. On a single-file three.js build it caught a THREE.Timer import that silently froze the app on a black screen with zero console errors — a code-only review passes that; the browser verify-loop didn't. On a second build it caught two HUD bugs (a label drowned in bloom, labels clipping the viewport edge) that I hadn't predicted. Three real bugs caught by the observe step in two toy projects.
The new-file-vs-edit split added in 52ac8ac (write_file to author, patch to edit) immediately governed real work: full rewrites went through write_file, surgical fixes through patch mode='replace' — matching the Anthropic-family steering without conscious effort.
"Tools not chat" held throughout — no large code blocks pasted into replies as a substitute for editing.

Notes / non-gaps surfaced

The workspace snapshot assumes one workspace per session (it's pinned at session start, cache-safe by design). Working in a different dir mid-session leaves it stale-but-labeled ("re-check with git") — correct tradeoff, not a bug.
The posture intentionally encodes correctness discipline, not taste. It made working code ship fast; aesthetic judgment came from the agent + vision, not the harness. That's the right boundary.

The new-file fix (52ac8ac) closed the one real gap these evals exposed; the rest are correct-by-design tradeoffs. Posture's in good shape.

…asymmetry

…it steering, $HOME guard Tuning pass on the coding posture from dogfooding it as a harness: - Workspace snapshot now hands the model its verify loop up front: detected manifests + package manager (lockfile sniff), the exact verify commands (package.json scripts, Makefile targets, scripts/run_tests.sh, pytest config), and which context files (AGENTS.md / CLAUDE.md / .cursorrules) exist at the root. Marker-only (non-git) projects get the snapshot too instead of nothing. The "verify before claiming done" brief line was the highest-value piece in evals — this turns it from advice into an executable loop instead of making the model rediscover the test command every session. Still stat-cheap, size-guarded reads, built once at prompt time. - Edit-format steering covers the families Hermes actually serves: Gemini and open-weight coding models (DeepSeek, Qwen, Kimi, GLM, Grok, Hermes, Llama, Mistral, Devstral, MiniMax) steer to mode='replace' — their RL scaffolds use str_replace-style editors. Previously only GPT/Codex and Claude families got steering; the models Hermes users disproportionately run all fell to neutral. - Operating brief gains four behaviors elite harnesses encode: batch independent reads/searches in one turn; fix root causes and the bug class (sibling call paths), not the reported site; no drive-by refactors/renames/reformatting; never read, print, or commit secrets. Plus a patch-failure escalation ladder: after the same region fails twice, rewrite the enclosing function/file with write_file instead of a third patch attempt. - $HOME dotfiles guard: a git repo rooted exactly at the home directory (or a marker sitting in it, e.g. a global ~/AGENTS.md) is user config, not a code workspace — without the guard, every session anywhere under a dotfiles-managed home silently flipped to the coding posture. Real projects under such a home still detect via their own markers/repos; 'on' mode bypasses the guard.

OutThisLife · 2026-06-11T03:08:17Z

Validation round 2 — tuning pass (`aa35e8b`) + live evals against fake projects

Beyond the unit suite (46 tests), I validated the tuning pass two ways: an exhaustive harness-side matrix with real imports, and live hermes -z runs against planted-bug projects under /tmp.

Harness matrix (9 scenarios, real `resolve_runtime_mode` + `build_coding_workspace_block`, no LLM)

Scenario	Posture	Snapshot
node + pnpm-lock git repo	coding	`package.json (pnpm)` · `Verify: pnpm run test; pnpm run lint` (`dev` script correctly excluded)
python + uv.lock + AGENTS.md	coding	`pyproject.toml (uv)` · `Verify: pytest` · `Context files: AGENTS.md`
node repo from `src/` subdir	coding	walk-up resolves the root
marker-only project, no git	coding	facts snapshot, no git lines, `npm` fallback runner
bare dir	general	—
node repo on telegram surface	general	—
node repo, `focus` mode	coding	toolset collapses to `coding` + MCP
dotfiles repo at `$HOME`	general	guard holds
plain subdir of dotfiles `$HOME`	general	guard holds

Live CLI evals (agent operating under the posture)

Snapshot recall (zero tools allowed). Asked, in the python project, for the test command / package manager / agent-instruction file with tools forbidden. Answered pytest / uv / AGENTS.md in 5.5s with zero tool calls. uv is only knowable from the lockfile sniff and AGENTS.md only from the snapshot — causal evidence the verify-loop injection works, not a lucky guess. Every coding session now starts with the test command in hand instead of a 3–4 tool-call discovery dance.

Fix-and-verify (planted off-by-one in a node project). Found i <= items.length, made a one-character diff, verified the suite green before claiming done, summarised instead of pasting code, and did not commit — working tree left modified for the user. 24s end to end.

Root-cause / bug-class (the hard one). Reported only test_calc.py::test_even failing in median, while a sibling running_median carried the identical midpoint flaw with no test covering it. The agent fixed the reported site, went looking for the same flaw elsewhere, caught the untested sibling, and collapsed it to reuse the corrected logic — exactly the new "fix the class, check sibling call paths" brief line doing its job. Models' default failure mode here is tunnel vision on the named test; this is the strongest single result of the round.

Discipline lines all held across runs: no commits, minimal diffs, no chat code blocks, AGENTS.md style respected.

OutThisLife · 2026-06-11T03:49:39Z

Validation round 3 — context-provisioning A/B (the thing this PR is actually for)

The posture's goal is Cursor-style context provisioning: the model should know the workspace — runner, verify command, conventions — instead of burning tool calls rediscovering it every session (or guessing wrong). So this round measures trajectories, not solve rate, with an A/B between two isolated HERMES_HOME arms identical except agent.coding_context: auto vs off (memory disabled in both). Trajectories mined from the per-arm session DBs: tool-call sequences, every terminal command, tokens.

The context trap

A repo where the obvious verify command fails by design: tests are env-gated (conftest.py raises unless APP_MODE=test) and only runnable via make check. No pytest config in pyproject.toml, so the posture snapshot says exactly Verify: make check. Fix task: a broken loan-payment formula.

Same model, same prompt, same repo:

on  (6 tool calls):  search_files → read_file ×3 → patch → terminal
    $ make check                                              ← straight to the canonical target, 22.7s

off (10 tool calls): search_files → read_file ×2 → search_files → terminal → read_file ×2 → patch → terminal ×2
    $ ls -la && python3 --version                             ← environment discovery probe
    $ make check 2>&1; echo "EXIT: $?"                        ← found only after reading the Makefile
    $ python3 -c "from interest import monthly_payment; ..."  ← redundant ad-hoc re-check, 34.4s

Both fix the bug (4-line diff each, hidden held-out tests pass) — but the posture arm gets there with 40% fewer tool calls, 1 terminal command instead of 3, and ~35% less wall time, because the snapshot already answered the question the off arm had to go ask the filesystem.

Mined trajectories across the other 5 bench tasks (planted-bug repos: off-by-one + untested sibling, mutable-default leak, missing await, multi-file tax bug, anti-test-gaming trap)

Canonical-suite verification: on 5/5 vs off 3/5. With the posture, every run verified through the project's real suite (npm run test, uv run pytest, python3 -m pytest). Without it, both node tasks were "verified" with ad-hoc node -e spot-probes — the repo's test script never ran. Spot-probes check the line you changed; suites catch what you broke elsewhere. This is the "verify before claiming done" contract being load-bearing.
Runner identification. off hedged with guess-chains (pytest -q || python3 -m unittest -v); on used the lockfile-correct runner from the snapshot (uv run pytest).
Fewer discovery probes. on averaged fewer search_files calls before the first meaningful read — the snapshot's Root/Project lines pre-answer "where am I, what is this".
Solve rate itself was identical (frontier model, small bugs — saturated either way), and discipline held in both arms: no commits, gaming-trap test untouched (hash-verified) in all runs.

Net

The posture is an enablement layer, not an intelligence layer — capability the model already has, unlocked by handing it the workspace up front. Enabled: right verify command on the first try, suite-level verification instead of spot checks, lockfile-correct runner, zero environment-discovery tax. The same model without the posture has to earn that context every session through probes — and sometimes doesn't (the skipped node suites). That's the PR's actual job, and it's measurable in the trajectories.

Harness: pristine-copy repos, issue-text-only prompts, held-out hidden tests, anti-gaming hash checks, per-arm temp homes, trajectory mining from state.db. Adding a task is ~30 lines — happy to land it as a follow-up if there's appetite for a standing posture bench.

OutThisLife · 2026-06-11T04:02:34Z

How this PR maps to the published coding-harness literature

Cross-checked the posture against what Cursor, Anthropic, OpenAI, and the academic harness work have actually published (indexing/embeddings excluded — agentic search won that argument). Net: the PR implements the published prompt/context-layer canon nearly point-for-point, and the one mechanism the literature rates highest was already in core Hermes.

vs Cursor's published practice (Continually improving our agent harness + the public 2.0 system prompt)

Cursor's published practice	This PR
Static context block: OS, git status, open files	✓ workspace snapshot (branch/upstream/status/recent commits) + verify-loop facts (manifest, package manager, test/lint commands, context files)
Per-model harness customization — "custom prompting for different providers and even for different model versions"	✓ per-family edit-format steering; `RuntimeMode.model` is the seam for going deeper
"Do not loop more than 3 times to fix linter errors on the same file"	✓ verbatim in the brief
Never print code blocks as a substitute for edits; reference `path:line`	✓
Batch independent tool calls	✓
Todo tracking for multi-step work	✓
Cache-hit rate as a first-class constraint	✓ posture resolved once per session, baked into the stable prompt tier
A/B harness variants; measure tool-call count / token efficiency on real trajectories	✓ the context-provisioning A/B above is exactly this methodology
"Knock down guardrails as models improve; prefer dynamic context the agent can pull"	✓ prompt-only default, snapshot explicitly advisory ("re-check with `git`"), no hard constraints

vs SWE-agent / ACI (NeurIPS 2024)

The paper's biggest ablation win is a linter integrated into the edit tool feeding errors back immediately — removing it cost ~3 points, and removing the edit interface entirely was the single largest drop ("compact, efficient file editing is critical to performance"). That mechanism is already core Hermes: write_file/patch results carry lint and lsp_diagnostics fields back to the model (tools/file_operations.py). This PR adds the context layer the paper didn't study; its other finding — guardrails against repeated-edit failure loops — maps to the brief's re-read-before-retry + the patch→write_file escalation ladder.

vs the rest of the canon

Aider's edit-format benchmarks — format must match model training (diff-style for GPT, string-replacement for Claude/most others). The steering table is this finding, implemented.
Claude Code's env block — cwd, git status, recent commits, CLAUDE.md, "do not commit unless asked", conciseness mandate. The snapshot + brief mirror it nearly field-for-field.
OpenAI's GPT-4.1/Codex guidance — V4A apply_patch for GPT-family models → the mode='patch' nudge.
"Self-verification improves output quality 2–3x" (Boris Cherny, Claude Code) → the Verify line + verify-before-claiming-done, which the trap eval above showed converting ad-hoc spot-probes into suite-level verification.

What the published bar has that this PR deliberately doesn't

Depth of per-model customization — Cursor swaps whole prompt/tool variants per model version; this PR ships one steering line per family. The ContextProfile/RuntimeMode.model seam is built for that growth without re-architecting.
Per-tool/per-model error telemetry (Cursor's anomaly-detection baselines) — out of scope here; separate infrastructure.
IDE-only dynamic context (recently-viewed files, cursor position) — structurally N/A for CLI/TUI/ACP surfaces; the ACP layer can carry editor state later via the same seam.

Direction-wise there's nothing in the published literature this posture contradicts — the remaining gaps are depth on an already-correct seam.

…t context-files line; cite edit-format sources Follow-up to #43316 (coding-context posture): - Skill-category pruning from the prompt's skill index now only fires under the opt-in 'focus' mode, matching the toolset-collapse gating. The default 'auto' posture must never silently hide skills — a hidden skill is effectively never loaded proactively, footer note or not. - Drop the 'Context files: AGENTS.md ...' line from the workspace snapshot: those files' full contents are already injected into the system prompt as the Project Context block, so naming them again is redundant. - Replace the unsourced edit-format steering rationale with citations: OpenAI GPT-4.1 prompting guide (apply_patch/V4A), Anthropic text-editor tool docs (str_replace schema trained into the model), and the str_replace-style editors in SWE-agent/OpenHands/Qwen Code/Gemini CLI.

* feat(agent): coding-context posture with per-model edit-format tuning Hermes detects when it's running in a coding context — an interactive surface (CLI, TUI, ACP, desktop) sitting in a code workspace (git repo or recognised project root) — and shifts into a coding posture. Outside that (chat platforms, non-workspaces) nothing changes. The posture is modelled as a frozen RuntimeMode selected from a small ContextProfile registry (coding/general). A profile is data: the toolset to collapse to, the operating brief to inject, and seams for model routing and memory. Every domain reads the same resolved object instead of re-probing git/config on its own: - System prompt — RuntimeMode.system_blocks(): an operating brief (gather context before editing, edit through tools not chat, verify with terminal, cap retry loops) plus a live git/workspace snapshot, built once and baked into the stable prompt tier so per-conversation caching is preserved. - Per-model edit-format tuning — the brief nudges each model family toward the patch mode it handles best: OpenAI/Codex toward mode='patch' (V4A multi-file diffs), Anthropic toward mode='replace' (string replacement). The model id rides on RuntimeMode; unknown families keep neutral wording. - Skill index — non-coding skill categories are pruned from the prompt's skill index (discovery-only; skills_list/skill_view still reach the full catalog, with a disclosure note). - Toolset — only under the opt-in 'focus' mode does the posture collapse to the coding toolset + enabled MCP servers; the default posture is prompt-only and never overrides configured toolsets. Activation via agent.coding_context: auto (default), focus, on, off. Subagents inherit the posture for free via toolset inheritance + the shared prompt builder. Detection is not memoized so a long-lived gateway/TUI process can't pin a stale posture across working directories. * feat(agent): cover new-file authoring in the coding edit-format nudge The per-model edit-format guidance only addressed editing existing code (patch mode='patch' vs 'replace'), but authoring a brand-new file — write_file, not patch — is a large fraction of real coding work and the nudge was silent on it. Surfaced when building a single-file artifact where the dominant operation was write_file and the steering offered no guidance. Both family lines now lead with "author new files with write_file; for edits to existing code prefer ...". Tests assert write_file appears in each family's brief; unknown families still get neutral wording. * docs(agent): correct memoization docstring + clarify TUI config-load asymmetry * feat(agent): sharpen the coding posture — verify-loop facts, wider edit steering, $HOME guard Tuning pass on the coding posture from dogfooding it as a harness: - Workspace snapshot now hands the model its verify loop up front: detected manifests + package manager (lockfile sniff), the exact verify commands (package.json scripts, Makefile targets, scripts/run_tests.sh, pytest config), and which context files (AGENTS.md / CLAUDE.md / .cursorrules) exist at the root. Marker-only (non-git) projects get the snapshot too instead of nothing. The "verify before claiming done" brief line was the highest-value piece in evals — this turns it from advice into an executable loop instead of making the model rediscover the test command every session. Still stat-cheap, size-guarded reads, built once at prompt time. - Edit-format steering covers the families Hermes actually serves: Gemini and open-weight coding models (DeepSeek, Qwen, Kimi, GLM, Grok, Hermes, Llama, Mistral, Devstral, MiniMax) steer to mode='replace' — their RL scaffolds use str_replace-style editors. Previously only GPT/Codex and Claude families got steering; the models Hermes users disproportionately run all fell to neutral. - Operating brief gains four behaviors elite harnesses encode: batch independent reads/searches in one turn; fix root causes and the bug class (sibling call paths), not the reported site; no drive-by refactors/renames/reformatting; never read, print, or commit secrets. Plus a patch-failure escalation ladder: after the same region fails twice, rewrite the enclosing function/file with write_file instead of a third patch attempt. - $HOME dotfiles guard: a git repo rooted exactly at the home directory (or a marker sitting in it, e.g. a global ~/AGENTS.md) is user config, not a code workspace — without the guard, every session anywhere under a dotfiles-managed home silently flipped to the coding posture. Real projects under such a home still detect via their own markers/repos; 'on' mode bypasses the guard.

… project.facts RPC (NousResearch#51259) Follow-up to the coding-context posture (NousResearch#43316): that PR detects each repo's verify loop (manifests, package manager, exact test/lint/build commands, context files) and bakes it into the system-prompt snapshot — but only as a string, for the model. Non-prompt consumers (the desktop verify UI) had no way to read it without re-sniffing and drifting from the prompt. Split detection from rendering, keeping one source of truth: - `detect_project_facts(root) -> ProjectFacts` (frozen) holds the structured facts; `_project_facts()` now renders it into the same snapshot lines, so the prompt block stays byte-identical (cache-safe). - `project_facts_for(cwd)` resolves the workspace root (git, else marker) and returns the structured facts, or None outside a workspace. - `project.facts` gateway RPC surfaces it to any client (desktop/TUI/ACP). Tests assert the structured output and that the UI-facing commands never drift from what the prompt block renders (one detector feeds both).

…or flat sprites (#1) * feat(pets): pet engine + display.pet config Add the shared pet engine under agent/pet/: spritesheet manifest loading and in-process caching, six-state animation model, frame rendering, and the persistent pet store. Register the display.pet config block (pet, scale, enabled, etc.) that every surface reads from. Covered by tests/agent/test_pet_engine.py. * feat(pets): CLI pet pane + /pet command Render the reactive pet pane in the classic CLI (steady redraw, right-aligned) and wire the /pet command to list and switch pets, plus an enable/disable toggle. Backed by hermes_cli/pets.py and the CLI commands mixin, registered in the central command registry. Covered by the CLI pet pane and toggle tests. * feat(pets): TUI pet pane, picker + gateway RPCs Add the Ink pet sprite pane, the interactive /pet picker overlay, and live pet switching/rescale driven by new tui_gateway RPCs (pet state, pet.scale, per-state frames). Wires pet flash state and the picker into the TUI layout and slash handler. Covered by the slash-handler test. * feat(desktop): floating pet, pop-out overlay + Cmd+K picker Add the in-window floating pet (sprite, speech bubble, contact shadow, profile-scoped, resize-safe) and a pop-out always-on-top overlay window with gestures and notifications. Add the Cmd+K pet picker page plus the appearance gallery and size slider in settings. Includes the pet stores, electron overlay wiring, i18n strings, and store tests. * docs(pets): feature guide, petdex skill + catalog Add the pets feature guide and the petdex skill (SKILL.md + bundled doc), and register them in the website sidebar and skills catalog. * fix(desktop): portal floating composer to body so it can't be clipped off-screen The popped-out composer is position:fixed, but the chat content wrapper sets `contain: layout paint`, which makes it a containing block for — and clips — fixed descendants. Inline, the floating composer was positioned/clipped relative to the chat column (which shifts with the sidebars), not the viewport, so the viewport-based bounds clamp from #50466 couldn't keep it reachable: users still lost it off-screen. Portal it to <body> when popped out so fixed positioning and the clamp finally share the viewport as their reference. Docked stays inline (it's absolute within the chat column by design). * fix(desktop): move composer out of contain wrapper instead of portaling Replaces the body-portal approach: render ChatBar as a sibling of the contain:[layout paint] chat wrapper (inside the same runtime boundary) rather than portaling the floating instance to <body>. The wrapper is a containing block for — and clips — position:fixed descendants, which is what stranded the popped-out composer off-screen. As a sibling it anchors to the outer relative container: docked stays absolute (identical placement), floating resolves against the viewport. Both states stay mounted, so dock<->float no longer remounts the editor (the portal toggle did). * fix(desktop): clamp floating composer to the thread area, not the whole window Now that the popped-out composer is fixed to the viewport, clamping against the window let it slide under a pinned sidebar. Confine it to the thread region (data-slot="composer-bounds") instead — its rect already excludes a pinned sidebar and the header — falling back to the full window before it's measured. This subsumes the old titlebar top-margin (the thread rect starts below the header). * fix(desktop): guarantee out-of-bounds composer is reclamped on load Re-clamp once more on the next frame after pop-out so layout (sidebar widths, fonts) has settled, and treat a degenerate pre-layout bounds rect as "unknown" (fall back to the window) so we never clamp the box into a collapsed area. Net: anyone who loads in with a stranded position is pulled back on-screen and the fix is persisted, even if the first measure was premature. * feat(skills): add cloudflare-temporary-deploy optional skill (#50849) * chore: re-trigger CI (workflows did not dispatch on prior head) * feat(skills): add cloudflare-temporary-deploy optional skill Optional web-development skill teaching the agent to deploy a Worker to a live workers.dev URL with no Cloudflare account via 'wrangler deploy --temporary' (Wrangler 4.102.0+). Cloudflare provisions a throwaway, claimable account valid for 60 minutes — ideal for an autonomous write->deploy->verify loop with no OAuth/signup hard stop. - SKILL.md: when/when-not, prereqs (unauth requirement, version floor), step-by-step deploy + verify flow, product limits table, pitfalls (hidden flag, stale global wrangler, auth-present error, rate limits, workers.dev edge cache), verification. - scripts/parse_deploy_output.py: stdlib-only parser extracting live URL, claim URL, account name/state, expiry, deploy status from wrangler output. - tests/skills/test_cloudflare_temporary_deploy_skill.py: 16 tests incl. a real-output regression case. Verified live end-to-end: temporary account created with no creds, deployed to a live URL, curl confirmed body, redeploy reused the account. * feat(goals): completion contracts for /goal — evidence-based judging (#50501) Adds an optional structured completion contract to the standing-goal loop, adapted from OpenAI Codex's /goal guidance (a durable objective works best when it names what done means, how to prove it, what not to break, what's in scope, and when to stop). A contract has five optional fields — outcome, verification, constraints, boundaries, stop_when. When set, the continuation prompt tells the agent to target the verification surface and respect constraints, and the judge marks the goal done only when the verification criterion is met with concrete evidence (command result, file excerpt, test output) instead of a loose "looks done" claim. This tightens the most common /goal failure mode: premature completion / endless over-continuation on an underspecified goal. Two ways to set a contract, both backward compatible (bare /goal <text> behaves exactly as before): - /goal draft <objective> — expands plain text into a full contract via the goal_judge aux model (cache-safe side call), falls back to a free-form goal if the model is unavailable. - /goal <text> with inline 'field: value' lines (verify:, constraints:, boundaries:, stop when:, ...). Plain goals with an incidental colon are not mangled — only known field prefixes are pulled out. - /goal show prints the active contract. Contracts persist in SessionDB.state_meta alongside the goal (survive /resume), compose with /subgoal criteria, and old goal rows load unchanged. CLI + every gateway platform via the shared GoalManager engine; zero new model tools. Tests: +18 in tests/hermes_cli/test_goals.py (parse/serialize/judge-prompt/ draft/fallback), 73/73 green; 42/42 across the broader goal test surface; live E2E roundtrip (set -> persist -> reload -> contract-aware prompts) green. * fix(computer-use): route CuaDriver vision capture via get_window_state cua-driver 0.6.x removed the standalone screenshot MCP tool, so capture(mode='vision') hit 'Unknown tool: screenshot' and returned a 0x0 image with no PNG while som/ax (which use get_window_state) still worked. Route vision through get_window_state(capture_mode='vision'). Salvaged from PR #50771; same fix submitted earlier as #39262 by @Tranquil-Flow. * feat(computer-use): add whole-screen/desktop capture target capture(app='screen'|'desktop') now resolves to the OS shell/desktop window (Windows Progman/WorkerW desktop or Shell_TrayWnd taskbar, macOS Finder/Dock) so 'show me my screen' and 'click the taskbar' work. Previously capture() only matched application windows, and the schema advertised 'or the whole screen' without any code path delivering it. cua-driver is window-oriented (no virtual-desktop or per-monitor MCP tool), so a single image still cannot span multiple monitors — the schema now states this and the no-desktop-window path returns a clear message instead of silently grabbing the frontmost app. * hermes_state: add SessionDB.delete_telegram_topic_binding (#31501) Targeted ``(chat_id, thread_id)`` prune for the ``telegram_dm_topic_bindings`` table — the missing piece for #31501, where the Telegram adapter detects a topic the user deleted out-of-band but the binding row keeps living in state.db. The recovery logic in ``gateway.run._recover_telegram_topic_thread_id`` then steers every future inbound message back to the dead topic, dropping tool progress, approvals and replies into the wrong place. Returns the number of rows deleted; silently no-ops when the topic-mode tables haven't been migrated yet (read-only / pristine profile) so the helper is safe to call from a send-fallback hot path before the schema has run. * gateway/telegram: prune stale DM topic binding on Thread-not-found (#31501) Both fallback sites that currently log "Thread X not found, retrying without message_thread_id" now also drop the ``telegram_dm_topic_bindings`` row keyed on ``(chat_id, thread_id)``: * The streaming send loop (``send`` body) — fires on the second failure, after the same-thread one-shot retry confirms the thread really is gone (the first attempt is left alone because Bot API has been observed to return a transient "Thread not found" that recovers on immediate retry). * The control-message helper ``_send_message_with_thread_fallback`` (approval prompts, model picker, update prompts) — single-shot retry, prune unconditionally on the BadRequest match. Without this prune, a user who deletes a Telegram DM topic in the client keeps getting their next inbound message recovered back to the dead thread by ``_recover_telegram_topic_thread_id`` in ``gateway/run.py``, which walks the per-user binding list newest-first and treats the deleted thread as authoritative. The reproduction in the bug report is exactly this: tool progress, approvals, activity messages and replies all land in the wrong place until the user manually runs DELETE on state.db. Cleanup is best-effort — we log at INFO when it succeeds, swallow any exception from the SessionDB call, and the user-facing send proceeds either way. Refs #31501 * tests: regression coverage for stale topic-binding prune (#31501) Thirteen tests across four layers: * ``SessionDB.delete_telegram_topic_binding`` — pin the new helper's contract: removes only the (chat_id, thread_id) row it was asked about, leaves siblings alone, returns 0 silently when the row never existed, and is a no-op on a pristine database whose topic-mode tables haven't been migrated yet. * ``TelegramAdapter._prune_stale_dm_topic_binding`` — the glue must drop the binding when ``self._session_store._db`` exposes the helper, swallow exceptions so a failed cleanup never breaks the user-facing send, and refuse to issue a DELETE for ``chat_id=None`` / ``thread_id=None`` so a bookkeeping miss can't accidentally null-match every row. * Source-level guards on ``TelegramAdapter.send`` and ``_send_message_with_thread_fallback`` — the prune call must sit beside the two existing "Thread X not found, retrying without message_thread_id" warnings, before the retry runs, so a future refactor can't silently drop the cleanup wire. * End-to-end semantic — once a topic is pruned, the ``GatewayRunner._recover_telegram_topic_thread_id`` walk steers future inbound messages to the surviving binding instead of the dead one. This is the exact behaviour change the bug report's reproduction asks for: no more landings in the wrong topic until the operator hand-edits ``state.db``. Refs #31501 * fix(telegram): disable DM topic mode when last binding is pruned Follow-up to #31501. When the send-fallback prune removes a chat's final telegram_dm_topic_bindings row, also flip telegram_dm_topic_mode.enabled to 0 in the same transaction. Without this, a user who turns topics off in the Telegram client (rather than via /topic off) leaves enabled=1 with zero lanes: _recover_telegram_topic_thread_id keeps treating the chat as topic-enabled and lobby messages keep hunting for bindings that no longer exist. Clearing the flag makes recovery fully stand down once the dead topics are gone. Adds 3 regression tests covering the last-binding clear, the multi-binding no-op, and the unmatched-prune no-op. * fix(api): allow dashboard updates for git checkouts in containers (#51005) Salvages #50469 by @libre-7. _dashboard_local_update_managed_externally() previously blocked every containerized dashboard from the local update API, even when the running install was a bind-mounted git checkout that can be updated with hermes update. Allow the dashboard updater only for git installs inside containers, while keeping hosted /opt/data, docker, and pip installs managed externally. Pip remains blocked because its apply path mutates the running container filesystem and is not the self-managed checkout case. Adds regression coverage for docker, git, and pip install-method handling inside containers, and maps the contributor email for release attribution. Co-authored-by: libre-7 <libre-7@users.noreply.github.com> * fix(model_switch): route typed configured models off openai-codex (#45006) A typed `/model <name>` where `<name>` is declared under `providers.<slug>` or `custom_providers` — but typed while the current provider is a soft-accepting one (e.g. `openai-codex`) — stayed on the current provider and was swallowed as an unknown hidden Codex model, instead of routing to the provider that actually declares it. Add configured-provider exact-match detection (`_configured_provider_matches`) and a new Step d.5 in `switch_model`: if the typed model is declared in user/custom provider config, route to that provider BEFORE `detect_provider_for_model()` guesses from static catalogs and BEFORE the common-path validation lets a soft-accepting current provider swallow the name. - Matching is exact (case-insensitive) against explicitly-declared model collections only (`models`, `model`, `default_model`) — never fuzzy/family. - Same-provider declarer → keep current provider (canonicalize the id). - Multiple declarers → fail clearly and ask for `--provider <slug>`. - Single declarer → route there; for `providers.<slug>` user providers, set `explicit_provider` so the credential block resolves base_url/key from config. - Step e (`detect_provider_for_model`) is gated off when `config_routed`. The deliberately-supported openai-codex / xai-oauth hidden-model soft-accept (#16172 / #19729) is left untouched: when nothing in config matches, detection is a no-op. Salvaged from #45442 by harjothkhara (authorship preserved). Tests: tests/hermes_cli/test_model_switch_configured_provider_routing.py (7 tests). Full model_switch suite: 214 passed. Fixes #45006 * fix(image/video gen): make schema delivery instruction platform-neutral (#51031) * chore: re-trigger CI (workflows did not dispatch on prior head) * fix(image/video gen): make schema delivery instruction platform-neutral The image_generate and video_generate tool schema descriptions hardcoded a gateway-only delivery instruction ('display it with markdown ![description](url-or-path) and the gateway will deliver it'). That schema is sent on every platform, so on CLI it directly contradicted the CLI platform hint ('Do NOT emit MEDIA:/path tags ... state its absolute path in plain text'), and on messaging platforms it was also wrong about the mechanism (local file paths are delivered via MEDIA: tags, not markdown image syntax — markdown ![]() only works for URLs). The per-platform file-delivery convention is already owned correctly by the platform hints in prompt_builder.py. The tool schema now just describes the result shape (URL or absolute path in the image/video field) and defers 'how to deliver' to the active platform's guidance. Provider/model injection already works via _build_dynamic_image_schema() (the 'Active backend: <provider> · model: <model>' line); no change there. * fix(computer-use): delete broken pre-install asset probe; trust the upstream installer `hermes computer-use install` refused to install on Linux, Windows, and macOS x86_64 because the pre-install asset probe was hitting the wrong GitHub endpoint AND duplicating tag-resolution logic the upstream installer already does correctly. `_check_cua_driver_asset_for_arch()` queried `https://api.github.com/repos/trycua/cua/releases/latest`. On trycua/cua: - cua-driver-rs releases (the binary the installer fetches) are marked **prerelease** on every cut. GitHub's `/releases/latest` explicitly skips prereleases. - The Python package releases (`cua-agent`, `cua-computer`, `cua-train`) are non-prerelease and end up as the "latest" instead. Live API check today: $ curl -sf https://api.github.com/repos/trycua/cua/releases/latest \ | jq '{tag:.tag_name, asset_count: (.assets|length)}' { "tag": "agent-v0.8.3", "asset_count": 0 } The probe sees zero assets, prints "Latest CUA release has no Linux x86_64 asset", and skips install on every Linux / Windows / macOS-x86_64 host — even though the cua-driver-rs-v0.6.0 release ships 19 binary assets covering all those platforms. Filtering `/releases?per_page=N` for the `cua-driver-rs-v*` prefix fixes the bug, but it duplicates tag-resolution logic the upstream `_install-rust.sh` already does correctly via `CUA_DRIVER_RS_BAKED_VERSION` (auto-baked by CD on every release, with a `/releases?per_page=N` API fallback for dev checkouts). The right answer is to trust that contract instead of mirroring it in Python where it can drift. Two paths get the same outcome without the probe: 1. **Fresh install**: run `install.sh` directly. It has the baked release tag, fetches the right asset, and errors with a clear message on missing-arch downloads. No preflight needed. 2. **Upgrade path**: `cua_driver_update_check()` (separately added) shells `cua-driver check-update --json` against the installed binary, which returns the canonical update answer from the same source the installer uses. - `hermes_cli/tools_config.py`: delete `_check_cua_driver_asset_for_arch` and its two call sites in `install_cua_driver`. Replace with an inline comment near the top of the module explaining the rationale. - `tests/hermes_cli/test_install_cua_driver.py`: drop the `TestCheckCuaDriverAssetForArch` block. Add `TestArchProbeRemoval` with three regressions: - `test_probe_function_is_gone` — asserts the deleted helpers stay deleted. - `test_fresh_install_does_not_call_github_api` — asserts the install path doesn't hit GitHub directly from Python anymore. - `test_upgrade_with_binary_does_not_call_github_api_directly` — same for the upgrade path. All 9 `test_install_cua_driver` tests pass. Reported by @teknium1 while testing on a headed Ubuntu host. * fix(tests): update cua install tests for cross-platform support f-trycua's #50855 test file predated the cross-platform PR (#50552) and reintroduced two stale tests asserting Linux is unsupported (test_*_non_macos_*, patching platform.system="Linux" and expecting a no-op/warn). Linux + Windows are supported now, so install proceeds on those platforms. Restore main's cross-platform-correct versions: test_*_on_unsupported_platform_* using FreeBSD as the genuinely unsupported case. * fix(agent): complete final text on last turn * fix(cron): deliver max-iteration fallback reports * test(discord): add regression test for 100-command sync limit Add a test to verify that _safe_sync_slash_commands deletes obsolete commands before creating new ones. This ensures we never temporarily exceed Discord's 100-command limit during sync, which would trigger error 30032 and break all slash commands. This test guards against the regression where sync could fail even though the registration cap was properly enforced. * fix(discord): delete obsolete slash commands before creating new ones Discord enforces a hard 100-command limit per app and rejects an upsert that would push the live total over 100 (error 30032), which silently breaks ALL slash commands. The sync deleted obsolete commands AFTER creating new ones, so an app already at the cap momentarily exceeded it and the whole sync failed. Reorder: delete no-longer-desired commands up front, then create/update. Removes the now-redundant trailing delete loop. Adapts @infinitycrew39 PR #50890 to current main (the original adapter diff no longer applied after the platform refactor); test commit cherry-picked with authorship preserved. * fix(cron): fail closed when an unpinned job's provider drifts from creation snapshot (#44585) An unpinned cron job follows the global default provider (config.yaml model.default + resolve_runtime_provider). If that global state is changed after the job is created — e.g. a temporary switch to a paid provider like nous/claude-fable-5 — the job silently inherits it on its next tick and spends real money. This is the reported $7.73 incident: a job created under a free/default provider later inherited a temporary paid switch. Fix (ask #1 only) preserves the legitimate "unpinned job should follow model.default" use case by detecting *drift* rather than freezing the model: - create_job (cron/jobs.py): for UNPINNED, agent-backed jobs (no explicit provider, not no_agent), snapshot the provider that resolution WOULD pick right now into a new optional `provider_snapshot` field, resolved via the same resolve_runtime_provider() path the ticker uses. Fail-open to None on any resolution error so job creation never breaks. - run_job (cron/scheduler.py): right after runtime resolution, if the job has a provider_snapshot AND is unpinned AND the currently-resolved provider DIFFERS from the snapshot, fail closed for that run — make no paid call and deliver a loud, actionable alert naming both providers and telling the user to pin explicitly (`cronjob action=update job_id=.. provider=..`). Back-compat: jobs with no snapshot (pre-existing jobs, no_agent jobs, or any job whose creation-time resolution failed) behave exactly as before — the guard only engages when a snapshot exists. Explicitly-pinned jobs (job.provider set) are unaffected since they don't drift with global state. Tests: tests/cron/test_cron_provider_pin.py covers snapshot-matches (runs), snapshot-differs (fail closed, no agent constructed), no-snapshot back-compat, None-snapshot back-compat, explicitly-pinned (runs regardless), plus create_job snapshot capture/skip/fail-open. The fail-closed case is load-bearing (fails without the guard). Issue #44585 asks #2-4 (hard-stop a running job, gateway-stop containment, fail-closed on provider mutation) are out of scope for this change. * fix(security): deny root-level credential stores in media delivery The media-delivery denylist in gateway/platforms/base.py enumerated only .env/auth.json/credentials/config.yaml under HERMES_HOME, so other credential stores that live at the root fell through and could be auto-attached to chat replies. The reported case: the Google Workspace skill's google_token.json refreshes every turn, bumping its mtime to 'now', which kept passing the strict-mode recency window and re-sent the OAuth token on every reply. Extend the explicit per-file denylist to mirror the canonical credential set already enforced by the read/write guards in agent/file_safety.py: google_token.json, google_oauth_pending.json, auth/google_oauth.json, .anthropic_oauth.json, webhook_subscriptions.json, cache/bws_cache.json, auth.lock, and the pairing/ token directory. Targeted per-file additions (not a blanket ~/.hermes deny, which was declined in #32090/#34425 because it would block skills/, logs/, and ad-hoc agent-written deliverables). mcp-tokens/ (#37222) and state.db/kanban.db (#41071) are left to their sibling targeted PRs. Reported-by: xxxigm (#50912) * fix(memory): apply /memory approve against a fresh store when no live agent The CLI /memory slash handler (cli_commands_mixin._handle_memory_command) passed self.agent._memory_store straight through, which is None when the command runs without a live agent — e.g. /memory approve from the Desktop GUI. The shared write-approval handler then returns "memory store unavailable" and applies nothing, even with built-in memory enabled and pending writes present. Fall back to a freshly loaded on-disk MemoryStore when no live store is available, mirroring the gateway path (gateway/slash_commands.py). It persists to the same MEMORY/USER.md and creates MEMORY.md on the first approved write. Fixes #46783 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(memory): honor configured char limits in the no-agent on-disk store Follow-up to the /memory approve fresh-store fix. Both the CLI fallback and the messaging-gateway handler built a bare MemoryStore() with the hardcoded default char limits (2200/1375), ignoring the user's configured memory.memory_char_limit / user_char_limit. A live agent honors those overrides (agent/agent_init.py), so an approval applied without a live agent could accept a write the user's lower cap would reject, or vice versa. Extract a shared tools.memory_tool.load_on_disk_store() factory that reads the configured limits (falling back to defaults if config can't load) and wire both the CLI and gateway handlers to it, closing the gap on both surfaces and de-duplicating the construction block. * fix(gateway): redact credentials from TUI approval prompts (#48456) Follow-up to #50767, which redacted the chat-platform (_approval_notify_sync) and SSE/API (_approval_notify) approval transports. The TUI JSON-RPC transport is the third egress and was missed: three register_gateway_notify callbacks in tui_gateway/server.py emitted the raw approval_data — including the unredacted command Tirith flagged — straight to the TUI client via _emit. Route all three registrations through a new module-level _emit_approval_request() helper that redacts payload['command'] via the shared gateway.run._redact_approval_command seam before emitting, matching the pattern used for the other two transports. Completes the whole-bug-class fix for #48456. Tests: assert the helper emits a redacted command (real credential pattern), handles missing/None command, and a wiring guard that no registration emits the raw payload directly (only the helper may). Both mutation-checked. The #48456 fix series originated from @liuhao1024's #48462 — credit to them for the original report and chat-platform fix; this completes the remaining transport. Co-authored-by: liuhao1024 <sunsky.lau@gmail.com> * fix(file_tools): resolve tilde using profile home for file operations (#48552) File tools (read_file, write_file, patch, list_directory, etc.) used os.path.expanduser() which reads the gateway process HOME env var. In Docker/systemd/s6 deployments where the gateway HOME differs from interactive sessions, tilde expanded to the wrong directory. Add _expand_tilde() helper that delegates to get_subprocess_home() when available, falling back to os.path.expanduser(). Replace all 9 expanduser() call sites in file_tools.py with _expand_tilde(). * fix(cron): scope job execution to its owning profile (#32091 follow-up) (#50993) The #32091 fix moved every profile's cron jobs into one shared root store, but never wired the execution-scoping half it recommended: a job still ran under whichever profile's ticker picked it up, not its owning profile. So a job created under `hermes -p donna` could execute with the root profile's .env / config.yaml / credentials. - jobs.py: create_job auto-captures the active profile (explicit profile= override available) and stores it on the job; resolve_profile_home() maps a profile name to its HERMES_HOME; legacy jobs backfill to 'default'. - scheduler.py: run_job applies the job's profile via a scoped HERMES_HOME override (env var + in-process ContextVar) before any .env/config/script load, restored in finally. tick() routes profile-mismatched jobs to the single-worker sequential pool so the env mutation can't race. - cronjob tool threads profile through (NOT exposed in the model schema, to avoid cross-profile privilege escalation); hermes cron add gains --profile. E2E verified against a temp HERMES_HOME with a real profile dir: a root-profile ticker runs a profile='donna' job with HERMES_HOME=donna during execution and restores the ticker env afterward. * feat(background-review): aux-model selector for the self-improvement review (#49252) Adds auxiliary.background_review.{provider,model} (default auto = main chat model — unchanged). Set it to a different, cheaper model and the post-turn self-improvement review runs there for ~3-5x lower cost. Cache-aware by design: the main chat is warm in the prompt cache, so the default full-history replay on the main model is cheap cache reads — left exactly as-is. A different model can't reuse that cache (different key), so when (and only when) routed to a different model the fork replays a compact digest instead of the full transcript, minimising what it cold-writes on the aux model. Same model -> full replay; different model -> digest. Quality holds in benchmarks: memory capture identical, skill near-identical. Nothing changes unless you opt in by naming a different model. Co-authored-by: Hermes Agent <noreply@nousresearch.com> * feat(computer-use): surface macOS permission preflight in the desktop Computer Use already worked through the desktop backend (the cua-driver toolset enables + installs via Settings -> Skills & Tools), but there was no in-app way to see or grant the two macOS permissions it needs, so "give a model my Mac" was tribal knowledge. The grants attach to cua-driver's OWN TCC identity (com.trycua.driver / the installed CuaDriver.app), not Hermes -- so no app entitlement is involved. cua-driver 0.5+ exposes `permissions status/grant`, which we wrap: - tools/computer_use/permissions.py: thin client over the two subcommands - hermes computer-use permissions {status,grant}: CLI parity - GET /api/tools/computer-use/status, POST .../permissions/grant: desktop REST - ComputerUsePanel: live Accessibility + Screen Recording state with a Grant button (dialog attributed to CuaDriver), shown in the expanded Computer Use toolset row. Binary install stays in the existing provider post-setup runner. Follow-ups: i18n the card copy; a "Stop driver" control (cua-driver stop) for the runaway-`serve` case. * fix(computer-use): vision capture returns an image on cua-driver >=0.5.x Vision mode called a `screenshot` MCP tool that cua-driver dropped in 0.5.x (full-window PNG capture was folded into `get_window_state`). The driver replied "Unknown tool: screenshot", so `images` came back empty, `png_b64` stayed None, and capture returned a 0x0 result with no image on every call. `som`/`ax` were unaffected because they already use `get_window_state`, which masked the regression. Route vision by capability: - driver advertises `screenshot` (older builds) -> use it (no AX walk) - otherwise -> call `get_window_state` but discard the AX tree/elements, returning only the PNG so vision stays free of element noise - capabilities not yet discovered -> try `screenshot`, fall back to `get_window_state` on an empty image, so the path self-heals Add `_image_from_tool_result` to pull the PNG from either an MCP image content-part or `structuredContent.screenshot_png_b64`, and use it on the som path too so the image won't silently drop on driver builds that deliver it via structuredContent instead of a content part. Verified live (vision: 1568x954, 0 elements; som: image + 527 elements) and with unit coverage of all four routing cases. * feat(computer-use): make the preflight cross-platform (win/linux) The card was macOS-only. cua-driver also runs on Windows and Linux, so fold `cua-driver doctor` (cross-platform binary/health probes) into a single OS-aware `ready` signal: - macOS: ready == both TCC grants; keeps the permission rows + grant flow. - Windows/Linux: no TCC toggles, so ready == driver health, with a per-OS note (SmartScreen/UIAccess on Windows; X11/XWayland on Linux). `computer_use_status()` replaces the macOS-only `permissions_status()` and surfaces `platform`, `ready`, `can_grant`, and the doctor `checks` (non-ok ones render as warnings). CLI `permissions status`, the REST endpoint, and the desktop card all key off the one payload. Grant stays macOS-only (400 elsewhere — nothing to grant). * fix(computer-use): set stdin=DEVNULL on cua-driver subprocess calls The subprocess-stdin guard (TUI gateway fd-inheritance protection) flagged the `permissions grant` call. None of the cua-driver probes/grant read stdin, so DEVNULL is correct; apply it to the shared `_run` helper and the grant call. * fix(desktop): avoid stack overflow on embedded image replay Replace the giant embedded-image regex with a bounded scanner so opening sessions with multi-megabyte data URLs does not crash the renderer. * fix(agent): shrink anthropic-native image history Retry image-size rejections by rewriting Anthropic base64 image source blocks, not just OpenAI-style image_url parts. * feat(desktop): add timeline rail for long chat threads Adds a compact right-edge prompt timeline for long desktop chat sessions, with hover previews, click-to-jump, active/hover row states, and pane hover-reveal suppression so the rail can live at the hard edge without opening side panels. * feat(memory): Honcho OAuth connect — desktop and CLI flows + token refresh (#44335) * feat(memory): OAuth token storage and refresh for the Honcho provider * feat(memory): refresh the Honcho OAuth token in the client and session * feat(memory): zero-CLI loopback OAuth authorization flow * feat(memory): generic memory-provider OAuth connect endpoints * feat(desktop): memory-provider OAuth connect link * feat(memory): CLI OAuth sign-in with source-tagged authorize links * fix(memory): IP-literal loopback redirect and consent config_path on the authorize link * fix(memory): profile-scope the memory-provider OAuth endpoints * refactor(desktop): generic memory-provider OAuth client functions * docs(memory): trim OAuth module docstrings to the invariants * docs(memory): document OAuth connect as an optional auth method * fix(memory): send home-relative display path to consent, not the absolute path * perf(memory): cache OAuth token expiry in memory to skip the hot-path disk read * fix(memory): log OAuth refresh failures at warning, not debug * feat(memory): fall back to an OS-assigned loopback port when 8765 is taken * test(memory): cover the desktop Connect launcher, status, and provider dispatch * fix(desktop): keep the memory-provider dropdown one size regardless of connect state * fix(desktop): move the memory connect link to the description line, leaving the dropdown untouched * refactor(memory): move OAuth connect routes out of web_server into a memory-layer router * refactor(desktop): import MemoryConnect directly, drop the single-export barrel * fix(memory): launch CLI OAuth sign-in right after the auth choice, not after the wizard * fix(desktop): auto-clear the OAuth error state instead of leaving it sticky * test(honcho): isolate auth-method prompt from deployment-shape wizard tests main's wizard suite scripts the cloud prompts without the OAuth auth-method step; auto-answer it in the shared helper so the answer lists stay shape-only. * docs(honcho): document query-adaptive reasoning level (reasoningHeuristic) README never mentioned reasoningHeuristic and listed reasoningLevelCap as an orphaned cap with the wrong default (— vs "high"). Add the query-adaptive scaling note + the reasoningHeuristic/reasoningLevelCap rows (grouped under Dialectic & Reasoning), matching the wording already on the hosted honcho.md page, and add a pointer from the memory-providers overview. * fix(honcho): default the CLI peer prompt to the OAuth consent name The CLI runs the grant with apply_config=False, so the peerName the user just entered at consent was dropped and the wizard's 'Your name' prompt fell back to $USER. Surface it as a transient OAuthCredential.consent_peer_name (set even when config isn't merged) and seed the prompt default from it. * feat(honcho): split OAuth client_id by surface (cli=hermes-agent, desktop=hermes-desktop) resolve_endpoints now picks the client_id from the initiating surface and threads it through authorize -> token exchange -> persisted grant -> refresh, so the CLI and desktop register as distinct OAuth clients. Surface-specific env overrides (HONCHO_OAUTH_CLIENT_ID_CLI/_DESKTOP) win over the generic HONCHO_OAUTH_CLIENT_ID, which still overrides every surface. * feat(honcho): show OAuth vs API key in status; detect existing OAuth in setup status now prints 'Auth: OAuth (clientId, token valid Xm/expired)' instead of masking the OAuth access token as a generic API key; setup notes an existing OAuth grant when re-run. * docs(honcho): drop 'shared pool' wording from unified observation mode help * fix(honcho): cross-process lock around OAuth refresh to prevent grant revocation The in-process threading lock can't stop a sibling process (another profile or the desktop app sharing honcho.json) from replaying the single-use refresh token and tripping reuse-detection, which revokes the whole grant. Guard the read-refresh-persist section with an OS file lock on <config>.lock so only one process rotates at a time; the others re-read the freshly-persisted token. Best-effort: platforms without flock degrade to in-process serialization. * refactor(honcho): one OAuth client (hermes-agent) for all surfaces Collapse the per-surface client_id split. CLI and desktop now use a single client_id (hermes-agent); consent branding/UI still adapt via the source query param. One grant identity means no clientId-vs-refresh-token desync that could get the grant revoked. HONCHO_OAUTH_CLIENT_ID still overrides for self-hosting. * fix(honcho): per-session resolves to session_id, never remapped by title Reorder resolve_session_name so stable identifiers win over labels: gateway per-chat key first, then the per-session session_id, then the cwd map / title. A (possibly auto-generated) title can no longer remap a live per-session conversation onto a second Honcho session mid-stream — fixes the desktop, which is per-conversation via session_id. Consequence: a gateway's per-chat key now also wins over a title (titles never remap a stable id). * fix(desktop): stop auto-opening tool previews Drop gateway-event preview registration so HTML artifacts from tool results no longer pop the rail. De-dupe the inline preview card label. * feat(desktop): detect tool previews into composer status stack Register previewable artifacts from the tool row, feed a session-scoped store, and render compact rows above the composer. Remove the inline preview card. * fix(desktop): toggle preview rail and open in browser Status row opens/closes the preview pane; external link uses a dedicated file:// browser bridge (openExternal, not openPath). * style(desktop): soften inline code and expanded tool chrome Drop the inline-code border; halve the expanded tool block radius. * revert(cron): return cron job storage to per-profile (reverts #32117 + #50993) (#51116) * Revert "fix(cron): scope job execution to its owning profile (#32091 follow-up) (#50993)" This reverts commit 660e36f097e8bc0c2dc2a9e22d203eb6a9d9361c. * Revert "fix(cron): anchor cron storage at the default root home (not the active profile)" This reverts commit a5c09fd176627cce350ef1b30dcd8528f9e7c775. * feat(agent): expose coding-context project facts as structured data + project.facts RPC (#51259) Follow-up to the coding-context posture (#43316): that PR detects each repo's verify loop (manifests, package manager, exact test/lint/build commands, context files) and bakes it into the system-prompt snapshot — but only as a string, for the model. Non-prompt consumers (the desktop verify UI) had no way to read it without re-sniffing and drifting from the prompt. Split detection from rendering, keeping one source of truth: - `detect_project_facts(root) -> ProjectFacts` (frozen) holds the structured facts; `_project_facts()` now renders it into the same snapshot lines, so the prompt block stays byte-identical (cache-safe). - `project_facts_for(cwd)` resolves the workspace root (git, else marker) and returns the structured facts, or None outside a workspace. - `project.facts` gateway RPC surfaces it to any client (desktop/TUI/ACP). Tests assert the structured output and that the UI-facing commands never drift from what the prompt block renders (one detector feeds both). * feat(agent): one-shot LLM helper + llm.oneshot gateway RPC (#51261) A "one-shot" is a single stateless model call that runs OUTSIDE any conversation: it never touches session history, never breaks prompt caching, and returns plain text. UI surfaces need this for small generative chores — a commit message from a diff, a rename suggestion, a summary — where an agent turn would pollute the thread and hand-rolling an LLM call at every call site would be worse. - `agent/oneshot.py`: `run_oneshot(...)` over the existing auxiliary-client plumbing (same path as title generation). Two call shapes: explicit instructions/input, or a registered `template` + `variables` (templates own the prompt engineering so it stays consistent across CLI/TUI/desktop). Ships a `commit_message` template. Model selection inherits the live session via `main_runtime`, else the configured aux `task` backend. - `tui_gateway/server.py`: `llm.oneshot` RPC (long-handler) inheriting the session's model when `session_id` resolves. Stateless by construction — no session mutation, cache untouched. * feat(relay): declare relevance policy to the connector + document the management plane (#51248) The gateway half of Phase 6 Unit ζ: project the agent's existing relevance knobs into the connector's platform-agnostic vocabulary and declare them at boot over the /relay/policy route, so the SAME mention-gating / free-response / allow-bots behavior the agent applies directly also governs relay delivery (and excluded chatter never wakes a scaled-to-zero agent). - gateway/relay/__init__.py: - relay_relevance_policy(): project require_mention -> requireAddress, free_response_channels -> freeResponseScopes, {PLATFORM}_ALLOW_BOTS in {mentions,all} -> allowOtherBots. Reads the fronted platform's config block + bridged top-level keys. Returns None when all-default (the connector's quiet default already matches) or no concrete platform is fronted. - send_relay_policy(): POST /relay/policy authenticated with the gateway's own per-gateway upgrade token (make_upgrade_token — same bearer as the WS upgrade), so the connector attaches it to the authenticated instance, never a body-asserted id. Re-declares every boot (self-healing, full replace). NEVER raises, NEVER blocks boot — relevance is an optimization layered on the δ/ε authorization gate. Reuses the per-gateway secret + the /relay/provision host; no new inbound surface, no new credential. - _policy_url(): ws(s)://…/relay -> http(s)://…/relay/policy. - gateway/run.py: call send_relay_policy() after register_relay_adapter() succeeds (the secret is resolved by then). - docs/relay-connector-contract.md: new §7 documenting per-instance delivery + the management plane (/manage/* + /relay/policy) + the relevance-declaration contract; versioning renumbered to §8. Contract conformance test stays green (§2/§3 tables untouched). Tests: +12 (projection mapping incl. comma-string + top-level fallback; send auth/skip/fail-soft/non-200). Full relay suite 118 pass. The connector route is already E2E-proven (connector repo gateway_policy_driver.py); this adds the real gateway send-path it pairs with. This completes Phase 6 (Team Gateway per-user isolation) end to end. * fix(slack): transcribe in-app voice messages (audio/mp4) instead of failing Slack in-app voice clips ("record a clip") arrive as MP4/AAC containers (mimetype audio/mp4, filename audio_message*.mp4), and Slack sometimes labels them video/mp4. The inbound audio handler derived the cache extension from the mimetype and fell back to ".ogg" for anything not in {.ogg,.mp3,.wav,.webm,.m4a} — so audio/mp4 voice messages were cached as .ogg. OpenAI STT (whisper-1, gpt-4o-transcribe) sniffs the container from the FILENAME extension, so it received MP4 bytes named .ogg and rejected them. WhatsApp .ogg and uploaded .m4a worked only because their extension happened to match the bytes. Fix: - _resolve_slack_audio_ext(): pick the cache extension from the real filename first, then a mimetype map (audio/mp4 -> .m4a), defaulting to .m4a — never the bogus .ogg fallback. Mirrors the video branch and the audio map already in gateway/platforms/bluebubbles.py. - _is_slack_voice_clip(): detect audio-only clips mislabeled video/mp4 via the slack_audio subtype / audio_message* filename, and route them through the audio path (cached as audio, reported as audio/*) so they reach STT instead of video understanding. Genuine videos (and slack_video screen recordings) are left on the video path. Verified end-to-end against a real audio-only MP4: old path cached it as .ogg (ffprobe shows MP4 bytes -> container mismatch -> OpenAI rejects); new path caches it as .mp4 (extension matches bytes -> accepted). Adds inbound-audio tests (previously none): helper unit tests plus _handle_slack_message E2E coverage for audio/mp4, video/mp4-mislabeled voice clips, and a real video staying on the video path. Confirmed the two voice-message tests fail without the fix (mutation check). * fix(slack): report ext-matched audio mimetype for rerouted voice clips Follow-up to the salvaged voice-clip fix: the rerouted video/mp4 branch used {".m4a": "audio/mp4"}.get(ext, "audio/mp4"), whose sole key's value equals the default, so it always returned "audio/mp4" regardless of the cached extension (dead lookup + a throwaway dict per inbound voice clip). Replace it with a module-level _SLACK_EXT_TO_AUDIO_MIME map so the reported media_type matches the bytes we cached (e.g. a clip cached as .wav now reports audio/wav instead of audio/mp4). STT routing already keys on the audio/ prefix + cached filename extension, so behavior is unchanged; this just removes the dead construct and keeps the reported mimetype coherent. * docs(computer-use): document Windows UIPI elevated-window limitation (#51121) A Medium-integrity Hermes agent cannot drive High-integrity (admin) windows on Windows — UIPI blocks UIA enumeration and mouse injection (SOM returns 0 elements, clicks silently no-op, screenshots still work, keyboard partially bypasses). OS constraint affecting every Windows automation stack, not a cua-driver bug. Document the symptom + the run-elevated workaround. Closes #49067. * ci: run only the lanes a PR affects (python/frontend/site) Heavy PR checks run on every PR because the workflows deliberately avoid `on.paths` filters — a path-gated workflow leaves its required check pending forever when no matching file changes, blocking merge. So a docs-only PR still spins up the TypeScript matrix, the full Python suite, and ruff/ty. Keep every workflow triggering on every PR (checks always report) but gate the expensive *steps* on what the PR touches. Skipping a step (not the job) leaves the job green, so required checks never hang — the same idiom already proven in contributor-check.yml. A classifier (scripts/ci/classify_changes.py) maps the PR diff to three lanes — python, frontend, site — surfaced as step outputs by a composite action (.github/actions/detect-changes). Fail-open: an empty diff or any .github/ change runs everything; python is a denylist (skipped only when every file is provably prose or a frontend-only package); skills/**/SKILL.md counts as python-relevant since the skill-doc tests read that tree. Non-PR events always run the full pipeline. * ci: build Docker on main + release only, never on PRs The image build + smoke test + integration suite are the heaviest jobs in CI (~9-11 min) and ran on every PR. Gate them to push-to-main and release: a broken build surfaces on the main push, while the cheap pre-merge guards (docker-lint hadolint/shellcheck, uv-lockfile-check) still run on PRs to catch the common Dockerfile/lockfile breakage. Steps skip on PRs so the job stays green; the dead PR-only arm64 cache-warm build is removed. * ci: make dependency installs resilient to transient flakes `npm ci` / `uv sync` / toolchain header fetches occasionally die on transient network blips — e.g. node-pty's node-gyp fetching Node headers (an undici assert) during the typecheck job's `npm ci`, which killed the job before `tsc` ever ran. "Re-run and it goes green" is exactly what CI should do itself. - New reusable `.github/actions/retry` composite action wraps a command and retries on failure (3x / 10s, command passed via env so it can't inject). Applied to every PR-path network install: npm ci (typecheck, desktop build, docs site), uv sync (tests, e2e), uv tool install (lint), pip install (docs site). - typecheck now runs `npm ci --ignore-scripts`: `tsc` needs only sources + type defs, so skipping install scripts drops node-pty's native rebuild (whose header fetch was the flake) and is faster. Validated locally — tsc passes for ui-tui, apps/shared, and apps/desktop with scripts skipped. - ripgrep download uses `curl --retry`. Docker (main-only) and the release/windows workflows are intentionally left for a follow-up. * ci: refactor paths & clones ci: centralize path-gating behind single orchestrator + all-checks-pass gate Replace the scattered per-workflow detect-changes pattern with a single ci.yml orchestrator that runs the classifier once, then conditionally calls sub-workflows via workflow_call based on lane outputs. A final all-checks-pass job (if: always()) aggregates all results so branch protection only needs to require one check. Changes: - New .github/workflows/ci.yml orchestrator (detect + conditional calls + all-checks-pass gate) - Extend classify_changes.py with scan/deps/mcp_catalog lanes, absorbing supply-chain-audit's internal changes job - Update detect-changes/action.yml to expose the new lane outputs - Convert all 10 PR-gated sub-workflows to workflow_call-only triggers, removing their push/pull_request triggers and per-step detect-changes guards (gating now happens at the orchestrator level) - lint.yml + supply-chain-audit.yml receive event_name as a workflow_call input to replace github.event_name (which is "workflow_call" inside called workflows) - supply-chain-audit.yml: remove internal changes job + *-gate jobs (orchestrator handles gating, booleans arrive as inputs) - contributor-check.yml: remove internal filter step - Update test_classify_changes.py for 6-lane output + new supply-chain test cases * ci: remove unused windows installer job * fix(ci): only run supplychain checks in pr * fix(desktop): replace native title tooltips with styled Tip component * fix(ci): classify should default to no MCP * fix(install): drop system-browser fallback + auto-repair stale snap override The installer scanned PATH/well-known locations for a Chrome/Chromium binary and, when found, skipped the bundled Playwright Chromium download and wrote that path into ~/.hermes/.env as AGENT_BROWSER_EXECUTABLE_PATH. On Snap-based systems `command -v chromium` resolves to /snap/bin/chromium, whose sandbox blocks agent-browser's control socket under /tmp -- so every browser_navigate hung until the 60s timeout fired ("opening web page failed"). Drop the system-browser fallback entirely (per maintainer direction): find_system_browser()/Find-SystemBrowser now honor ONLY an explicit, user-set AGENT_BROWSER_EXECUTABLE_PATH override -- no PATH scan, no well-known-path scan. A /snap/* path is rejected even when set explicitly, since its confinement is the bug. Applied to both install.sh (Linux/macOS) and install.ps1 (Windows). Crucially, also auto-repair already-affected installs: the bad snap path persists in .env and is read directly by the runtime, and the installer skips re-config when AGENT_BROWSER_EXECUTABLE_PATH is already set ("already configured"), so a plain reinstall/update never recovered an existing user. New strip_snap_browser_override() removes a snap-pointing AGENT_BROWSER_EXECUTABLE_PATH (and its auto-written comment) from .env on every install/update, run from both browser-setup paths (install_node_deps and ensure_browser), so updating is enough to recover. A deliberately-set non-snap override is left untouched. docker/stage2-hook.sh is intentionally untouched: it discovers the bundled Playwright Chromium, not a system browser. * test(install): assert no system-browser auto-detect + snap override repair Replace the old "skips download when a system browser exists" assertions with tests for the new behavior: - no PATH scan for browser command names, and the "use the system browser" path is gone; - find_system_browser consults only an explicit AGENT_BROWSER_EXECUTABLE_PATH override (which still skips the bundled download); - strip_snap_browser_override runs on both install paths and a /snap/* path is rejected, so already-affected installs auto-recover on update. * feat(discord): render reasoning as -# subtext via display.reasoning_style (#51168) Adds a per-platform display.reasoning_style setting (code | blockquote | subtext) controlling how the show_reasoning summary renders on the gateway. Discord defaults to "subtext" (-# small grey metadata text); every other platform keeps the fenced code block. Resolves through the existing display.platforms.<platform>.reasoning_style override chain. * feat(cli): track background subagents in the status bar (#51441) The classic prompt_toolkit status bar already shows two background indicators: ▶ N (/background agent threads) and ⚙ N (shell processes spawned by terminal(background=true)). Background/async subagents (delegate_task batches and background single delegations) had no indicator despite being long-running work the user should be able to see at a glance. Add a third indicator ⛓ N sourced from tools.async_delegation.active_count() — the count of delegations still in the 'running' state. Renders in the plain-text builder and the styled-fragment builder across the same width tiers as the other two (omitted on the narrow <52 tier), guarded so a raising active_count() leaves the snapshot at 0. * feat(slack): add --no-assistant flag to manifest generation By default `hermes slack manifest` opts the app into Slack's AI Assistant container (assistant_view feature + assistant:write scope + assistant_thread_* events). Slack then renders DMs as the right-hand Assistant split-pane, where every exchange is a thread and bare slash commands (/help, /new, ...) are not delivered as normal command events — they only work when the bot is @mentioned. There was no way to opt out short of hand-editing the generated JSON. Add --no-assistant to emit a flat-DM manifest that omits those three pieces, so DMs render as a normal chat and slash commands dispatch inline. The regular messaging surface (Messages tab, slash commands, Socket Mode, channel + DM scopes/events) is preserved in both modes. Default behaviour is unchanged (assistant mode still on). Tests: cover both manifest modes and the argparse wiring. * feat(tui): track background subagents in the status bar (#51485) Parity with the classic CLI status bar's ⛓ indicator (PR #51441). The Ink TUI status bar now shows ⛓ N for live background/async subagents (delegate_task batches + background single delegations). - tui_gateway/server.py: _get_usage() embeds active_subagents from tools.async_delegation.active_count() — the same registry the CLI reads — onto the existing per-update usage payload, guarded so a raising active_count() leaves the field off without breaking usage. - ui-tui appChrome: new 'subagents' status segment (breakpoint w>=92, slots between bg and cost in the shed-order), renders ⛓ N from usage.active_subagents. - Usage / SessionUsageResponse types gain active_subagents?. Distinct from the turn-scoped SpawnHud / /agents overlay, which mirror live in-turn subagent.* events; this is the persistent registry count. * feat: add reasoning_effort support to ollama-cloud provider Map Hermes xhigh→max to unlock DeepSeek V4's 'Max thinking' tier through Ollama Cloud's OpenAI-compatible /v1/chat/completions endpoint. low/medium/high pass through unchanged; disabled/none suppress reasoning entirely. Empirically confirmed: reasoning_effort:max produces ~2.5× more thinking tokens than high on deepseek-v4-pro:cloud (1576 vs 642). * chore: add s010mn to AUTHOR_MAP for PR #29221 salvage * fix(mcp): skip killpg when child shares gateway's process group (#47134) /reload-mcp -> shutdown_mcp_servers -> _kill_orphaned_mcp_children(include_active=True) -> _send_signal -> killpg(pgid, SIGTERM). When a tracked MCP stdio child shares the gateway's OWN process group, killpg delivers SIGTERM to the gateway itself, firing its SIGTERM handler -> os._exit(0): /reload-mcp crashes the gateway. Pre-compute the gateway's own pgid (os.getpgrp(), None on Windows/restricted) and, in _send_signal, skip killpg when pgid == own pgid, falling through to the per-pid os.kill path so the child is still reaped without self-signaling. Adds a regression test (folded in) that pins the guard: with a tracked pgid equal to the gateway's own pgid, killpg is never called for that pgid and the per-pid kill fallback is used. Mutation-checked. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * fix(tui): preserve live session identity across compression (#49041) When a session rotates id on compression, _sync_session_key_after_compress() re-anchored the session_key, approval-notify routing, yolo state, and slash worker — but never moved the active-session lease, which stayed keyed to the pre-compression id. And _find_live_session_by_key() matched live sessions on the stale session_key, not the live agent's current agent.session_id. After compression a resume/create path failed to recognize the existing live agent and could build a SECOND live agent against the same DB continuation -> forked lineage / cross-session message mixing. - active_sessions.transfer_active_session(): move a lease in place to the new id under the exclusive file lock (no slot drop). - gateway _transfer_active_session_slot(): call it inside _sync_session_key_after_compress(); on the rare fallback (entry pruned) RESERVE the new slot before releasing the old lease (reserve-before-release), so a concurrent gateway at the session cap cannot grab the freed slot in a release-then-reacquire window and leave this session with no lease; if the reserve fails, keep the existing lease (review fix). - _session_lookup_key(): make live-session lookup authoritative on agent.session_id, wired into all stale-session_key consumers (_find_live_session_by_key, _session_live_item, _live_session_payload) — fixes the whole lookup class. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * fix(telegram): wire platform_httpx_limits into general-pool HTTPXRequest (#31599) PTB's HTTPXRequest builds its httpx.AsyncClient with `limits = httpx.Limits(max_connections=connection_pool_size)` and no keepalive tuning, so httpx's default keepalive_expiry=5.0 applies. Behind an HTTP proxy (Cloudflare Warp etc.) a peer-initiated FIN can sit in CLOSE_WAIT longer than that, leaking fds in the general request pool (_request[1], which routes bot.send_message/set_my_commands) — the pool _drain_polling_connections never resets. Telegram was the lone holdout adapter not using the shared #18451 CLOSE_WAIT helper. Wire gateway.platforms._http_client_limits.platform_httpx_limits() into the httpx client across ALL THREE request-construction branches — fallback-transport, proxy, and plain — via httpx_kwargs["limits"], which PTB spreads last into its client kwargs so our tuned limits win. PTB's connection_pool_size (max_connections) is preserved; only keepalive behaviour is tightened (max_keepalive_connections + keepalive_expiry<5.0). The fix is macOS-import-safe: no Linux-only socket TCP_KEEPIDLE/INTVL/CNT constants at module scope (unlike the broken candidate which crashed on import on the reporter's OS), and it patches the actual proxy path the repro hits rather than TelegramFallbackTransport, which the proxy repro never instantiates. Adds a mutation-survivable behavior-contract test asserting every HTTPXRequest built by connect() receives httpx_kwargs["limits"] with keepalive_expiry < httpx's 5.0 default, across both the proxy and plain branches. Reverting the limits wiring fails the test. Co-authored-by: indigokarasu <mx.indigo.karasu@gmail.com> * fix(agent): persist tool calls before turn-end flush Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * feat(skills): /learn — distill a reusable skill from anything you describe (#51506) Open-ended skill learning across every surface. /learn <free text> takes a description of any source — a directory, a URL, the workflow you just walked the agent through, or pasted notes — and the live agent gathers it with the tools it already has (read_file/search_files, web_extract, the conversation, the pasted text), then authors a SKILL.md via skill_manage following the house authoring standards (<=60-char description, the standard section order, Hermes-tool framing, no invented commands). No engine, no model-tool footprint, works on any terminal backend (local, Docker, remote): /learn builds a standards-guided prompt and hands it to the agent as a normal turn. - agent/learn_prompt.py: shared standards-guided prompt builder - /learn registry entry (both surfaces) + CLI handler (inject onto input queue) + gateway handler (rewrite turn, fall through, /blueprint pattern) - tui_gateway command.dispatch returns a send directive -> TUI + dashboard chat - dashboard Skills page 'Learn a skill' panel (dir + URL + open-ended text) composes a /learn request and runs it in chat - docs (slash-commands ref + skills feature page), 11 targeted tests Inspired by OpenAI Codex's Record & Replay and the /learn concept from #47234 (dir-distillation engine); reworked to be open-ended and engine-free per review. * fix(agent): handle concurrent tool submit shutdown * fix(gateway): preserve _session_tasks on guard mismatch to enable stale lock healing (#48300) _session_task_is_stale() failed to detect a stale session lock when the owner task completed and cleaned _session_tasks (del in _process_message_background's finally) but _active_sessions was NOT released because _release_session_guard skipped on a guard mismatch (a concurrent reset/new command or drain handoff swapped _active_sessions[key] to a different guard). With no owner task left to inspect, _session_task_is_stale reported 'not stale', the orphaned guard was never healed, and the session deadlocked permanently — later messages received but never dispatched. Reorder the finally cleanup to release-then-conditional-delete: release the guard first, then drop the _session_tasks entry ONLY if the guard was actually released (session_key no longer in _active_sessions). On a guard mismatch the done-task entry survives, so the on-entry self-heal (_session_task_is_stale -> _heal_stale_session_lock) detects the stale lock and clears it on the next inbound message. Extracted the cleanup into a callable _cleanup_finished_session_task() helper so the regression test drives the REAL production code path rather than a copy of its logic (the original test inlined the fixed logic and passed regardless of the production order — mutation-verified the rewritten tests now fail on the buggy del-first order). Added a positive-path test (guard matches -> release + delete) so both branches are pinned. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * chore(release): map manusjs email to manus-use GitHub login Required by contributor-check/check-attribution before salvaging PR #51129 (Discord thread-starter dedup, #51057). The CI step greps AUTHOR_MAP by exact email and does not special-case noreply addresses. * fix(gateway): prevent double dispatch of Discord messages via thread-starter dedup When _auto_create_thread() creates a thread from a user message via message.create_thread(), Discord fires a second MESSAGE_CREATE event for the 'thread starter message'. That starter message carries message.id == thread.id and may arrive with type=default instead of type=21 (thread_starter_message), so the existing type filter in on_message does not catch it — triggering a second call into _handle_message and thus a second agent run and response. Fix: after _auto_create_thread succeeds and returns a thread, pre-seed the dedup cach…

…esearch#43316) * feat(agent): coding-context posture with per-model edit-format tuning Hermes detects when it's running in a coding context — an interactive surface (CLI, TUI, ACP, desktop) sitting in a code workspace (git repo or recognised project root) — and shifts into a coding posture. Outside that (chat platforms, non-workspaces) nothing changes. The posture is modelled as a frozen RuntimeMode selected from a small ContextProfile registry (coding/general). A profile is data: the toolset to collapse to, the operating brief to inject, and seams for model routing and memory. Every domain reads the same resolved object instead of re-probing git/config on its own: - System prompt — RuntimeMode.system_blocks(): an operating brief (gather context before editing, edit through tools not chat, verify with terminal, cap retry loops) plus a live git/workspace snapshot, built once and baked into the stable prompt tier so per-conversation caching is preserved. - Per-model edit-format tuning — the brief nudges each model family toward the patch mode it handles best: OpenAI/Codex toward mode='patch' (V4A multi-file diffs), Anthropic toward mode='replace' (string replacement). The model id rides on RuntimeMode; unknown families keep neutral wording. - Skill index — non-coding skill categories are pruned from the prompt's skill index (discovery-only; skills_list/skill_view still reach the full catalog, with a disclosure note). - Toolset — only under the opt-in 'focus' mode does the posture collapse to the coding toolset + enabled MCP servers; the default posture is prompt-only and never overrides configured toolsets. Activation via agent.coding_context: auto (default), focus, on, off. Subagents inherit the posture for free via toolset inheritance + the shared prompt builder. Detection is not memoized so a long-lived gateway/TUI process can't pin a stale posture across working directories. * feat(agent): cover new-file authoring in the coding edit-format nudge The per-model edit-format guidance only addressed editing existing code (patch mode='patch' vs 'replace'), but authoring a brand-new file — write_file, not patch — is a large fraction of real coding work and the nudge was silent on it. Surfaced when building a single-file artifact where the dominant operation was write_file and the steering offered no guidance. Both family lines now lead with "author new files with write_file; for edits to existing code prefer ...". Tests assert write_file appears in each family's brief; unknown families still get neutral wording. * docs(agent): correct memoization docstring + clarify TUI config-load asymmetry * feat(agent): sharpen the coding posture — verify-loop facts, wider edit steering, $HOME guard Tuning pass on the coding posture from dogfooding it as a harness: - Workspace snapshot now hands the model its verify loop up front: detected manifests + package manager (lockfile sniff), the exact verify commands (package.json scripts, Makefile targets, scripts/run_tests.sh, pytest config), and which context files (AGENTS.md / CLAUDE.md / .cursorrules) exist at the root. Marker-only (non-git) projects get the snapshot too instead of nothing. The "verify before claiming done" brief line was the highest-value piece in evals — this turns it from advice into an executable loop instead of making the model rediscover the test command every session. Still stat-cheap, size-guarded reads, built once at prompt time. - Edit-format steering covers the families Hermes actually serves: Gemini and open-weight coding models (DeepSeek, Qwen, Kimi, GLM, Grok, Hermes, Llama, Mistral, Devstral, MiniMax) steer to mode='replace' — their RL scaffolds use str_replace-style editors. Previously only GPT/Codex and Claude families got steering; the models Hermes users disproportionately run all fell to neutral. - Operating brief gains four behaviors elite harnesses encode: batch independent reads/searches in one turn; fix root causes and the bug class (sibling call paths), not the reported site; no drive-by refactors/renames/reformatting; never read, print, or commit secrets. Plus a patch-failure escalation ladder: after the same region fails twice, rewrite the enclosing function/file with write_file instead of a third patch attempt. - $HOME dotfiles guard: a git repo rooted exactly at the home directory (or a marker sitting in it, e.g. a global ~/AGENTS.md) is user config, not a code workspace — without the guard, every session anywhere under a dotfiles-managed home silently flipped to the coding posture. Real projects under such a home still detect via their own markers/repos; 'on' mode bypasses the guard.

* feat(pets): pet engine + display.pet config Add the shared pet engine under agent/pet/: spritesheet manifest loading and in-process caching, six-state animation model, frame rendering, and the persistent pet store. Register the display.pet config block (pet, scale, enabled, etc.) that every surface reads from. Covered by tests/agent/test_pet_engine.py. * feat(pets): CLI pet pane + /pet command Render the reactive pet pane in the classic CLI (steady redraw, right-aligned) and wire the /pet command to list and switch pets, plus an enable/disable toggle. Backed by hermes_cli/pets.py and the CLI commands mixin, registered in the central command registry. Covered by the CLI pet pane and toggle tests. * feat(pets): TUI pet pane, picker + gateway RPCs Add the Ink pet sprite pane, the interactive /pet picker overlay, and live pet switching/rescale driven by new tui_gateway RPCs (pet state, pet.scale, per-state frames). Wires pet flash state and the picker into the TUI layout and slash handler. Covered by the slash-handler test. * feat(desktop): floating pet, pop-out overlay + Cmd+K picker Add the in-window floating pet (sprite, speech bubble, contact shadow, profile-scoped, resize-safe) and a pop-out always-on-top overlay window with gestures and notifications. Add the Cmd+K pet picker page plus the appearance gallery and size slider in settings. Includes the pet stores, electron overlay wiring, i18n strings, and store tests. * docs(pets): feature guide, petdex skill + catalog Add the pets feature guide and the petdex skill (SKILL.md + bundled doc), and register them in the website sidebar and skills catalog. * fix(desktop): portal floating composer to body so it can't be clipped off-screen The popped-out composer is position:fixed, but the chat content wrapper sets `contain: layout paint`, which makes it a containing block for — and clips — fixed descendants. Inline, the floating composer was positioned/clipped relative to the chat column (which shifts with the sidebars), not the viewport, so the viewport-based bounds clamp from #50466 couldn't keep it reachable: users still lost it off-screen. Portal it to <body> when popped out so fixed positioning and the clamp finally share the viewport as their reference. Docked stays inline (it's absolute within the chat column by design). * fix(desktop): move composer out of contain wrapper instead of portaling Replaces the body-portal approach: render ChatBar as a sibling of the contain:[layout paint] chat wrapper (inside the same runtime boundary) rather than portaling the floating instance to <body>. The wrapper is a containing block for — and clips — position:fixed descendants, which is what stranded the popped-out composer off-screen. As a sibling it anchors to the outer relative container: docked stays absolute (identical placement), floating resolves against the viewport. Both states stay mounted, so dock<->float no longer remounts the editor (the portal toggle did). * fix(desktop): clamp floating composer to the thread area, not the whole window Now that the popped-out composer is fixed to the viewport, clamping against the window let it slide under a pinned sidebar. Confine it to the thread region (data-slot="composer-bounds") instead — its rect already excludes a pinned sidebar and the header — falling back to the full window before it's measured. This subsumes the old titlebar top-margin (the thread rect starts below the header). * fix(desktop): guarantee out-of-bounds composer is reclamped on load Re-clamp once more on the next frame after pop-out so layout (sidebar widths, fonts) has settled, and treat a degenerate pre-layout bounds rect as "unknown" (fall back to the window) so we never clamp the box into a collapsed area. Net: anyone who loads in with a stranded position is pulled back on-screen and the fix is persisted, even if the first measure was premature. * feat(skills): add cloudflare-temporary-deploy optional skill (#50849) * chore: re-trigger CI (workflows did not dispatch on prior head) * feat(skills): add cloudflare-temporary-deploy optional skill Optional web-development skill teaching the agent to deploy a Worker to a live workers.dev URL with no Cloudflare account via 'wrangler deploy --temporary' (Wrangler 4.102.0+). Cloudflare provisions a throwaway, claimable account valid for 60 minutes — ideal for an autonomous write->deploy->verify loop with no OAuth/signup hard stop. - SKILL.md: when/when-not, prereqs (unauth requirement, version floor), step-by-step deploy + verify flow, product limits table, pitfalls (hidden flag, stale global wrangler, auth-present error, rate limits, workers.dev edge cache), verification. - scripts/parse_deploy_output.py: stdlib-only parser extracting live URL, claim URL, account name/state, expiry, deploy status from wrangler output. - tests/skills/test_cloudflare_temporary_deploy_skill.py: 16 tests incl. a real-output regression case. Verified live end-to-end: temporary account created with no creds, deployed to a live URL, curl confirmed body, redeploy reused the account. * feat(goals): completion contracts for /goal — evidence-based judging (#50501) Adds an optional structured completion contract to the standing-goal loop, adapted from OpenAI Codex's /goal guidance (a durable objective works best when it names what done means, how to prove it, what not to break, what's in scope, and when to stop). A contract has five optional fields — outcome, verification, constraints, boundaries, stop_when. When set, the continuation prompt tells the agent to target the verification surface and respect constraints, and the judge marks the goal done only when the verification criterion is met with concrete evidence (command result, file excerpt, test output) instead of a loose "looks done" claim. This tightens the most common /goal failure mode: premature completion / endless over-continuation on an underspecified goal. Two ways to set a contract, both backward compatible (bare /goal <text> behaves exactly as before): - /goal draft <objective> — expands plain text into a full contract via the goal_judge aux model (cache-safe side call), falls back to a free-form goal if the model is unavailable. - /goal <text> with inline 'field: value' lines (verify:, constraints:, boundaries:, stop when:, ...). Plain goals with an incidental colon are not mangled — only known field prefixes are pulled out. - /goal show prints the active contract. Contracts persist in SessionDB.state_meta alongside the goal (survive /resume), compose with /subgoal criteria, and old goal rows load unchanged. CLI + every gateway platform via the shared GoalManager engine; zero new model tools. Tests: +18 in tests/hermes_cli/test_goals.py (parse/serialize/judge-prompt/ draft/fallback), 73/73 green; 42/42 across the broader goal test surface; live E2E roundtrip (set -> persist -> reload -> contract-aware prompts) green. * fix(computer-use): route CuaDriver vision capture via get_window_state cua-driver 0.6.x removed the standalone screenshot MCP tool, so capture(mode='vision') hit 'Unknown tool: screenshot' and returned a 0x0 image with no PNG while som/ax (which use get_window_state) still worked. Route vision through get_window_state(capture_mode='vision'). Salvaged from PR #50771; same fix submitted earlier as #39262 by @Tranquil-Flow. * feat(computer-use): add whole-screen/desktop capture target capture(app='screen'|'desktop') now resolves to the OS shell/desktop window (Windows Progman/WorkerW desktop or Shell_TrayWnd taskbar, macOS Finder/Dock) so 'show me my screen' and 'click the taskbar' work. Previously capture() only matched application windows, and the schema advertised 'or the whole screen' without any code path delivering it. cua-driver is window-oriented (no virtual-desktop or per-monitor MCP tool), so a single image still cannot span multiple monitors — the schema now states this and the no-desktop-window path returns a clear message instead of silently grabbing the frontmost app. * hermes_state: add SessionDB.delete_telegram_topic_binding (#31501) Targeted ``(chat_id, thread_id)`` prune for the ``telegram_dm_topic_bindings`` table — the missing piece for #31501, where the Telegram adapter detects a topic the user deleted out-of-band but the binding row keeps living in state.db. The recovery logic in ``gateway.run._recover_telegram_topic_thread_id`` then steers every future inbound message back to the dead topic, dropping tool progress, approvals and replies into the wrong place. Returns the number of rows deleted; silently no-ops when the topic-mode tables haven't been migrated yet (read-only / pristine profile) so the helper is safe to call from a send-fallback hot path before the schema has run. * gateway/telegram: prune stale DM topic binding on Thread-not-found (#31501) Both fallback sites that currently log "Thread X not found, retrying without message_thread_id" now also drop the ``telegram_dm_topic_bindings`` row keyed on ``(chat_id, thread_id)``: * The streaming send loop (``send`` body) — fires on the second failure, after the same-thread one-shot retry confirms the thread really is gone (the first attempt is left alone because Bot API has been observed to return a transient "Thread not found" that recovers on immediate retry). * The control-message helper ``_send_message_with_thread_fallback`` (approval prompts, model picker, update prompts) — single-shot retry, prune unconditionally on the BadRequest match. Without this prune, a user who deletes a Telegram DM topic in the client keeps getting their next inbound message recovered back to the dead thread by ``_recover_telegram_topic_thread_id`` in ``gateway/run.py``, which walks the per-user binding list newest-first and treats the deleted thread as authoritative. The reproduction in the bug report is exactly this: tool progress, approvals, activity messages and replies all land in the wrong place until the user manually runs DELETE on state.db. Cleanup is best-effort — we log at INFO when it succeeds, swallow any exception from the SessionDB call, and the user-facing send proceeds either way. Refs #31501 * tests: regression coverage for stale topic-binding prune (#31501) Thirteen tests across four layers: * ``SessionDB.delete_telegram_topic_binding`` — pin the new helper's contract: removes only the (chat_id, thread_id) row it was asked about, leaves siblings alone, returns 0 silently when the row never existed, and is a no-op on a pristine database whose topic-mode tables haven't been migrated yet. * ``TelegramAdapter._prune_stale_dm_topic_binding`` — the glue must drop the binding when ``self._session_store._db`` exposes the helper, swallow exceptions so a failed cleanup never breaks the user-facing send, and refuse to issue a DELETE for ``chat_id=None`` / ``thread_id=None`` so a bookkeeping miss can't accidentally null-match every row. * Source-level guards on ``TelegramAdapter.send`` and ``_send_message_with_thread_fallback`` — the prune call must sit beside the two existing "Thread X not found, retrying without message_thread_id" warnings, before the retry runs, so a future refactor can't silently drop the cleanup wire. * End-to-end semantic — once a topic is pruned, the ``GatewayRunner._recover_telegram_topic_thread_id`` walk steers future inbound messages to the surviving binding instead of the dead one. This is the exact behaviour change the bug report's reproduction asks for: no more landings in the wrong topic until the operator hand-edits ``state.db``. Refs #31501 * fix(telegram): disable DM topic mode when last binding is pruned Follow-up to #31501. When the send-fallback prune removes a chat's final telegram_dm_topic_bindings row, also flip telegram_dm_topic_mode.enabled to 0 in the same transaction. Without this, a user who turns topics off in the Telegram client (rather than via /topic off) leaves enabled=1 with zero lanes: _recover_telegram_topic_thread_id keeps treating the chat as topic-enabled and lobby messages keep hunting for bindings that no longer exist. Clearing the flag makes recovery fully stand down once the dead topics are gone. Adds 3 regression tests covering the last-binding clear, the multi-binding no-op, and the unmatched-prune no-op. * fix(api): allow dashboard updates for git checkouts in containers (#51005) Salvages #50469 by @libre-7. _dashboard_local_update_managed_externally() previously blocked every containerized dashboard from the local update API, even when the running install was a bind-mounted git checkout that can be updated with hermes update. Allow the dashboard updater only for git installs inside containers, while keeping hosted /opt/data, docker, and pip installs managed externally. Pip remains blocked because its apply path mutates the running container filesystem and is not the self-managed checkout case. Adds regression coverage for docker, git, and pip install-method handling inside containers, and maps the contributor email for release attribution. Co-authored-by: libre-7 <libre-7@users.noreply.github.com> * fix(model_switch): route typed configured models off openai-codex (#45006) A typed `/model <name>` where `<name>` is declared under `providers.<slug>` or `custom_providers` — but typed while the current provider is a soft-accepting one (e.g. `openai-codex`) — stayed on the current provider and was swallowed as an unknown hidden Codex model, instead of routing to the provider that actually declares it. Add configured-provider exact-match detection (`_configured_provider_matches`) and a new Step d.5 in `switch_model`: if the typed model is declared in user/custom provider config, route to that provider BEFORE `detect_provider_for_model()` guesses from static catalogs and BEFORE the common-path validation lets a soft-accepting current provider swallow the name. - Matching is exact (case-insensitive) against explicitly-declared model collections only (`models`, `model`, `default_model`) — never fuzzy/family. - Same-provider declarer → keep current provider (canonicalize the id). - Multiple declarers → fail clearly and ask for `--provider <slug>`. - Single declarer → route there; for `providers.<slug>` user providers, set `explicit_provider` so the credential block resolves base_url/key from config. - Step e (`detect_provider_for_model`) is gated off when `config_routed`. The deliberately-supported openai-codex / xai-oauth hidden-model soft-accept (#16172 / #19729) is left untouched: when nothing in config matches, detection is a no-op. Salvaged from #45442 by harjothkhara (authorship preserved). Tests: tests/hermes_cli/test_model_switch_configured_provider_routing.py (7 tests). Full model_switch suite: 214 passed. Fixes #45006 * fix(image/video gen): make schema delivery instruction platform-neutral (#51031) * chore: re-trigger CI (workflows did not dispatch on prior head) * fix(image/video gen): make schema delivery instruction platform-neutral The image_generate and video_generate tool schema descriptions hardcoded a gateway-only delivery instruction ('display it with markdown ![description](url-or-path) and the gateway will deliver it'). That schema is sent on every platform, so on CLI it directly contradicted the CLI platform hint ('Do NOT emit MEDIA:/path tags ... state its absolute path in plain text'), and on messaging platforms it was also wrong about the mechanism (local file paths are delivered via MEDIA: tags, not markdown image syntax — markdown ![]() only works for URLs). The per-platform file-delivery convention is already owned correctly by the platform hints in prompt_builder.py. The tool schema now just describes the result shape (URL or absolute path in the image/video field) and defers 'how to deliver' to the active platform's guidance. Provider/model injection already works via _build_dynamic_image_schema() (the 'Active backend: <provider> · model: <model>' line); no change there. * fix(computer-use): delete broken pre-install asset probe; trust the upstream installer `hermes computer-use install` refused to install on Linux, Windows, and macOS x86_64 because the pre-install asset probe was hitting the wrong GitHub endpoint AND duplicating tag-resolution logic the upstream installer already does correctly. `_check_cua_driver_asset_for_arch()` queried `https://api.github.com/repos/trycua/cua/releases/latest`. On trycua/cua: - cua-driver-rs releases (the binary the installer fetches) are marked **prerelease** on every cut. GitHub's `/releases/latest` explicitly skips prereleases. - The Python package releases (`cua-agent`, `cua-computer`, `cua-train`) are non-prerelease and end up as the "latest" instead. Live API check today: $ curl -sf https://api.github.com/repos/trycua/cua/releases/latest \ | jq '{tag:.tag_name, asset_count: (.assets|length)}' { "tag": "agent-v0.8.3", "asset_count": 0 } The probe sees zero assets, prints "Latest CUA release has no Linux x86_64 asset", and skips install on every Linux / Windows / macOS-x86_64 host — even though the cua-driver-rs-v0.6.0 release ships 19 binary assets covering all those platforms. Filtering `/releases?per_page=N` for the `cua-driver-rs-v*` prefix fixes the bug, but it duplicates tag-resolution logic the upstream `_install-rust.sh` already does correctly via `CUA_DRIVER_RS_BAKED_VERSION` (auto-baked by CD on every release, with a `/releases?per_page=N` API fallback for dev checkouts). The right answer is to trust that contract instead of mirroring it in Python where it can drift. Two paths get the same outcome without the probe: 1. **Fresh install**: run `install.sh` directly. It has the baked release tag, fetches the right asset, and errors with a clear message on missing-arch downloads. No preflight needed. 2. **Upgrade path**: `cua_driver_update_check()` (separately added) shells `cua-driver check-update --json` against the installed binary, which returns the canonical update answer from the same source the installer uses. - `hermes_cli/tools_config.py`: delete `_check_cua_driver_asset_for_arch` and its two call sites in `install_cua_driver`. Replace with an inline comment near the top of the module explaining the rationale. - `tests/hermes_cli/test_install_cua_driver.py`: drop the `TestCheckCuaDriverAssetForArch` block. Add `TestArchProbeRemoval` with three regressions: - `test_probe_function_is_gone` — asserts the deleted helpers stay deleted. - `test_fresh_install_does_not_call_github_api` — asserts the install path doesn't hit GitHub directly from Python anymore. - `test_upgrade_with_binary_does_not_call_github_api_directly` — same for the upgrade path. All 9 `test_install_cua_driver` tests pass. Reported by @teknium1 while testing on a headed Ubuntu host. * fix(tests): update cua install tests for cross-platform support f-trycua's #50855 test file predated the cross-platform PR (#50552) and reintroduced two stale tests asserting Linux is unsupported (test_*_non_macos_*, patching platform.system="Linux" and expecting a no-op/warn). Linux + Windows are supported now, so install proceeds on those platforms. Restore main's cross-platform-correct versions: test_*_on_unsupported_platform_* using FreeBSD as the genuinely unsupported case. * fix(agent): complete final text on last turn * fix(cron): deliver max-iteration fallback reports * test(discord): add regression test for 100-command sync limit Add a test to verify that _safe_sync_slash_commands deletes obsolete commands before creating new ones. This ensures we never temporarily exceed Discord's 100-command limit during sync, which would trigger error 30032 and break all slash commands. This test guards against the regression where sync could fail even though the registration cap was properly enforced. * fix(discord): delete obsolete slash commands before creating new ones Discord enforces a hard 100-command limit per app and rejects an upsert that would push the live total over 100 (error 30032), which silently breaks ALL slash commands. The sync deleted obsolete commands AFTER creating new ones, so an app already at the cap momentarily exceeded it and the whole sync failed. Reorder: delete no-longer-desired commands up front, then create/update. Removes the now-redundant trailing delete loop. Adapts @infinitycrew39 PR #50890 to current main (the original adapter diff no longer applied after the platform refactor); test commit cherry-picked with authorship preserved. * fix(cron): fail closed when an unpinned job's provider drifts from creation snapshot (#44585) An unpinned cron job follows the global default provider (config.yaml model.default + resolve_runtime_provider). If that global state is changed after the job is created — e.g. a temporary switch to a paid provider like nous/claude-fable-5 — the job silently inherits it on its next tick and spends real money. This is the reported $7.73 incident: a job created under a free/default provider later inherited a temporary paid switch. Fix (ask #1 only) preserves the legitimate "unpinned job should follow model.default" use case by detecting *drift* rather than freezing the model: - create_job (cron/jobs.py): for UNPINNED, agent-backed jobs (no explicit provider, not no_agent), snapshot the provider that resolution WOULD pick right now into a new optional `provider_snapshot` field, resolved via the same resolve_runtime_provider() path the ticker uses. Fail-open to None on any resolution error so job creation never breaks. - run_job (cron/scheduler.py): right after runtime resolution, if the job has a provider_snapshot AND is unpinned AND the currently-resolved provider DIFFERS from the snapshot, fail closed for that run — make no paid call and deliver a loud, actionable alert naming both providers and telling the user to pin explicitly (`cronjob action=update job_id=.. provider=..`). Back-compat: jobs with no snapshot (pre-existing jobs, no_agent jobs, or any job whose creation-time resolution failed) behave exactly as before — the guard only engages when a snapshot exists. Explicitly-pinned jobs (job.provider set) are unaffected since they don't drift with global state. Tests: tests/cron/test_cron_provider_pin.py covers snapshot-matches (runs), snapshot-differs (fail closed, no agent constructed), no-snapshot back-compat, None-snapshot back-compat, explicitly-pinned (runs regardless), plus create_job snapshot capture/skip/fail-open. The fail-closed case is load-bearing (fails without the guard). Issue #44585 asks #2-4 (hard-stop a running job, gateway-stop containment, fail-closed on provider mutation) are out of scope for this change. * fix(security): deny root-level credential stores in media delivery The media-delivery denylist in gateway/platforms/base.py enumerated only .env/auth.json/credentials/config.yaml under HERMES_HOME, so other credential stores that live at the root fell through and could be auto-attached to chat replies. The reported case: the Google Workspace skill's google_token.json refreshes every turn, bumping its mtime to 'now', which kept passing the strict-mode recency window and re-sent the OAuth token on every reply. Extend the explicit per-file denylist to mirror the canonical credential set already enforced by the read/write guards in agent/file_safety.py: google_token.json, google_oauth_pending.json, auth/google_oauth.json, .anthropic_oauth.json, webhook_subscriptions.json, cache/bws_cache.json, auth.lock, and the pairing/ token directory. Targeted per-file additions (not a blanket ~/.hermes deny, which was declined in #32090/#34425 because it would block skills/, logs/, and ad-hoc agent-written deliverables). mcp-tokens/ (#37222) and state.db/kanban.db (#41071) are left to their sibling targeted PRs. Reported-by: xxxigm (#50912) * fix(memory): apply /memory approve against a fresh store when no live agent The CLI /memory slash handler (cli_commands_mixin._handle_memory_command) passed self.agent._memory_store straight through, which is None when the command runs without a live agent — e.g. /memory approve from the Desktop GUI. The shared write-approval handler then returns "memory store unavailable" and applies nothing, even with built-in memory enabled and pending writes present. Fall back to a freshly loaded on-disk MemoryStore when no live store is available, mirroring the gateway path (gateway/slash_commands.py). It persists to the same MEMORY/USER.md and creates MEMORY.md on the first approved write. Fixes #46783 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(memory): honor configured char limits in the no-agent on-disk store Follow-up to the /memory approve fresh-store fix. Both the CLI fallback and the messaging-gateway handler built a bare MemoryStore() with the hardcoded default char limits (2200/1375), ignoring the user's configured memory.memory_char_limit / user_char_limit. A live agent honors those overrides (agent/agent_init.py), so an approval applied without a live agent could accept a write the user's lower cap would reject, or vice versa. Extract a shared tools.memory_tool.load_on_disk_store() factory that reads the configured limits (falling back to defaults if config can't load) and wire both the CLI and gateway handlers to it, closing the gap on both surfaces and de-duplicating the construction block. * fix(gateway): redact credentials from TUI approval prompts (#48456) Follow-up to #50767, which redacted the chat-platform (_approval_notify_sync) and SSE/API (_approval_notify) approval transports. The TUI JSON-RPC transport is the third egress and was missed: three register_gateway_notify callbacks in tui_gateway/server.py emitted the raw approval_data — including the unredacted command Tirith flagged — straight to the TUI client via _emit. Route all three registrations through a new module-level _emit_approval_request() helper that redacts payload['command'] via the shared gateway.run._redact_approval_command seam before emitting, matching the pattern used for the other two transports. Completes the whole-bug-class fix for #48456. Tests: assert the helper emits a redacted command (real credential pattern), handles missing/None command, and a wiring guard that no registration emits the raw payload directly (only the helper may). Both mutation-checked. The #48456 fix series originated from @liuhao1024's #48462 — credit to them for the original report and chat-platform fix; this completes the remaining transport. Co-authored-by: liuhao1024 <sunsky.lau@gmail.com> * fix(file_tools): resolve tilde using profile home for file operations (#48552) File tools (read_file, write_file, patch, list_directory, etc.) used os.path.expanduser() which reads the gateway process HOME env var. In Docker/systemd/s6 deployments where the gateway HOME differs from interactive sessions, tilde expanded to the wrong directory. Add _expand_tilde() helper that delegates to get_subprocess_home() when available, falling back to os.path.expanduser(). Replace all 9 expanduser() call sites in file_tools.py with _expand_tilde(). * fix(cron): scope job execution to its owning profile (#32091 follow-up) (#50993) The #32091 fix moved every profile's cron jobs into one shared root store, but never wired the execution-scoping half it recommended: a job still ran under whichever profile's ticker picked it up, not its owning profile. So a job created under `hermes -p donna` could execute with the root profile's .env / config.yaml / credentials. - jobs.py: create_job auto-captures the active profile (explicit profile= override available) and stores it on the job; resolve_profile_home() maps a profile name to its HERMES_HOME; legacy jobs backfill to 'default'. - scheduler.py: run_job applies the job's profile via a scoped HERMES_HOME override (env var + in-process ContextVar) before any .env/config/script load, restored in finally. tick() routes profile-mismatched jobs to the single-worker sequential pool so the env mutation can't race. - cronjob tool threads profile through (NOT exposed in the model schema, to avoid cross-profile privilege escalation); hermes cron add gains --profile. E2E verified against a temp HERMES_HOME with a real profile dir: a root-profile ticker runs a profile='donna' job with HERMES_HOME=donna during execution and restores the ticker env afterward. * feat(background-review): aux-model selector for the self-improvement review (#49252) Adds auxiliary.background_review.{provider,model} (default auto = main chat model — unchanged). Set it to a different, cheaper model and the post-turn self-improvement review runs there for ~3-5x lower cost. Cache-aware by design: the main chat is warm in the prompt cache, so the default full-history replay on the main model is cheap cache reads — left exactly as-is. A different model can't reuse that cache (different key), so when (and only when) routed to a different model the fork replays a compact digest instead of the full transcript, minimising what it cold-writes on the aux model. Same model -> full replay; different model -> digest. Quality holds in benchmarks: memory capture identical, skill near-identical. Nothing changes unless you opt in by naming a different model. Co-authored-by: Hermes Agent <noreply@nousresearch.com> * feat(computer-use): surface macOS permission preflight in the desktop Computer Use already worked through the desktop backend (the cua-driver toolset enables + installs via Settings -> Skills & Tools), but there was no in-app way to see or grant the two macOS permissions it needs, so "give a model my Mac" was tribal knowledge. The grants attach to cua-driver's OWN TCC identity (com.trycua.driver / the installed CuaDriver.app), not Hermes -- so no app entitlement is involved. cua-driver 0.5+ exposes `permissions status/grant`, which we wrap: - tools/computer_use/permissions.py: thin client over the two subcommands - hermes computer-use permissions {status,grant}: CLI parity - GET /api/tools/computer-use/status, POST .../permissions/grant: desktop REST - ComputerUsePanel: live Accessibility + Screen Recording state with a Grant button (dialog attributed to CuaDriver), shown in the expanded Computer Use toolset row. Binary install stays in the existing provider post-setup runner. Follow-ups: i18n the card copy; a "Stop driver" control (cua-driver stop) for the runaway-`serve` case. * fix(computer-use): vision capture returns an image on cua-driver >=0.5.x Vision mode called a `screenshot` MCP tool that cua-driver dropped in 0.5.x (full-window PNG capture was folded into `get_window_state`). The driver replied "Unknown tool: screenshot", so `images` came back empty, `png_b64` stayed None, and capture returned a 0x0 result with no image on every call. `som`/`ax` were unaffected because they already use `get_window_state`, which masked the regression. Route vision by capability: - driver advertises `screenshot` (older builds) -> use it (no AX walk) - otherwise -> call `get_window_state` but discard the AX tree/elements, returning only the PNG so vision stays free of element noise - capabilities not yet discovered -> try `screenshot`, fall back to `get_window_state` on an empty image, so the path self-heals Add `_image_from_tool_result` to pull the PNG from either an MCP image content-part or `structuredContent.screenshot_png_b64`, and use it on the som path too so the image won't silently drop on driver builds that deliver it via structuredContent instead of a content part. Verified live (vision: 1568x954, 0 elements; som: image + 527 elements) and with unit coverage of all four routing cases. * feat(computer-use): make the preflight cross-platform (win/linux) The card was macOS-only. cua-driver also runs on Windows and Linux, so fold `cua-driver doctor` (cross-platform binary/health probes) into a single OS-aware `ready` signal: - macOS: ready == both TCC grants; keeps the permission rows + grant flow. - Windows/Linux: no TCC toggles, so ready == driver health, with a per-OS note (SmartScreen/UIAccess on Windows; X11/XWayland on Linux). `computer_use_status()` replaces the macOS-only `permissions_status()` and surfaces `platform`, `ready`, `can_grant`, and the doctor `checks` (non-ok ones render as warnings). CLI `permissions status`, the REST endpoint, and the desktop card all key off the one payload. Grant stays macOS-only (400 elsewhere — nothing to grant). * fix(computer-use): set stdin=DEVNULL on cua-driver subprocess calls The subprocess-stdin guard (TUI gateway fd-inheritance protection) flagged the `permissions grant` call. None of the cua-driver probes/grant read stdin, so DEVNULL is correct; apply it to the shared `_run` helper and the grant call. * fix(desktop): avoid stack overflow on embedded image replay Replace the giant embedded-image regex with a bounded scanner so opening sessions with multi-megabyte data URLs does not crash the renderer. * fix(agent): shrink anthropic-native image history Retry image-size rejections by rewriting Anthropic base64 image source blocks, not just OpenAI-style image_url parts. * feat(desktop): add timeline rail for long chat threads Adds a compact right-edge prompt timeline for long desktop chat sessions, with hover previews, click-to-jump, active/hover row states, and pane hover-reveal suppression so the rail can live at the hard edge without opening side panels. * feat(memory): Honcho OAuth connect — desktop and CLI flows + token refresh (#44335) * feat(memory): OAuth token storage and refresh for the Honcho provider * feat(memory): refresh the Honcho OAuth token in the client and session * feat(memory): zero-CLI loopback OAuth authorization flow * feat(memory): generic memory-provider OAuth connect endpoints * feat(desktop): memory-provider OAuth connect link * feat(memory): CLI OAuth sign-in with source-tagged authorize links * fix(memory): IP-literal loopback redirect and consent config_path on the authorize link * fix(memory): profile-scope the memory-provider OAuth endpoints * refactor(desktop): generic memory-provider OAuth client functions * docs(memory): trim OAuth module docstrings to the invariants * docs(memory): document OAuth connect as an optional auth method * fix(memory): send home-relative display path to consent, not the absolute path * perf(memory): cache OAuth token expiry in memory to skip the hot-path disk read * fix(memory): log OAuth refresh failures at warning, not debug * feat(memory): fall back to an OS-assigned loopback port when 8765 is taken * test(memory): cover the desktop Connect launcher, status, and provider dispatch * fix(desktop): keep the memory-provider dropdown one size regardless of connect state * fix(desktop): move the memory connect link to the description line, leaving the dropdown untouched * refactor(memory): move OAuth connect routes out of web_server into a memory-layer router * refactor(desktop): import MemoryConnect directly, drop the single-export barrel * fix(memory): launch CLI OAuth sign-in right after the auth choice, not after the wizard * fix(desktop): auto-clear the OAuth error state instead of leaving it sticky * test(honcho): isolate auth-method prompt from deployment-shape wizard tests main's wizard suite scripts the cloud prompts without the OAuth auth-method step; auto-answer it in the shared helper so the answer lists stay shape-only. * docs(honcho): document query-adaptive reasoning level (reasoningHeuristic) README never mentioned reasoningHeuristic and listed reasoningLevelCap as an orphaned cap with the wrong default (— vs "high"). Add the query-adaptive scaling note + the reasoningHeuristic/reasoningLevelCap rows (grouped under Dialectic & Reasoning), matching the wording already on the hosted honcho.md page, and add a pointer from the memory-providers overview. * fix(honcho): default the CLI peer prompt to the OAuth consent name The CLI runs the grant with apply_config=False, so the peerName the user just entered at consent was dropped and the wizard's 'Your name' prompt fell back to $USER. Surface it as a transient OAuthCredential.consent_peer_name (set even when config isn't merged) and seed the prompt default from it. * feat(honcho): split OAuth client_id by surface (cli=hermes-agent, desktop=hermes-desktop) resolve_endpoints now picks the client_id from the initiating surface and threads it through authorize -> token exchange -> persisted grant -> refresh, so the CLI and desktop register as distinct OAuth clients. Surface-specific env overrides (HONCHO_OAUTH_CLIENT_ID_CLI/_DESKTOP) win over the generic HONCHO_OAUTH_CLIENT_ID, which still overrides every surface. * feat(honcho): show OAuth vs API key in status; detect existing OAuth in setup status now prints 'Auth: OAuth (clientId, token valid Xm/expired)' instead of masking the OAuth access token as a generic API key; setup notes an existing OAuth grant when re-run. * docs(honcho): drop 'shared pool' wording from unified observation mode help * fix(honcho): cross-process lock around OAuth refresh to prevent grant revocation The in-process threading lock can't stop a sibling process (another profile or the desktop app sharing honcho.json) from replaying the single-use refresh token and tripping reuse-detection, which revokes the whole grant. Guard the read-refresh-persist section with an OS file lock on <config>.lock so only one process rotates at a time; the others re-read the freshly-persisted token. Best-effort: platforms without flock degrade to in-process serialization. * refactor(honcho): one OAuth client (hermes-agent) for all surfaces Collapse the per-surface client_id split. CLI and desktop now use a single client_id (hermes-agent); consent branding/UI still adapt via the source query param. One grant identity means no clientId-vs-refresh-token desync that could get the grant revoked. HONCHO_OAUTH_CLIENT_ID still overrides for self-hosting. * fix(honcho): per-session resolves to session_id, never remapped by title Reorder resolve_session_name so stable identifiers win over labels: gateway per-chat key first, then the per-session session_id, then the cwd map / title. A (possibly auto-generated) title can no longer remap a live per-session conversation onto a second Honcho session mid-stream — fixes the desktop, which is per-conversation via session_id. Consequence: a gateway's per-chat key now also wins over a title (titles never remap a stable id). * fix(desktop): stop auto-opening tool previews Drop gateway-event preview registration so HTML artifacts from tool results no longer pop the rail. De-dupe the inline preview card label. * feat(desktop): detect tool previews into composer status stack Register previewable artifacts from the tool row, feed a session-scoped store, and render compact rows above the composer. Remove the inline preview card. * fix(desktop): toggle preview rail and open in browser Status row opens/closes the preview pane; external link uses a dedicated file:// browser bridge (openExternal, not openPath). * style(desktop): soften inline code and expanded tool chrome Drop the inline-code border; halve the expanded tool block radius. * revert(cron): return cron job storage to per-profile (reverts #32117 + #50993) (#51116) * Revert "fix(cron): scope job execution to its owning profile (#32091 follow-up) (#50993)" This reverts commit 660e36f097e8bc0c2dc2a9e22d203eb6a9d9361c. * Revert "fix(cron): anchor cron storage at the default root home (not the active profile)" This reverts commit a5c09fd176627cce350ef1b30dcd8528f9e7c775. * feat(agent): expose coding-context project facts as structured data + project.facts RPC (#51259) Follow-up to the coding-context posture (#43316): that PR detects each repo's verify loop (manifests, package manager, exact test/lint/build commands, context files) and bakes it into the system-prompt snapshot — but only as a string, for the model. Non-prompt consumers (the desktop verify UI) had no way to read it without re-sniffing and drifting from the prompt. Split detection from rendering, keeping one source of truth: - `detect_project_facts(root) -> ProjectFacts` (frozen) holds the structured facts; `_project_facts()` now renders it into the same snapshot lines, so the prompt block stays byte-identical (cache-safe). - `project_facts_for(cwd)` resolves the workspace root (git, else marker) and returns the structured facts, or None outside a workspace. - `project.facts` gateway RPC surfaces it to any client (desktop/TUI/ACP). Tests assert the structured output and that the UI-facing commands never drift from what the prompt block renders (one detector feeds both). * feat(agent): one-shot LLM helper + llm.oneshot gateway RPC (#51261) A "one-shot" is a single stateless model call that runs OUTSIDE any conversation: it never touches session history, never breaks prompt caching, and returns plain text. UI surfaces need this for small generative chores — a commit message from a diff, a rename suggestion, a summary — where an agent turn would pollute the thread and hand-rolling an LLM call at every call site would be worse. - `agent/oneshot.py`: `run_oneshot(...)` over the existing auxiliary-client plumbing (same path as title generation). Two call shapes: explicit instructions/input, or a registered `template` + `variables` (templates own the prompt engineering so it stays consistent across CLI/TUI/desktop). Ships a `commit_message` template. Model selection inherits the live session via `main_runtime`, else the configured aux `task` backend. - `tui_gateway/server.py`: `llm.oneshot` RPC (long-handler) inheriting the session's model when `session_id` resolves. Stateless by construction — no session mutation, cache untouched. * feat(relay): declare relevance policy to the connector + document the management plane (#51248) The gateway half of Phase 6 Unit ζ: project the agent's existing relevance knobs into the connector's platform-agnostic vocabulary and declare them at boot over the /relay/policy route, so the SAME mention-gating / free-response / allow-bots behavior the agent applies directly also governs relay delivery (and excluded chatter never wakes a scaled-to-zero agent). - gateway/relay/__init__.py: - relay_relevance_policy(): project require_mention -> requireAddress, free_response_channels -> freeResponseScopes, {PLATFORM}_ALLOW_BOTS in {mentions,all} -> allowOtherBots. Reads the fronted platform's config block + bridged top-level keys. Returns None when all-default (the connector's quiet default already matches) or no concrete platform is fronted. - send_relay_policy(): POST /relay/policy authenticated with the gateway's own per-gateway upgrade token (make_upgrade_token — same bearer as the WS upgrade), so the connector attaches it to the authenticated instance, never a body-asserted id. Re-declares every boot (self-healing, full replace). NEVER raises, NEVER blocks boot — relevance is an optimization layered on the δ/ε authorization gate. Reuses the per-gateway secret + the /relay/provision host; no new inbound surface, no new credential. - _policy_url(): ws(s)://…/relay -> http(s)://…/relay/policy. - gateway/run.py: call send_relay_policy() after register_relay_adapter() succeeds (the secret is resolved by then). - docs/relay-connector-contract.md: new §7 documenting per-instance delivery + the management plane (/manage/* + /relay/policy) + the relevance-declaration contract; versioning renumbered to §8. Contract conformance test stays green (§2/§3 tables untouched). Tests: +12 (projection mapping incl. comma-string + top-level fallback; send auth/skip/fail-soft/non-200). Full relay suite 118 pass. The connector route is already E2E-proven (connector repo gateway_policy_driver.py); this adds the real gateway send-path it pairs with. This completes Phase 6 (Team Gateway per-user isolation) end to end. * fix(slack): transcribe in-app voice messages (audio/mp4) instead of failing Slack in-app voice clips ("record a clip") arrive as MP4/AAC containers (mimetype audio/mp4, filename audio_message*.mp4), and Slack sometimes labels them video/mp4. The inbound audio handler derived the cache extension from the mimetype and fell back to ".ogg" for anything not in {.ogg,.mp3,.wav,.webm,.m4a} — so audio/mp4 voice messages were cached as .ogg. OpenAI STT (whisper-1, gpt-4o-transcribe) sniffs the container from the FILENAME extension, so it received MP4 bytes named .ogg and rejected them. WhatsApp .ogg and uploaded .m4a worked only because their extension happened to match the bytes. Fix: - _resolve_slack_audio_ext(): pick the cache extension from the real filename first, then a mimetype map (audio/mp4 -> .m4a), defaulting to .m4a — never the bogus .ogg fallback. Mirrors the video branch and the audio map already in gateway/platforms/bluebubbles.py. - _is_slack_voice_clip(): detect audio-only clips mislabeled video/mp4 via the slack_audio subtype / audio_message* filename, and route them through the audio path (cached as audio, reported as audio/*) so they reach STT instead of video understanding. Genuine videos (and slack_video screen recordings) are left on the video path. Verified end-to-end against a real audio-only MP4: old path cached it as .ogg (ffprobe shows MP4 bytes -> container mismatch -> OpenAI rejects); new path caches it as .mp4 (extension matches bytes -> accepted). Adds inbound-audio tests (previously none): helper unit tests plus _handle_slack_message E2E coverage for audio/mp4, video/mp4-mislabeled voice clips, and a real video staying on the video path. Confirmed the two voice-message tests fail without the fix (mutation check). * fix(slack): report ext-matched audio mimetype for rerouted voice clips Follow-up to the salvaged voice-clip fix: the rerouted video/mp4 branch used {".m4a": "audio/mp4"}.get(ext, "audio/mp4"), whose sole key's value equals the default, so it always returned "audio/mp4" regardless of the cached extension (dead lookup + a throwaway dict per inbound voice clip). Replace it with a module-level _SLACK_EXT_TO_AUDIO_MIME map so the reported media_type matches the bytes we cached (e.g. a clip cached as .wav now reports audio/wav instead of audio/mp4). STT routing already keys on the audio/ prefix + cached filename extension, so behavior is unchanged; this just removes the dead construct and keeps the reported mimetype coherent. * docs(computer-use): document Windows UIPI elevated-window limitation (#51121) A Medium-integrity Hermes agent cannot drive High-integrity (admin) windows on Windows — UIPI blocks UIA enumeration and mouse injection (SOM returns 0 elements, clicks silently no-op, screenshots still work, keyboard partially bypasses). OS constraint affecting every Windows automation stack, not a cua-driver bug. Document the symptom + the run-elevated workaround. Closes #49067. * ci: run only the lanes a PR affects (python/frontend/site) Heavy PR checks run on every PR because the workflows deliberately avoid `on.paths` filters — a path-gated workflow leaves its required check pending forever when no matching file changes, blocking merge. So a docs-only PR still spins up the TypeScript matrix, the full Python suite, and ruff/ty. Keep every workflow triggering on every PR (checks always report) but gate the expensive *steps* on what the PR touches. Skipping a step (not the job) leaves the job green, so required checks never hang — the same idiom already proven in contributor-check.yml. A classifier (scripts/ci/classify_changes.py) maps the PR diff to three lanes — python, frontend, site — surfaced as step outputs by a composite action (.github/actions/detect-changes). Fail-open: an empty diff or any .github/ change runs everything; python is a denylist (skipped only when every file is provably prose or a frontend-only package); skills/**/SKILL.md counts as python-relevant since the skill-doc tests read that tree. Non-PR events always run the full pipeline. * ci: build Docker on main + release only, never on PRs The image build + smoke test + integration suite are the heaviest jobs in CI (~9-11 min) and ran on every PR. Gate them to push-to-main and release: a broken build surfaces on the main push, while the cheap pre-merge guards (docker-lint hadolint/shellcheck, uv-lockfile-check) still run on PRs to catch the common Dockerfile/lockfile breakage. Steps skip on PRs so the job stays green; the dead PR-only arm64 cache-warm build is removed. * ci: make dependency installs resilient to transient flakes `npm ci` / `uv sync` / toolchain header fetches occasionally die on transient network blips — e.g. node-pty's node-gyp fetching Node headers (an undici assert) during the typecheck job's `npm ci`, which killed the job before `tsc` ever ran. "Re-run and it goes green" is exactly what CI should do itself. - New reusable `.github/actions/retry` composite action wraps a command and retries on failure (3x / 10s, command passed via env so it can't inject). Applied to every PR-path network install: npm ci (typecheck, desktop build, docs site), uv sync (tests, e2e), uv tool install (lint), pip install (docs site). - typecheck now runs `npm ci --ignore-scripts`: `tsc` needs only sources + type defs, so skipping install scripts drops node-pty's native rebuild (whose header fetch was the flake) and is faster. Validated locally — tsc passes for ui-tui, apps/shared, and apps/desktop with scripts skipped. - ripgrep download uses `curl --retry`. Docker (main-only) and the release/windows workflows are intentionally left for a follow-up. * ci: refactor paths & clones ci: centralize path-gating behind single orchestrator + all-checks-pass gate Replace the scattered per-workflow detect-changes pattern with a single ci.yml orchestrator that runs the classifier once, then conditionally calls sub-workflows via workflow_call based on lane outputs. A final all-checks-pass job (if: always()) aggregates all results so branch protection only needs to require one check. Changes: - New .github/workflows/ci.yml orchestrator (detect + conditional calls + all-checks-pass gate) - Extend classify_changes.py with scan/deps/mcp_catalog lanes, absorbing supply-chain-audit's internal changes job - Update detect-changes/action.yml to expose the new lane outputs - Convert all 10 PR-gated sub-workflows to workflow_call-only triggers, removing their push/pull_request triggers and per-step detect-changes guards (gating now happens at the orchestrator level) - lint.yml + supply-chain-audit.yml receive event_name as a workflow_call input to replace github.event_name (which is "workflow_call" inside called workflows) - supply-chain-audit.yml: remove internal changes job + *-gate jobs (orchestrator handles gating, booleans arrive as inputs) - contributor-check.yml: remove internal filter step - Update test_classify_changes.py for 6-lane output + new supply-chain test cases * ci: remove unused windows installer job * fix(ci): only run supplychain checks in pr * fix(desktop): replace native title tooltips with styled Tip component * fix(ci): classify should default to no MCP * fix(install): drop system-browser fallback + auto-repair stale snap override The installer scanned PATH/well-known locations for a Chrome/Chromium binary and, when found, skipped the bundled Playwright Chromium download and wrote that path into ~/.hermes/.env as AGENT_BROWSER_EXECUTABLE_PATH. On Snap-based systems `command -v chromium` resolves to /snap/bin/chromium, whose sandbox blocks agent-browser's control socket under /tmp -- so every browser_navigate hung until the 60s timeout fired ("opening web page failed"). Drop the system-browser fallback entirely (per maintainer direction): find_system_browser()/Find-SystemBrowser now honor ONLY an explicit, user-set AGENT_BROWSER_EXECUTABLE_PATH override -- no PATH scan, no well-known-path scan. A /snap/* path is rejected even when set explicitly, since its confinement is the bug. Applied to both install.sh (Linux/macOS) and install.ps1 (Windows). Crucially, also auto-repair already-affected installs: the bad snap path persists in .env and is read directly by the runtime, and the installer skips re-config when AGENT_BROWSER_EXECUTABLE_PATH is already set ("already configured"), so a plain reinstall/update never recovered an existing user. New strip_snap_browser_override() removes a snap-pointing AGENT_BROWSER_EXECUTABLE_PATH (and its auto-written comment) from .env on every install/update, run from both browser-setup paths (install_node_deps and ensure_browser), so updating is enough to recover. A deliberately-set non-snap override is left untouched. docker/stage2-hook.sh is intentionally untouched: it discovers the bundled Playwright Chromium, not a system browser. * test(install): assert no system-browser auto-detect + snap override repair Replace the old "skips download when a system browser exists" assertions with tests for the new behavior: - no PATH scan for browser command names, and the "use the system browser" path is gone; - find_system_browser consults only an explicit AGENT_BROWSER_EXECUTABLE_PATH override (which still skips the bundled download); - strip_snap_browser_override runs on both install paths and a /snap/* path is rejected, so already-affected installs auto-recover on update. * feat(discord): render reasoning as -# subtext via display.reasoning_style (#51168) Adds a per-platform display.reasoning_style setting (code | blockquote | subtext) controlling how the show_reasoning summary renders on the gateway. Discord defaults to "subtext" (-# small grey metadata text); every other platform keeps the fenced code block. Resolves through the existing display.platforms.<platform>.reasoning_style override chain. * feat(cli): track background subagents in the status bar (#51441) The classic prompt_toolkit status bar already shows two background indicators: ▶ N (/background agent threads) and ⚙ N (shell processes spawned by terminal(background=true)). Background/async subagents (delegate_task batches and background single delegations) had no indicator despite being long-running work the user should be able to see at a glance. Add a third indicator ⛓ N sourced from tools.async_delegation.active_count() — the count of delegations still in the 'running' state. Renders in the plain-text builder and the styled-fragment builder across the same width tiers as the other two (omitted on the narrow <52 tier), guarded so a raising active_count() leaves the snapshot at 0. * feat(slack): add --no-assistant flag to manifest generation By default `hermes slack manifest` opts the app into Slack's AI Assistant container (assistant_view feature + assistant:write scope + assistant_thread_* events). Slack then renders DMs as the right-hand Assistant split-pane, where every exchange is a thread and bare slash commands (/help, /new, ...) are not delivered as normal command events — they only work when the bot is @mentioned. There was no way to opt out short of hand-editing the generated JSON. Add --no-assistant to emit a flat-DM manifest that omits those three pieces, so DMs render as a normal chat and slash commands dispatch inline. The regular messaging surface (Messages tab, slash commands, Socket Mode, channel + DM scopes/events) is preserved in both modes. Default behaviour is unchanged (assistant mode still on). Tests: cover both manifest modes and the argparse wiring. * feat(tui): track background subagents in the status bar (#51485) Parity with the classic CLI status bar's ⛓ indicator (PR #51441). The Ink TUI status bar now shows ⛓ N for live background/async subagents (delegate_task batches + background single delegations). - tui_gateway/server.py: _get_usage() embeds active_subagents from tools.async_delegation.active_count() — the same registry the CLI reads — onto the existing per-update usage payload, guarded so a raising active_count() leaves the field off without breaking usage. - ui-tui appChrome: new 'subagents' status segment (breakpoint w>=92, slots between bg and cost in the shed-order), renders ⛓ N from usage.active_subagents. - Usage / SessionUsageResponse types gain active_subagents?. Distinct from the turn-scoped SpawnHud / /agents overlay, which mirror live in-turn subagent.* events; this is the persistent registry count. * feat: add reasoning_effort support to ollama-cloud provider Map Hermes xhigh→max to unlock DeepSeek V4's 'Max thinking' tier through Ollama Cloud's OpenAI-compatible /v1/chat/completions endpoint. low/medium/high pass through unchanged; disabled/none suppress reasoning entirely. Empirically confirmed: reasoning_effort:max produces ~2.5× more thinking tokens than high on deepseek-v4-pro:cloud (1576 vs 642). * chore: add s010mn to AUTHOR_MAP for PR #29221 salvage * fix(mcp): skip killpg when child shares gateway's process group (#47134) /reload-mcp -> shutdown_mcp_servers -> _kill_orphaned_mcp_children(include_active=True) -> _send_signal -> killpg(pgid, SIGTERM). When a tracked MCP stdio child shares the gateway's OWN process group, killpg delivers SIGTERM to the gateway itself, firing its SIGTERM handler -> os._exit(0): /reload-mcp crashes the gateway. Pre-compute the gateway's own pgid (os.getpgrp(), None on Windows/restricted) and, in _send_signal, skip killpg when pgid == own pgid, falling through to the per-pid os.kill path so the child is still reaped without self-signaling. Adds a regression test (folded in) that pins the guard: with a tracked pgid equal to the gateway's own pgid, killpg is never called for that pgid and the per-pid kill fallback is used. Mutation-checked. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * fix(tui): preserve live session identity across compression (#49041) When a session rotates id on compression, _sync_session_key_after_compress() re-anchored the session_key, approval-notify routing, yolo state, and slash worker — but never moved the active-session lease, which stayed keyed to the pre-compression id. And _find_live_session_by_key() matched live sessions on the stale session_key, not the live agent's current agent.session_id. After compression a resume/create path failed to recognize the existing live agent and could build a SECOND live agent against the same DB continuation -> forked lineage / cross-session message mixing. - active_sessions.transfer_active_session(): move a lease in place to the new id under the exclusive file lock (no slot drop). - gateway _transfer_active_session_slot(): call it inside _sync_session_key_after_compress(); on the rare fallback (entry pruned) RESERVE the new slot before releasing the old lease (reserve-before-release), so a concurrent gateway at the session cap cannot grab the freed slot in a release-then-reacquire window and leave this session with no lease; if the reserve fails, keep the existing lease (review fix). - _session_lookup_key(): make live-session lookup authoritative on agent.session_id, wired into all stale-session_key consumers (_find_live_session_by_key, _session_live_item, _live_session_payload) — fixes the whole lookup class. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * fix(telegram): wire platform_httpx_limits into general-pool HTTPXRequest (#31599) PTB's HTTPXRequest builds its httpx.AsyncClient with `limits = httpx.Limits(max_connections=connection_pool_size)` and no keepalive tuning, so httpx's default keepalive_expiry=5.0 applies. Behind an HTTP proxy (Cloudflare Warp etc.) a peer-initiated FIN can sit in CLOSE_WAIT longer than that, leaking fds in the general request pool (_request[1], which routes bot.send_message/set_my_commands) — the pool _drain_polling_connections never resets. Telegram was the lone holdout adapter not using the shared #18451 CLOSE_WAIT helper. Wire gateway.platforms._http_client_limits.platform_httpx_limits() into the httpx client across ALL THREE request-construction branches — fallback-transport, proxy, and plain — via httpx_kwargs["limits"], which PTB spreads last into its client kwargs so our tuned limits win. PTB's connection_pool_size (max_connections) is preserved; only keepalive behaviour is tightened (max_keepalive_connections + keepalive_expiry<5.0). The fix is macOS-import-safe: no Linux-only socket TCP_KEEPIDLE/INTVL/CNT constants at module scope (unlike the broken candidate which crashed on import on the reporter's OS), and it patches the actual proxy path the repro hits rather than TelegramFallbackTransport, which the proxy repro never instantiates. Adds a mutation-survivable behavior-contract test asserting every HTTPXRequest built by connect() receives httpx_kwargs["limits"] with keepalive_expiry < httpx's 5.0 default, across both the proxy and plain branches. Reverting the limits wiring fails the test. Co-authored-by: indigokarasu <mx.indigo.karasu@gmail.com> * fix(agent): persist tool calls before turn-end flush Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * feat(skills): /learn — distill a reusable skill from anything you describe (#51506) Open-ended skill learning across every surface. /learn <free text> takes a description of any source — a directory, a URL, the workflow you just walked the agent through, or pasted notes — and the live agent gathers it with the tools it already has (read_file/search_files, web_extract, the conversation, the pasted text), then authors a SKILL.md via skill_manage following the house authoring standards (<=60-char description, the standard section order, Hermes-tool framing, no invented commands). No engine, no model-tool footprint, works on any terminal backend (local, Docker, remote): /learn builds a standards-guided prompt and hands it to the agent as a normal turn. - agent/learn_prompt.py: shared standards-guided prompt builder - /learn registry entry (both surfaces) + CLI handler (inject onto input queue) + gateway handler (rewrite turn, fall through, /blueprint pattern) - tui_gateway command.dispatch returns a send directive -> TUI + dashboard chat - dashboard Skills page 'Learn a skill' panel (dir + URL + open-ended text) composes a /learn request and runs it in chat - docs (slash-commands ref + skills feature page), 11 targeted tests Inspired by OpenAI Codex's Record & Replay and the /learn concept from #47234 (dir-distillation engine); reworked to be open-ended and engine-free per review. * fix(agent): handle concurrent tool submit shutdown * fix(gateway): preserve _session_tasks on guard mismatch to enable stale lock healing (#48300) _session_task_is_stale() failed to detect a stale session lock when the owner task completed and cleaned _session_tasks (del in _process_message_background's finally) but _active_sessions was NOT released because _release_session_guard skipped on a guard mismatch (a concurrent reset/new command or drain handoff swapped _active_sessions[key] to a different guard). With no owner task left to inspect, _session_task_is_stale reported 'not stale', the orphaned guard was never healed, and the session deadlocked permanently — later messages received but never dispatched. Reorder the finally cleanup to release-then-conditional-delete: release the guard first, then drop the _session_tasks entry ONLY if the guard was actually released (session_key no longer in _active_sessions). On a guard mismatch the done-task entry survives, so the on-entry self-heal (_session_task_is_stale -> _heal_stale_session_lock) detects the stale lock and clears it on the next inbound message. Extracted the cleanup into a callable _cleanup_finished_session_task() helper so the regression test drives the REAL production code path rather than a copy of its logic (the original test inlined the fixed logic and passed regardless of the production order — mutation-verified the rewritten tests now fail on the buggy del-first order). Added a positive-path test (guard matches -> release + delete) so both branches are pinned. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com> * chore(release): map manusjs email to manus-use GitHub login Required by contributor-check/check-attribution before salvaging PR #51129 (Discord thread-starter dedup, #51057). The CI step greps AUTHOR_MAP by exact email and does not special-case noreply addresses. * fix(gateway): prevent double dispatch of Discord messages via thread-starter dedup When _auto_create_thread() creates a thread from a user message via message.create_thread(), Discord fires a second MESSAGE_CREATE event for the 'thread starter message'. That starter message carries message.id == thread.id and may arrive with type=default instead of type=21 (thread_starter_message), so the existing type filter in on_message does not catch it — triggering a second call into _handle_message and thus a second agent run and response. Fix: after _auto_create_thread succeeds and returns a thread, pre-seed the dedup cache with str(thread.id) via…