fix(memos-local-plugin): use POSIX-ERE-compatible pgrep pattern for hermes chat detection (port of #2192 to main)

[kiwipaulrob]

Summary

Ports the reviewed pgrep pattern fix from #2192 onto main, so release trains that build the local plugin from main stop shipping an invalid pgrep -f pattern.

#2192 was merged on 24 Aug into fix-local-plugin-260824, but main (and npm builds published from it, including 2.0.15) still carries the pre-fix pattern. This PR applies the identical reviewed change — POSIX character classes + capturing groups only for the pgrep wire format, with a dedicated JS literal for the unit-test helper.

Root cause

HERMES_CHAT_PROCESS_PATTERN shipped as hermes(?:\\s+\\S+)*\\s+chat\\b. The (?:...) non-capturing group is PCRE syntax; pgrep -f on Linux compiles patterns with glibc POSIX ERE, which has no non-capturing groups and rejects the whole pattern:

pgrep: regex error: Invalid preceding regular expression   # pgrep exits 2

isHermesChatRunning() collapses every failure to false, so each detection poll errors and the daemon viewer stays stuck on "disconnected". The original #1915 fix passed its unit tests because JavaScript's RegExp accepts (?:...) — JS matching behaviour is a faithful proxy for matching, but not for pattern validity under ERE. Observed live on 26 Aug 2026 (plugin 2.0.15): one regex error per poll cycle in the daemon journal across reboots, plus core.health timeouts during host load spikes while detection kept silently failing.

Fix (identical to reviewed #2192)

• pgrep wire pattern rebuilt from POSIX character classes and capturing groups only:
  hermes([[:space:]]+[^[:space:]]+)*[[:space:]]+chat([[:space:]]|$)
• JS test helper split into its own literal (HERMES_CHAT_JS_PATTERN) so each engine gets a natively valid regex for the same command grammar; chat must be a complete argv token (no chat-server false positives)
• New Linux-only regression test runs the real pgrep binary against the wire pattern and requires exit status 0 or 1 — exit 2 means a syntax error slipped back in

Verification

• Old-pattern reproduction: pgrep -f 'hermes(?:\\s+\\S+)*\\s+chat\\b' → exit 2 (Invalid preceding regular expression); new pattern → exit 0/1
• vitest run tests/unit/bridge/hermes-process.test.ts: 16/16 passed (includes the real-pgrep Linux regression)
• Full bridge suites: vitest run tests/unit/bridge/ tests/unit/bridge-status.test.ts → 7 files / 39 tests passed
• Scoped tsc --noEmit type-check of bridge/hermes-process.ts: clean

Notes

• No runtime dependencies; no generated dist/ files added.
• CONTRIBUTING.md suggests PRs against dev, but no plain dev branch exists upstream; recent plugin fixes (fix(memos-local-plugin): use POSIX-ERE-compatible pgrep pattern for hermes chat detection #2192) were merged via feature branches, so this targets main. Happy to retarget if maintainers prefer another base.

[Memtensor-AI]

🤖 Open Code Review

Target: PR #2283
Task: 1047e25905856aaf
Base: main
Head: fix/pgrep-ere-pattern-main

✅ OpenCodeReview: Review complete: 0 finding(s) across 1 selected item(s).

Generated by cloud-assistant via Open Code Review.

[Memtensor-AI]

⚠️ Automated Test Results: ENV ISSUE

The test environment encountered an issue that requires manual attention.

Details: Executor error: Command failed: git clone --depth 1 --branch fix/pgrep-ere-pattern-main git@github.com:kiwipaulrob/MemOS.git /data/test-workspaces/1047e25905856aaf/repo
Cloning into '/data/test-workspaces/1047e25905856aaf/repo'...
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Branch: fix/pgrep-ere-pattern-main

[kiwipaulrob]

The ENV ISSUE above was a transient failure in the test executor's SSH transport, not a problem with this branch:

kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

That error occurs during SSH key exchange — before any git ref negotiation — so the branch was never actually fetched.

Verified independently:

• Branch fix/pgrep-ere-pattern-main exists on the fork and resolves to exactly 32d1f046 (checked via git ls-remote over HTTPS just now)
• All 17 GitHub Actions checks on the head commit are green (build matrix ubuntu/macos/windows × Python 3.10–3.13 + sync)
• OpenCodeReview completed with 0 findings

Could the automated test be re-run for this task? Happy to help if there's anything needed from the fork side.

[Hun-ger]

Thanks for the contribution and for validating the POSIX ERE behavior with the real pgrep binary.

This fix is already present on fix-local-plugin-260824 through #2192 (commit 7b950062). I compared the current files with this PR: the runtime implementation is the same, with only a non-behavioral fixture-path difference in one test. The original contribution record is therefore already preserved by #2192.

Closing this PR as duplicate/superseded so the same fix is not landed twice. It will reach main with the aggregate plugin-fix branch.