Skip to content

feat: Background Process Monitoring — watch_patterns for real-time output alerts#7635

Merged
teknium1 merged 2 commits into
mainfrom
hermes/hermes-b092dccf
Apr 11, 2026
Merged

feat: Background Process Monitoring — watch_patterns for real-time output alerts#7635
teknium1 merged 2 commits into
mainfrom
hermes/hermes-b092dccf

Conversation

@teknium1

@teknium1 teknium1 commented Apr 11, 2026

Copy link
Copy Markdown
Contributor

Background Process Monitoring

Hermes agents can now monitor background processes in real-time and react to specific output the moment it appears — no polling, no wasted tokens, no manual checking.

terminal(
    command='npm run dev',
    background=true,
    watch_patterns=['ERROR', 'WARN', 'listening on port']
)

The agent keeps working on other tasks. The instant ERROR appears in the process output, Hermes wakes up and reacts — fixes the bug, restarts the server, notifies the user. Zero-cost while the output is clean.

This turns background processes from fire-and-forget into event-driven workflows: start a dev server and get alerted on crashes. Run a test suite and react to the first failure while the rest still runs. Deploy to production and watch for errors in real time. Monitor build output for warnings before they become blockers.

How It Works

One new parameter on the existing terminal tool — no new tools, no schema bloat. The agent passes a list of strings to watch for, and Hermes handles the rest:

  • Pattern matching runs inside the existing reader threads across all backends (local, Docker, SSH, Modal, Daytona, Singularity)
  • Notifications flow through the unified completion_queue alongside notify_on_complete events — same proven delivery path, same consumption points in CLI and gateway
  • Rate limiting prevents noisy processes from burning tokens: 8 notifications per 10-second window, with a 45-second sustained-overload kill switch
  • Crash recovery persists watch patterns in the checkpoint file so gateway restarts don't lose monitoring state

Stacks with notify_on_complete — use both to get pattern alerts while running AND a completion summary when done.

What the Agent Sees

When a pattern matches:

[SYSTEM: Background process proc_abc123 matched watch pattern "ERROR".
Command: npm run dev
Matched output:
TypeError: Cannot read property 'foo' of undefined
    at Server.handler (app.js:42:15)]

If rate-limited:

[SYSTEM: Background process proc_abc123 matched watch pattern "ERROR".
Command: npm run dev  
Matched output:
Error: connection refused
(12 earlier matches were suppressed by rate limit)]

Changes

File What
tools/process_registry.py ProcessSession.watch_patterns, rate-limit state, _check_watch_patterns() in all 3 reader threads, unified queue with type field, checkpoint persistence
tools/terminal_tool.py watch_patterns array parameter in schema + handler
cli.py _format_process_notification() — unified formatter for completions + watch events, drain at both idle and post-turn sites
gateway/run.py _format_gateway_process_notification(), _inject_watch_notification(), post-agent-run drain
tools/code_execution_tool.py watch_patterns blocked in execute_code sandbox
tests/tools/test_watch_patterns.py 20 tests covering matching, rate limiting, overload kill, checkpoint persistence, schema, handler

E2E Verified

Interactive CLI session: started a 30-iteration loop printing ERROR every 5th line. Agent received the watch notification while idle, woke up, reported all 6 ERROR lines. Full pipeline confirmed working across pattern matching → queue → idle drain → synthetic message injection → agent turn.

Tests

20 passed — test_watch_patterns.py
59 passed — test_notify_on_complete.py + test_process_registry.py (no regressions)
7 passed  — test_terminal_tool.py (no regressions)

@teknium1 teknium1 changed the title feat: watch_patterns for background process output monitoring feat: watch_patterns — background process output monitoring Apr 11, 2026
@teknium1 teknium1 changed the title feat: watch_patterns — background process output monitoring feat: Background Process Monitoring — watch_patterns for real-time output alerts Apr 11, 2026
Adds a new 'watch_patterns' parameter to terminal(background=true) that
lets the agent specify strings to watch for in process output. When a
matching line appears, a notification is queued and injected as a
synthetic message — triggering a new agent turn, similar to
notify_on_complete but mid-process.

Implementation:
- ProcessSession gets watch_patterns field + rate-limit state
- _check_watch_patterns() in ProcessRegistry scans new output chunks
  from all three reader threads (local, PTY, env-poller)
- Rate limited: max 8 notifications per 10s window
- Sustained overload (45s) permanently disables watching for that process
- watch_queue alongside completion_queue, same consumption pattern
- CLI drains watch_queue in both idle loop and post-turn drain
- Gateway drains after agent runs via _inject_watch_notification()
- Checkpoint persistence + crash recovery includes watch_patterns
- Blocked in execute_code sandbox (like other bg params)
- 20 new tests covering matching, rate limiting, overload kill,
  checkpoint persistence, schema, and handler passthrough

Usage:
  terminal(
      command='npm run dev',
      background=true,
      watch_patterns=['ERROR', 'WARN', 'listening on port']
  )
Unified queue with 'type' field distinguishing 'completion',
'watch_match', and 'watch_disabled' events. Extracted
_format_process_notification() in CLI and gateway to handle
all event types in a single drain loop. Removes duplication
across both CLI drain sites and the gateway.
@teknium1 teknium1 force-pushed the hermes/hermes-b092dccf branch from c26d433 to bf2b74c Compare April 11, 2026 10:13
@teknium1 teknium1 merged commit f459214 into main Apr 11, 2026
ccross2 added a commit to ccross2/hermes-agent that referenced this pull request Apr 14, 2026
Brings ccross2/hermes-agent up to NousResearch/hermes-agent@ac80bd61
(v0.9.0 release "the everywhere release").

Merge highlights from upstream:
- Pluggable Context Engine slot (NousResearch#7464)
- Local web dashboard, Termux/Android, iMessage/WeChat platforms
- Fast Mode (/fast) for OpenAI/Anthropic priority queues
- Background process monitoring (watch_patterns, NousResearch#7635)
- Comprehensive security hardening (Twilio signature, SSRF, path
  traversal, git injection, shell injection in sandbox writes)
- Dead code cleanup (1,784 lines across 77 files, NousResearch#9180)
- CANONICAL_PROVIDERS consolidation (NousResearch#9237)
- gateway /stop no longer resets session (NousResearch#9224)

Conflict resolution summary (7 hunks across 3 files):

1-4. cli.py _build_compact_banner — took upstream.
   Upstream added skin-aware colors + version label + tiny_line for
   narrow terminals. ccross2 had added word-wrapping for narrow
   terminals (commit 5b32504). The skin engine integration is
   foundational (affects several other surfaces); the word-wrapping
   improvement can be re-added as a follow-up on top of skin-aware.

5. cli.py _reset_stream_state — kept BOTH.
   ccross2 added _stream_in_code_fence; upstream added
   _deferred_content. Different features in the same reset hook,
   both needed.

6. tools/transcription_tools.py get_stt_model_from_config — took ccross2.
   ccross2 added provider-aware model resolution (local/groq/openai
   with per-provider model overrides). Upstream restructured but
   didn't provide an equivalent; the function coexists with upstream's
   _load_stt_config() which returns the raw dict.

7. tests/tools/test_transcription_tools.py — took ccross2.
   Tests for the provider-aware function we kept in (6).

Post-merge state: 5 local ccross2 commits preserved on top of
upstream 0.9. Backup of pre-merge state at
ccross2/cc-fusion-09-rebase-backup (Claude Code's rebase attempt
with 4 of the 5 patches, before this proper merge).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant