Description
In apps/memos-local-plugin/bridge.cts, the isHermesChatRunning() function uses pgrep -f "hermes chat" to detect whether a Hermes chat session is active. This pattern only matches when "hermes" and "chat" are adjacent tokens in the process command line.
However, the hermes CLI supports global flags that are placed before the subcommand. For example, the --skills flag (and others like -m, --provider) can be used either as chat-level flags:
hermes chat --skills memory-routing
or as global flags:
hermes --skills memory-routing chat
In the latter case, the process command line becomes:
/usr/local/lib/hermes-agent/venv/bin/hermes --skills memory-routing chat
The substring "hermes chat" does not appear contiguously here, so pgrep -f "hermes chat" returns no match even though a chat session is actively running.
Impact
This only affects the daemon mode bridge (--daemon flag), where applyStaleRule() uses isHermesChatRunning() to upgrade the status from "disconnected" to "reconnecting". The stdio mode (the default when started via memtensor provider or systemd) is not affected — it manages its own lifecycle via the stdio connection directly.
Suggested Fix
Replace the fixed-string pattern with a regex that allows optional flags between "hermes" and "chat":
- const out = childProcess.execFileSync("pgrep", ["-f", "hermes chat"], {
+ const out = childProcess.execFileSync("pgrep", ["-f", "hermes\\s.*chat\\b"], {This pattern matches "hermes" followed by a whitespace character, then any characters (including flags), then "chat" at a word boundary. It covers both:
hermes chat (adjacent, no flags)hermes --skills memory-routing chat (global flags before subcommand)hermes chat --skills memory-routing (flags after subcommand, already matched by the original pattern)
The risk of false positives is minimal — matching a process that contains "hermes" and "chat" in unrelated positions on the same command line is unlikely in practice.
Environment
- Hermes Agent: any version supporting global flags before subcommands
- memos-local-plugin: any version (confirmed in v2.0.19 / npm v2.0.7)
- Platform: Linux (Ubuntu/Debian based)
Description
In
apps/memos-local-plugin/bridge.cts, theisHermesChatRunning()function usespgrep -f "hermes chat"to detect whether a Hermes chat session is active. This pattern only matches when"hermes"and"chat"are adjacent tokens in the process command line.However, the
hermesCLI supports global flags that are placed before the subcommand. For example, the--skillsflag (and others like-m,--provider) can be used either as chat-level flags:or as global flags:
In the latter case, the process command line becomes:
The substring
"hermes chat"does not appear contiguously here, sopgrep -f "hermes chat"returns no match even though a chat session is actively running.Impact
This only affects the daemon mode bridge (
--daemonflag), whereapplyStaleRule()usesisHermesChatRunning()to upgrade the status from"disconnected"to"reconnecting". The stdio mode (the default when started via memtensor provider or systemd) is not affected — it manages its own lifecycle via the stdio connection directly.Suggested Fix
Replace the fixed-string pattern with a regex that allows optional flags between
"hermes"and"chat":This pattern matches
"hermes"followed by a whitespace character, then any characters (including flags), then"chat"at a word boundary. It covers both:hermes chat(adjacent, no flags)hermes --skills memory-routing chat(global flags before subcommand)hermes chat --skills memory-routing(flags after subcommand, already matched by the original pattern)The risk of false positives is minimal — matching a process that contains
"hermes"and"chat"in unrelated positions on the same command line is unlikely in practice.Environment