Hermes Update —2026-06-10

What changed

Added a new Step6d-OPT block to 40-Projects/claude-oauth-safety-guardrails/sops/update-gate.md. It explicitly prompts BB before running the Claude Code CLI and Hermes Anthropic smoke tests. If BB says skip, the SOP logs that decision and continues to step7a.

Why we changed it

The smokes cost live API calls (5s each, negligible but real tokens) and only matter if BB is actively using Claude/Anthropic. During the2026-06-10 update, BB was on OpenCode Go (minimax-m3). Running the smokes by default would have spent calls on a route BB didn't need. The agent should ask, not assume.

Impact

Where it lives

40-Projects/claude-oauth-safety-guardrails/sops/update-gate.md — lines288-313. Renumbered6d → opt-in Claude Code CLI check,6e → opt-in Hermes Anthropic smoke.

What changed upstream

The530-commit window added a new _handle_polling_network_error pattern at gateway/platforms/telegram.py:948+. It does what our local _recover_degraded_send_path patch did: reset the httpx connection pool used for getUpdates polling, re-call start_polling(), verify the long-poll is actually alive after restart.

Reconciliation

Per the SOP source-vs-config rule and reconciliation pattern: drop our local patch. Upstream ships the equivalent. Add to 50-Areas/Hermes-Infra.md: remove the _recover_degraded_send_path entry from the "known patches" list. No behaviour change for us — same resilience, cleaner upstream pattern.

Impact

What was lost

Our2026-05-24 patch added a custom config key platform_pause_after_failures + env override HERMES_GATEWAY_PLATFORM_PAUSE_AFTER_FAILURES to keep Telegram polling on retryable network failures instead of auto-pausing after10. The update clobbered both. gateway/run.py no longer reads the config key or env var. Default behaviour is now: pause Telegram after10 consecutive failures (same as pre-patch stock).

Why it was added originally

Mac-sleep / hotel-Wi-Fi scenarios were repeatedly causing Telegram to go dead. The auto-pause was too eager —10 failures on a flaky connection would kill the bot for the whole outage. The override kept the bot retrying until the network came back.

Impact

What we checked

• Orchestrator skill (~/.hermes/skills/productivity/orchestrator/SKILL.md v2.0.0) — stock is v3.0.0. Upstream changelog showed only docs changes (d17c953a5, fda66c488). No behavior drift this update. Merge task (logged2026-06-06) still pending but no new drift.
• Worker skills (researcher, coder, writer, etc.) — docs-only upstream changes. No behavior drift.
• memory-gate hook (~/.hermes/hooks/memory-gate/handler.sh) — still wired and active. Upstream now ships write_approval config + inline prompt as a new layer. Our hook is orthogonal (stricter: requires literal "save to memory" / "yes save" in recent transcript). Keep both.
• network_watchdog.py — untouched (May21 file, hermes update doesn't touch it).
• Profile skill symlinks — all7 survived update (verified).

What it is

Your2026-05-24 patch added a custom config key platform_pause_after_failures and env override HERMES_GATEWAY_PLATFORM_PAUSE_AFTER_FAILURES. Together they tell the gateway: "never auto-pause Telegram on retryable network failures, just keep retrying indefinitely." The2026-06-10 update clobbered it. Default behaviour is back to: auto-pause Telegram after10 consecutive failures.

What it does (when working)

On a Mac that drops Wi-Fi, sleeps, or has a flaky hotel connection, the gateway's Telegram polling would hit network errors. Without the patch, after10 retries it gives up and marks the platform as paused. With the patch, it keeps retrying until the network comes back. You avoid having to manually /platform resume telegram every time.

Why it was added

The2026-05-24 incident: Telegram kept going dead on the Mac whenever the hotel Wi-Fi dropped or the laptop slept. The10-failure threshold was being hit constantly during normal travel. You added the override because auto-pause was making things worse, not better.

Cost to re-apply

• Time:5 min. Two source edits in gateway/run.py + one env line in .env.
• Risk: Low. Same code we already shipped. Will get clobbered on next Hermes update (recurring cost).
• Ongoing: ~2 min per future update to re-apply. Maybe automate via patch script.
• Money: Zero.

Pros of re-applying

• Telegram survives Mac-sleep / Wi-Fi drops automatically.
• No need for /platform resume telegram after every outage.
• Matches the behaviour you actually want for a portable Mac.

Cons of re-applying

• Source patch — gets clobbered on every Hermes update.
• May mask real failures (e.g. credential revocation) instead of pausing and alerting.
• No upstream PR — you're carrying private infra.

Pros of accepting default

• Zero maintenance — works with stock Hermes.
• Gateway auto-pauses on real failures, alerting you via launchd exit codes + logs.
• Matches what most users have.

Cons of accepting default

• Telegram will go silent on every Mac-sleep / Wi-Fi drop.
• You'll need /platform resume telegram (or hermes gateway restart) after every outage.
• Direct regression from the2026-05-24 incident.

Recommendation

How to re-apply

# Edit gateway/run.py to read the env override


# (sed patch — exact line varies per Hermes version, search for 'auto-paused')





# Add to ~/.hermes/.env


# HERMES_GATEWAY_PLATFORM_PAUSE_AFTER_FAILURES=0





# Restart gateway


# hermes gateway restart

What it is

During the update, hermes update tried to restart the gateway via launchd. launchctl reported "Service definition is stale relative to current Hermes install" and bootstrap failed with exit5 (Input/output error). Hermes fell back to running the gateway as a background process. That bg process is up now (PID9635) and Telegram polling works, but it has two consequences:

1. No auto-restart on crash. If the gateway process dies, launchd won't bring it back. You have to manually hermes gateway start.
2. No auto-start on login/reboot. If the Mac reboots while you're away, the gateway won't come back up until you log in and run it.

What running hermes gateway start does

Refreshes the plist definition (path: ~/Library/LaunchAgents/ai.hermes.gateway.plist) to match the current Hermes install, then re-bootstraps it under launchd. After that, the gateway is properly managed: auto-start on login, auto-restart on crash, normal exit code semantics.

Cost

• Time:30 seconds. One command.
• Risk: Very low. Gateway briefly restarts (Telegram polling reconnects in ~5s).
• Money: Zero.

Pros of refreshing

• Auto-restart on crash — safety net restored.
• Auto-start on login/reboot — Telegram comes back without your intervention.
• Proper exit code semantics — easier to debug if something goes wrong.
• Matches the normal Hermes setup pattern.

Cons of refreshing

• Telegram will briefly disconnect during the restart (~5s).
• If something else is wrong (auth, network), restart won't fix it and you'll see the same failure mode again.

Pros of staying on bg-process mode

• No action needed right now.
• Gateway is currently working.

Cons of staying on bg-process mode

• No auto-restart on crash — single point of failure.
• No auto-start on reboot — gateway won't be live when you return.
• Defeats the purpose of having a launchd-managed service.

Recommendation

How to refresh

hermes gateway start


# Verify:


hermes gateway status


# Should show: 'Gateway service is loaded' + PID + clean timestamps

What it is

Our custom orchestrator skill at ~/.hermes/skills/productivity/orchestrator/SKILL.md is v2.0.0. Stock Hermes ships skills/devops/kanban-orchestrator/SKILL.md v3.0.0 with meaningful improvements (goal_mode cards, stuck-worker recovery, hallucination detection, better decomposition rules). This drift was first logged2026-06-06. The2026-06-10 update added no new drift — task unchanged.

What the merge would do

Read both side by side. KEEP our BB-specific sections (verify-before-design, orchestrator SOUL companion note, named profile examples). ADOPT stock improvements (goal_mode, stuck worker recovery, hallucination detection, improved decomposition rule wording). BUMP version to3.0.0 after merge. TEST with a real kanban dispatch.

Cost

• Time:30-60 min. Careful skill merge, then a test dispatch.
• Risk: Medium if rushed — orchestrator is a load-bearing skill. Drift would cause slow degradation, not sudden breakage.
• Money: Zero.

Pros of merging now

• Get goal_mode + stuck worker recovery — useful for the kanban workload.
• Align with upstream — easier to merge in future.
• Close out the carry-over item.

Cons of merging now

• Takes30-60 min of careful work.
• If rushed, can break the orchestrator profile.
• No time pressure — drift is documented, not breaking anything.

Pros of deferring

• Current orchestrator still works (verified2026-06-10).
• No immediate user-visible problem.
• Can batch with other skill work later.

Cons of deferring

• Gap grows wider each release Hermes ships.
• Same failure class as the v0.14→v0.15 orchestrator deadlock (D-044) — drift can become blocking.
• Stays in your outstanding list.

Recommendation

How to merge

1. Open both files side by side: ~/.hermes/skills/productivity/orchestrator/SKILL.md (ours) + ~/.hermes/hermes-agent/skills/devops/kanban-orchestrator/SKILL.md (stock).
2. Use diff or read end-to-end. Note the sections.
3. Apply the merge plan above.
4. Bump version to3.0.0.
5. Test: hermes kanban assignees + dispatch a small task via the orchestrator profile.

What it is

The env-var credential CLAUDE_CODE_OAUTH_TOKEN in ~/.hermes/.env is dead. Hermes resolves env-var credentials before the healthy Keychain + file credentials, so any request that hits the env-var path returns401. The Keychain + file tokens are fresh (~7.7h remaining) but the resolver picks the wrong one first.

Why it was deferred

You're on OpenCode Go (minimax-m3) right now, not Claude. The failure doesn't bite. If/when you switch back to Claude/Anthropic, requests will fail until this is fixed.

What the fix does

Open Claude Code, type /login, complete the browser OAuth, exit. That writes a fresh access token + refresh token to macOS Keychain. Mirror the credentials file via the hermes-claude-auth installer. Reset Hermes's credential pool so it re-discovers both. Restart the gateway.

Cost when you do it

• Time:2 min for the login,30s for the mirror,30s for the reset,10s for the restart.
• Risk: Low. Same SOP-001 pattern that worked2026-06-06.
• Money: Zero.

Pros of doing it now

• Clean auth state across all sources.
• No failure if you suddenly need Claude.

Cons of doing it now

• Requires interactive /login in Claude Code (cannot automate — needs browser).
• If you're not using Claude, it's wasted effort.

Pros of deferring

• No effort now.
• System works fine on OpenCode Go / Kimi / GPT.

Cons of deferring

• If you switch to Claude and forget, first request fails.
• Keychain token is still expiring in ~7.7h — will need fresh login within a day regardless.

Recommendation

How to fix (when ready)

#1. Open Claude Code interactively


claude


# Then inside the TUI: /login → browser OAuth → /exit





#2. Mirror credentials to file


cd ~/Documents/ClaudeCode/hermes-claude-auth && ./install.sh





#3. Reset Hermes pool


hermes auth reset anthropic





#4. Restart gateway


hermes gateway restart





#5. Smoke (OPT-IN now, per new SOP)


# hermes chat -q 'Reply with exactly: AUTH TEST OK' \


# --provider anthropic -m claude-sonnet-4-6 -Q


# (NEVER use 'claude setup-token' — requires TTY, fails silently from automation)