Messaging Gateway Troubleshooting
SkillCommunicationmessaging-gateway-troubleshooting — Troubleshoot Hermes messaging gateway platform adapters, webhooks, authorization, delivery, and loop-prevention behavior.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Messaging Gateway Troubleshooting skill
What this skill tells your AI
The instructions your AI receives, as published by atlasomnia/hermes-custom-pack in skills/messaging-gateway-troubleshooting/SKILL.md and read by ahel’s review.
Use this when Hermes messaging platforms are installed/configured but messages do not arrive, are ignored, do not reply, or appear to risk reply loops.
Operating principles
- Verify the live path end to end before assuming config is wrong:
- Gateway service is running.
- Platform server/client is running.
- Local webhook/listener is bound.
- Health endpoint responds if available.
- Platform has the webhook registered.
- Gateway logs show the adapter connected.
- Separate transport, authorization, and adapter filtering:
- Transport failure: no webhook hit / listener closed.
- Authorization failure: sender not allowed or pairing pending.
- Adapter filtering: message acknowledged but intentionally skipped, e.g. group mention gating, tapback filtering, or self-message loop guard.
- For user-visible claims, verify with real command output:
hermes status, listener checks, webhook health, and gateway logs. - When changing Hermes gateway config or adapter code, restart the gateway and verify the adapter reconnects.
- For gateway slash-command failures, inspect session-origin scope separately from transport health:
- Compare
source,user_id,chat_id,thread_id, andorigin_jsonin the live session database. - Trace both the listing path and the action path; a session browser is still broken if it lists a target that
/resumerejects. - In forum/threaded platforms, distinguish same-parent-chat ownership from exact-thread isolation rather than weakening origin checks globally.
Telegram forum session browsing
- A fresh Telegram forum topic can have no prior exact-thread sessions even when the same owner has many titled sessions in sibling topics of the same parent chat.
- Do not diagnose this from session history alone. Correlate gateway send logs, live DB origin columns, and the gateway routing origin.
- Cross-topic browsing must be Telegram-specific, same-parent-chat, and same-owner;
thread_sessions_per_user=falsepermits sharing within one thread, not across sibling threads. - Keep
/sessionsvisibility and/resumeauthorization aligned, including persisted-only rows. - See
references/telegram-forum-session-scope.mdfor the reproduction, authorization contract, TDD matrix, and safe activation procedure.
BlueBubbles / iMessage notes
- BlueBubbles may mark messages from the Mac's own Apple ID/iMessage identity as
isFromMe=true. - A blanket
isFromMeskip prevents reply loops but also prevents the owner from texting Hermes from that same iMessage identity. - The safer loop guard is outbound-ID based: remember Hermes-sent
tempGuidand returnedguid/messageGuid, then ignore only inbound webhook echoes whose IDs match that cache. - On macOS, do not assume
localhostreaches an IPv4-only Hermes webhook. BlueBubbles/Electron/Node may resolvelocalhostto IPv6::1, causingconnect ECONNREFUSED ::1:<port>whilecurl http://127.0.0.1:<port>/healthstill works. Register local BlueBubbles webhooks ashttp://127.0.0.1:<port>/...unless Hermes is listening on IPv6 too. - See
references/bluebubbles-self-imessage-loop-guard.mdfor the concrete fix pattern, localhost/IPv6 pitfall, stale-webhook cleanup, and verification loop. - See
references/memory-context-injection-probes.mdfor probe handling when recalled-memory wrappers, formatting-failure echoes, or outbound test messages appear in a live platform chat.
Verification checklist
hermes statusshows the platform configured.- Gateway process/service is running under the expected profile/home.
- Listener exists for the adapter webhook port/path.
- Webhook health returns success if implemented.
- Platform-side webhook registration points at the active Hermes listener.
- Logs show adapter connected and webhook registered.
- A test message reaches the adapter or produces a pairing/authorization signal.
Pitfalls
- Do not confuse “gateway open” with “message authorized.” A listener can be healthy while the sender is ignored by allowlist/pairing logic.
- If Telegram is fast for text but a photo/image turn appears to run forever, inspect
agent.logfor repeated API calls ending inTypeError: expected string or bytes-like object, got 'list'from_interim_assistant_visible_text→strip_think_blocks. This was a multimodal block-list regression introduced by Codex interim-commentary handling; a current upstream release fixes the loop. Stop the affected turn, update Hermes through the normal update-safe procedure, reapply local patches, restart the gateway, and verify with a real photo+caption message. Transport latency and gateway health can look completely normal while this retry loop burns up to the agent iteration cap. - Do not persist negative claims like “BlueBubbles ignores self messages” as a permanent tool limitation. The durable lesson is the loop-guard design.
- Do not edit protected bundled skills; place Hermes-gateway-specific operational learnings here when bundled skills cannot be patched.
Public support files
references/bluebubbles-self-imessage-loop-guard.mdreferences/memory-context-injection-probes.mdreferences/telegram-forum-session-scope.md
Signals
- GitHub stars
- 56
- Forks
- 5
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
messaging-gateway-troubleshooting- Source
- github.com/atlasomnia/hermes-custom-pack