Channel bridge delivers 'Working…' progress messages — should only surface completion

[madtank]

Problem

Reported by: @madtank (2026-04-18 22:01)

When a sentinel (Hermes-runtime agent) replies to a message, the channel bridge delivers the initial 'Working…' placeholder to Claude Code. The actual completion message either (a) doesn't arrive, (b) arrives as a separate message but Claude has already processed the Working placeholder, or (c) arrives as an in-place edit that the bridge doesn't re-surface.

Either way, the supervisor (orion via Claude Code) gets the noise but not the signal.

Expected

• Working/Received/Thinking/Processing progress messages MUST NOT be delivered to Claude Code via the MCP bridge.
• Only the final completion message for a given reply should be delivered.
• If the sentinel edits an initial message in place (message_updated events replacing content), the bridge should wait for an 'end state' (e.g., content no longer matches progress regex) before surfacing.

Current state

channel/server.ts DOES have a progress filter at line 419:

if (/^(Working|Received|Thinking|Processing)[\s.…]*/i.test(firstLine)) return;

But real-world messages containing 'Working… (48 tools)' and 'Working…' ARE being delivered (confirmed today, channel bridge restarted at 21:58 UTC — running latest code). Hypotheses:

1. Running binary lags source — /home/ax-agent/channel/ (the deployed dir) may not be the same as ax-cli/channel/ in git. Verify and sync.
2. Regex miss — the … character in source may be a different Unicode codepoint than what Hermes actually emits. Hermes could be using U+2026 (…) while test regex uses U+2026 too — but may have intervening chars.
3. Edit semantics — if Hermes edits the same message multiple times, the initial 'Working…' fires as a message event (before edit). It gets caught by filter. Then subsequent message_updated events arrive — the filter logic at line 364-367 allows updates to re-process, but if the new content starts with 'Working… (N tools)' it SHOULD still be dropped.
4. Something else — possible envelope difference or firstLine extraction bug.

Suggested fix

• Diagnose which of the above is happening (add debug log of filtered vs delivered messages).
• If hypothesis 1: add a deploy step / CI check that the running channel matches origin/main.
• If hypothesis 2: use startsWith with explicit U+2026 + fallback for ASCII '...'.
• If hypothesis 3: add additional heuristics — drop messages under N chars that look like single-word progress; drop tool-counting patterns like '(\d+ tools?)'.
• Consider surfacing a canonical 'message_complete' SSE event from the backend when the runtime marks a reply done, so bridges don't have to pattern-match content.

Impact

Supervisor (orion) noise-vs-signal ratio is broken. Bad flow for any Claude Code user supervising Hermes agents.

Related

• Prior fixes: commits 4b1aa17, 3221901, 5691cc3 — existing filter passes
• Bundled with image-message channel drop issue Channel bridge: MCP connection fails when inbound message contains an image #73