mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-11-06 05:17:15 +00:00
main
14
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Ben Barclay
|
871900df63 |
feat(config): route every user config.yaml read and write through a ConfigBackend seam
Add hermes_cli/config_backend.py (config-config design §4.1, D10/D11): a ConfigBackend protocol, the FileBackend (today's behaviour), selection by HERMES_CONFIG_BACKEND only (default file; 'remote' and unknown values fail closed with ConfigBackendUnavailable), and path-level helpers (read_config_doc, read_config_doc_readonly, config_version, config_exists, write_config_key, write_config_document, supports_file_tooling). Migrate every direct reader/stat/exists/bypass writer of a user config.yaml to the helpers (config.py loaders + caches, config_effective, env_loader, gateway, TUI, CLI watchers, cron, tools, profiles, logging, time). File tooling (config edit, backups, xAI migration rewrite, raw dashboard editor) checks supports_file_tooling() first; migrations skip write-back without it. Add scripts/check_config_yaml_readers.py (CI lint next to the writers gate) that rejects a direct read of a config path outside the backend. |
||
|
Teknium
|
dc8e416b34 |
fix(cli): a hermes chat started from an agent's terminal runs in its launch directory
The local CLI force-exports TERMINAL_CWD = os.getcwd() at config load, except inside a gateway process, which it detected with the _HERMES_GATEWAY env marker. gateway/run.py sets that marker in os.environ, so every shell the gateway's terminal tool spawns inherits it. A `hermes chat` launched from such a shell skipped the export, kept the gateway's TERMINAL_CWD (terminal.cwd from config.yaml), and both its terminal tool and its system prompt ran in that directory while sessions.cwd recorded the real launch dir. Ask whether THIS process imported gateway.run instead; that is exactly when the marker is set in-process, minus the inherited case. Fixes #95078 |
||
|
Teknium
|
e1b65c5f0b |
refactor(browser): callers stop naming agent-browser, Camofox and the built-in browser tools
- hermes acp --setup-browser installs pm's chromium (browser_exec's local browser), not agent-browser; - the codex hermes-tools MCP server stops exposing the deleted browser_* tools (browser_exec stays out: it runs model-written Python outside codex's sandbox and approval UI); /codex-runtime copy follows; - telemetry: the removed tool names become RETIRED_TOOL_NAMES so the shipped schema enums keep them; camofox stays a legacy browser backend label; - CLI config defaults drop browser.camofox / record_sessions (the camofox plugin reads browser.camofox itself); - learn prompt names browser_exec; stale comments and help text updated. |
||
|
Teknium
|
d99af4187b |
refactor: move the Singularity terminal backend out of core into the singularity catalog plugin
The Singularity/Apptainer backend (tools/environments/singularity.py) now ships as the official 'singularity' plugin in NousResearch/hermes-official-plugins, registered through the terminal-environment provider seam under the same backend name and config keys (terminal.backend: singularity, terminal.singularity_image / TERMINAL_SINGULARITY_IMAGE, terminal.container_*). - 'singularity' leaves BUILTIN_BACKEND_NAMES so the plugin can register it; every hardcoded classification set drops it (the provider declares is_remote/is_container/supports_streams instead). - LEFT_CORE gains a singularity row: homes whose terminal.backend (or .env TERMINAL_ENV) is singularity get the catalog plugin once, on hermes update or agent/gateway start. An unknown-backend error for 'singularity' names the install command (new row field terminal_backend). - A plugin backend receives its per-task '<backend>_image' override; batch runs register one for the active backend. - BaseEnvironment's sudo-probe knob is renamed _passwordless_sudo_probe_supported: plugin backends set it, and the old spelling trips the install scanner. - Core's scratch-dir disk warning and process-exit sweep were Singularity-only and move to the plugin; the singularity setup row, dashboard probe/row and config defaults/bridges go too. Docs point at the plugin. |
||
|
Teknium
|
2aef21193c |
fix(cli): glyph layout keeps classic parity for the status line, spinner and reasoning
The glyph layout had dropped things the classic CLI shows: - the status line rendered a private default subset: context detail, cache hit, latency, tokens/s, duration and prompt/idle timers were gone. It now renders the classic segments unchanged (same fields, tiers and display.status_bar.fields filter) plus cwd and key hints when they fit. - the composer rule stripped the kaomoji/tool emoji and lost the streamed token count (the classic spinner suffix). Both are back. - reasoning no longer streamed: it was buffered and collapsed to a single summary line. It streams live again as in classic, under the dim bar, closed by the summary line; post-hoc reasoning keeps classic first-10-lines. - unset busy_input_mode silently switched to steer in this layout. It is interrupt in both layouts again (Tab still queues). |
||
|
Teknium
|
e2bb757eba |
feat(cli): glyph transcript, status line under the composer, two-line header
The classic CLI's scrollback was built from width-sized frames (reasoning and answer boxes, 40-column rules around every message), so a terminal resize re-wrapped and garbled everything already printed, and the status bar sat above the input where the spinner row made the composer jump. display.cli_layout (new, default "modern") switches to a grammar where every scrollback row starts with one glyph and never depends on the width: ❯ user message ∴ reasoning collapsed to "Thought for Ns · title" ● Verb target 0.2s ✗ failed call in red, with its exit code │ diff under its row ☤ Hermes answer label, no frame ─ turn summary · time Width-dependent chrome moves into prompt_toolkit's live region: the composer's top rule carries the spinner, current activity and elapsed time (left) and the session title (right); the status line renders under the composer with model, context gauge, live badges (stash, background work, goal, YOLO) and cwd/branch on the left and the keys that work right now on the right. Launch prints a two-line header instead of the full banner. With busy_input_mode unset, the modern layout steers (Tab queues); classic keeps interrupt. display.cli_layout: classic restores the previous look unchanged. Also: panel rows wrap per source line, so a heredoc command no longer breaks the approval panel's right border (both layouts); docs drop the stale claim that classic chat always queues (steer and interrupt reach the gateway). |
||
|
unsupportedpastels
|
aa86cf6815 |
fix(gateway): apply a client's HERMES_* behaviour values to its own session only
On main each `hermes` process read HERMES_EPHEMERAL_SYSTEM_PROMPT, HERMES_PREFILL_MESSAGES_FILE and HERMES_INFERENCE_PROVIDER from its own shell. Since the one gateway runs every session, the values exported by whichever client auto-started it became daemon-wide (messaging and cron included), and every later client's exports were ignored. The classic CLI and the Ink TUI now send an allowlisted `client_env` map (plain strings) with session.create; the classic CLI takes the allowlist's extra names from the profile's effective config (managed layer included), as the gateway reads them, and a safe-mode or ignore-user-config launch reads no profile. The gateway filters the map again against the session profile's allowlist, freezes it with the session's policy (outside launch_request, so viewers never see the values) and binds it for that session's turns only: the ephemeral prompt, the prefill file and the provider request read the session's value, in-process and for a managed worker. Desktop sends nothing and keeps the gateway's environment, as does a session created before this change. The auto-started daemon no longer inherits these variables (nor HERMES_ENABLE_PROJECT_PLUGINS); a gateway the operator starts keeps its own environment. Clients send the field only when runtime.describe lists it. An exact retry of a session created before this change returns its original session; the retry and commit comparisons and the policy identity treat an absent client_env as before. A retry is judged against the committed, filtered map: every stored name must come back with its stored value, and names dropped at creation don't count, whatever the allowlist is now. Fresh creates use the current rules, and the unfiltered map is never stored. Refs #134889 (LC-8) Refs #139523 |
||
|
Maciej Lisiewski
|
d76cce4f11 | ci: apply all automatic linter fixes available | ||
|
kshitijk4poor
|
bdde674296 |
feat(fast): /fast ultrafast for GPT-6 Astra, priced at the served tier
OpenAI's Ultrafast service tier (service_tier="ultrafast") is broadly available for GPT-6 Astra in the API and Codex (Pro 500 / Enterprise), billed at 6x Standard. GPT-6.1 Sol Ultrafast is announced as coming soon. - One tier table: agent.fast_mode.parse_service_tier / STATIC_TIERS now back the CLI, gateway and TUI config loaders (three hand-copied parsers). - resolve_fast_mode_overrides(tier="ultrafast") sends the tier only for Ultrafast models on api.openai.com / chatgpt.com; anything else gets nothing rather than a silent swap to another paid tier. - /fast ultrafast on CLI, gateway (typed + picker when supported) and TUI; static-tier attach sites pass the tier through. - Pricing: the response's SERVED service_tier is folded into usage (Codex stream assembler keeps it); served ultrafast prices from a published 6x row (272K whole-request tier included). A request asking for Ultrafast but served at default bills at Standard. - i18n: 4 new keys in all 17 locales; option lists mention ultrafast. |
||
|
Teknium
|
7c799a6565 |
feat(vercel): fresh sandboxes use a managed image (universal:latest); runtime presets deprecated, migration 49 (#126741)
* feat(vercel): start fresh sandboxes from a managed image instead of the deprecated runtime Vercel deprecated Sandbox runtimes (node24/node22/python3.13) in Aug 2026 in favour of images, and rejects runtime+image together and runtime with a snapshot source. New terminal.vercel_image (default vercel/sandbox/universal:latest, Node 24 + Python 3.14) picks the image for fresh sandboxes; a pinned terminal.vercel_runtime still works, wins over the image and logs a deprecation warning; snapshot restores send neither. Setup wizard prompts for the image, dashboard exposes both keys, status/config show the effective choice, TERMINAL_VERCEL_IMAGE bridges config to the tool like its siblings. * feat(config): migration 49 drops the seeded node24 Vercel runtime pin Every pre-49 config.yaml carries terminal.vercel_runtime: node24 (the template default) and the setup wizard mirrored it into .env as TERMINAL_VERCEL_RUNTIME. Both are the default copied, not a choice, so the migration drops them and fresh sandboxes follow vercel_image; node22 / python3.13 pins are the user's and survive. Persisted sandboxes are unaffected: a snapshot restore never sends a runtime or an image. |
||
|
Teknium
|
399d956903 |
feat(bot_desktop): Bot Screen, computer_use and the browser run inside the terminal backend (#121169)
* feat(docker): publish nousresearch/hermes-sandbox:desktop for terminal backends
The terminal backends (docker, modal, daytona, singularity) all default to
nikolaik/python-nodejs:python3.11-nodejs20, a bare Python+Node base. For Bot
Screen, computer_use and the browser to run INSIDE that sandbox instead of on
the gateway host, the sandbox image needs the display stack.
docker/sandbox-desktop.Dockerfile is that base plus:
- the everyday tools it lacked (jq, ripgrep, fd, tmux, less, nano, vim,
zip, rsync, tree, procps, htop, sudo for the base's uid-1000 `pn`)
- the exact package set the Hermes -desktop image installs (TigerVNC,
Xfce components, dbus, xauth, fonts)
- Playwright's headed Chromium (same build as the -desktop image)
- cua-driver 0.28.2 from its pinned release tarball
No Hermes inside; the default user stays root like the base so nothing
changes for people who just switch docker_image. Desktop processes run as
`pn`. 4.27 GB on amd64.
docker.yml gains a `sandbox` variant with its own cache scope and repository
(nousresearch/hermes-sandbox:desktop, :main-desktop, :<release>-desktop);
the docker-integration suite is skipped for it (no Hermes to test) and
docker/sandbox-desktop-smoke.sh runs instead: as `pn`, every launcher and
cua-driver binary resolves, the real launcher.sh publishes :20, the RFB
socket completes the 3.8 handshake relayed over `docker exec -i` stdio, and
a headed Chromium maps a window on that display. hadolint lints the new
Dockerfile in docker-lint.yml.
* feat(docker): sandbox desktop base on python3.13-nodejs26
Matches the Hermes image (Python 3.13 / Node 26) and the top of requires-python;
the default docker_image tag it inherited was Python 3.11 / Node 20. Same pn
uid 1000, Debian 13; smoke (launcher, RFB relay, headed Chromium) passes.
* feat(docker): bake agent-browser into hermes-sandbox:desktop
The browser tools drive the agent-browser CLI; when the browser follows the
terminal backend that CLI has to exist inside the sandbox. Pinned to the same
^0.26.0 range the gateway resolves, --ignore-scripts like the gateway's npx path.
* feat(bot_desktop): the screen, computer_use and the browser follow the terminal backend
A user who sandboxes `terminal` (docker/ssh/singularity) had the agent's
screen, cua-driver and Chromium running on the gateway HOST beside that
sandbox: Bot Screen gave a headless host a display, the Xfce panel carries
xfce4-terminal, and `computer_use` could open a shell outside the boundary
the sandbox exists for.
Now the desktop lives where the terminal lives:
- tools/environments/streams.py: one primitive per spawn-per-call backend, the
local argv prefix that runs its remainder inside the sandbox with stdio open
(`docker exec -i`, `ssh`, `apptainer exec`). SDK backends (modal, daytona,
vercel) have none and report so.
- tools/bot_desktop/sandbox_host.py: launcher.sh runs inside the sandbox as
the image's `pn`; the pane's RFB bytes ride a 12-line python relay over that
prefix; `cua-driver mcp` is the prefix + the sandbox image's own driver.
- tools/bot_desktop/placement.py + `bot_desktop.placement` (auto|terminal|
gateway). `auto` follows the backend; a sandbox that cannot host a screen
REFUSES with the opt-in named instead of silently using the host.
- runtime.start/stop/status/published_env branch on placement; the pane,
lease, epoch fencing and CLI are unchanged.
- cua_backend: the MCP invocation is the sandbox one when the screen is
there; the host driver's runtime contract is irrelevant then; check_fn is
true under a terminal placement without a host binary.
- browser_tool_session: agent-browser invocations are wrapped in the prefix
with the daemon, socket dir and profile inside the sandbox; screenshots are
fetched back so MEDIA: paths keep working; recycle closes the sandbox
daemon.
- web_routers/display.py: the bridge pumps a relay's stdio when the screen is
in a sandbox, a unix socket otherwise.
Live on docker with nousresearch/hermes-sandbox:desktop: start/observe/RFB
handshake through the dashboard bridge, human takeover fences the agent
(HumanHasControl) and keystrokes reach the sandbox Xvnc, handback restores,
three start/stop rounds leave zero desktop processes; computer_use capture
and list_windows see only the sandbox's Xfce; browser_navigate/snapshot/
vision run with Chromium and agent-browser inside the container and zero
host processes on the bot profile; modal + auto refuses naming the opt-in.
* feat(desktop): Screen pane shows where a sandbox-placed screen runs; Install is host-only
DesktopStatus gains placement ('gateway' | 'terminal:<backend>'). A sandbox
image lacking the stack is a blocker naming hermes-sandbox:desktop, shown in
place of Start; install_command stays None there because the pane's Install
button runs the package manager on the gateway host, the wrong machine, and
display.install refuses for the same reason. The pane header carries
'Screen runs inside the docker sandbox, with the terminal' (4 locales).
* fix(bot_desktop): "is the screen in the sandbox" is a disk check on hot paths, never a config read
Every browser command and CUA spawn asked in_sandbox(), which resolves placement by
loading config, which initializes HERMES_HOME. Under a test's fake home that raised
HomeInitializationError from _run_browser_command; on a real host it read config per
click. Hot paths now ask sandbox_screen_running(): the start marker on disk, written
only by a sandbox start. Policy (in_sandbox) stays for start/install, where config is
the question. display.observe gates on "an RFB endpoint exists" for either placement.
* test(moa): late-accounting sink test asserts the wedged slot's row, not sink order
Under CI load the poll loop can see the interrupt before collecting the fast slot, so the
fast slot also arrives late and first; the test then failed on sink_calls[0]. The
contract is that the wedged slot's real usage reaches the sink.
* chore: retrigger CI (zero-job dispatch failure, auto-heal)
* fix(bot_desktop): a sandbox that died under a live screen fails loudly, never falls to the host
sandbox_screen_running() drops a start marker whose terminal environment is no longer
registered (stale after a process restart). When the environment object outlives its
container, the browser's sandbox wrap now checks the published DISPLAY and raises
"the screen inside the terminal backend's sandbox is gone; start it again" instead of
KeyError('AGENT_BROWSER_PROFILE'). Live: fresh sandbox navigate ok; docker rm -f the
container; next navigate returns that error; zero host Chromium either way.
* feat(terminal): nousresearch/hermes-sandbox:desktop is the default container sandbox
Every container backend (docker, modal, daytona, singularity) now defaults to the
sandbox image with the desktop stack, so Bot Screen, computer_use and the browser
run inside the sandbox for everyone who never chose an image; Python 3.13 / Node 26
match the Hermes image. One constant (DEFAULT_SANDBOX_IMAGE) replaces six copies of
the old literal. Migration 47 moves saved configs still holding the OLD default and
never touches an image the user pinned. Docker reuse recreates a container built
from another image, or the flip would silently never take effect for anyone with a
persisted container (live: old container removed, new one on 3.13 / Node 26 with
Xvnc, cua-driver, agent-browser present).
* chore: retrigger CI (zero-job dispatch failure)
* chore: retrigger CI (zero-job dispatch failure, auto-heal)
* chore: retrigger CI (zero-job dispatch failure, auto-heal)
* chore(config): template stamps v47 and shows the new default sandbox image
The template is what install.sh / docker / doctor --fix seed; a stamp behind
DEFAULT_CONFIG makes every fresh install migrate on first run.
* feat(sandbox): the default image change is a decision, not a surprise
A persisted Docker sandbox on another image is kept when docker_image is unset;
only a written docker_image (an explicit pin) recreates it. The pin verdict
travels as TERMINAL_DOCKER_IMAGE_PINNED through both terminal bridges (process
env and per-profile scope) and the container-config allowlist.
Approval surfaces, all through hermes_cli.sandbox_image_switch: the interactive
CLI asks once at startup (y = pin the new image, n = pin the current one, Enter =
ask later); the Screen pane shows the same choice with Switch / Keep buttons via
display.switchSandboxImage; `hermes config set terminal.docker_image …` is the
same answer from any shell. Gateways and cron never decide: they keep the sandbox
and log the notice.
Migration 47 now unsets a saved image equal to the OLD default instead of
rewriting it to the new one — that value was the template copied, not a pin, and
rewriting it would have made the runtime recreate existing sandboxes unasked.
Modal restores its snapshot and Daytona reuses its labeled sandbox regardless of
the configured image, so existing sandboxes there were already untouched.
* fix(config): both plain defaults that preceded the desktop sandbox image are template copies
main pinned nikolaik/python-nodejs:python3.14-nodejs22 (
|
||
|
Hermes Agentandleakedd
|
4503c2458b |
fix(tui_gateway): honor prefill_messages_file on the Desktop agent path
Desktop and TUI agents are built by tui_gateway.server._make_agent, which never runs the classic CLI bootstrap and passed no prefill_messages to AIAgent, so a configured prefill_messages_file was silently ignored there. Resolve it with the CLI's own resolver/loader (env > prefill_messages_file > legacy agent.prefill_messages_file). The loader takes an optional base_dir so relative paths resolve against the profile building the agent, not the launch home. Co-authored-by: leakedd <66937184+leakedd@users.noreply.github.com> |
||
|
ethernet
|
9f2ba1b74d |
merge origin/main (779 commits) into ethie/pm-clean
Branch semantics kept where main and PM disagree: update_cmd_deps.py, constraints-termux.txt, the Electron update-api-check module and the post-swap hand-off test stay deleted; the pending-fleet-restart catch-up and the local_runtime tag/download ladder stay retired (PM owns engines). Ported from main onto the branch's shape: profile_scoped_chore for the auto-archive and plugin-update housekeeping chores, the local-runtime cross-process boot lock and residency cap, the checkpoint tmp_pack sweep, the cua daemon-liveness status probe, the remote-served Desktop update flag (posix.sh / windows.ps1), sign-in for env-pinned remote gateways (urlDisabled on RemoteSetupFields), the uvloop extra split (uvicorn without [standard]), and the umask-scoping spawn test. uv.lock regenerated with pm.build_env --lock-only; new utf-8 reads from main switched to utf-8-sig (check-windows-footguns). |
||
|
teknium1
|
2ca53fc386 |
refactor(cli): move cli.py module-level helper clusters into topical siblings; cli.py lands under 2,000 lines (#116911)
Mechanical, behaviour-neutral extraction along the existing hermes_cli/cli_*.py
pattern. Six clusters of module-level helpers leave cli.py:
- cli_config_load.py prefill messages, reasoning/service-tier parsing, terminal
env mirroring, CLI defaults + YAML merge, logging bootstrap
- cli_render.py reasoning-tag stripping, ANSI/skin colours, light-mode
detection, markdown/final rendering, output-history
recording, _cprint, ChatConsole, compact banner, panel wrap
- cli_terminal_input.py file drops/attachments, bracketed-paste patch, extended
Enter keys, CPR guards, TUI input height, query images
- cli_shutdown.py process session-id sync, exit watchdog, cleanup steps,
session-finalize notifications, one-shot finalize
- cli_single_query.py kanban goal loops, exit-code mapping, quiet -q runner,
image routing, signal handlers, single-query mode
- cli_auto_maintenance.py state-db / checkpoint startup maintenance
Every moved body is AST-identical to the base copy modulo two mechanical
edits: cli-level names are late-bound with a call-time `from cli import ...`
(the cli_init_mixin pattern) and mutable cli state is read through `_cli().NAME`
(the gateway_service_unit `_gw()` pattern), so every monkeypatch seam on the
`cli` facade still intercepts moved code and no read snapshots stale state.
Mutable module state and every `global`-writing function stay in cli.py; the
facade re-exports the moved names in one import block.
test_bracketed_paste_timeout AST-loads the paste helper from its new home.
cli.py 3959 -> 1820 lines.
|