Release Notes

v3.3.1 — 2026-08-15

• The outbound guard now refuses to send from a Gmail send-as alias whose SMTP relay is broken. Such a send fails silently: Gmail stamps the message SENT and drops the delivery failure into Trash, so the sender believes it arrived and the recipient never gets it. The check runs ahead of every path that would otherwise allow the send, including a held approval and the approved-recipient bypass, because a broken relay bounces the mail whoever it was addressed to.
• When a service account can impersonate the alias, the block message names the command that works. Sending as the mailbox over the API skips the send-as relay entirely and needs no app password, so a "broken" alias is often already reachable.
• New refresh_broken_aliases.py builds the alias list from Gmail's own bounce threads, reading the failed alias off the SENT message's From header rather than matching addresses in the bounce body. --clear <address> drops an alias after a repair, and an absent or empty list blocks nothing.
• New gog-sa-token mints a narrow-scope impersonated token. gog requests its whole scope bundle in one call, so a Workspace that delegated only gmail.send and gmail.readonly refuses the entire request, and a mailbox that can in fact send looks unreachable.
• New tests/outbound-guard/test-broken-alias.py covers the alias path against a throwaway HOME, and clears the shared approval store afterwards so the other guard suites stay order-independent.

v3.3.0 — 2026-08-15

Added

• Shared outbound guard that gates every outbound send through one code path, with matching hook entry points for Python and Node callers.
• Test suite for the guard covering the hook matrix, false positives, and shared-guard behaviour.
• Approval helper for granting a send, plus a README documenting how the gate works and how to wire it up.

Changed

• ops-comms and ops-inbox now route sends through the shared guard instead of their own checks.

v3.1.5 — 2026-08-15

Added: bin/ops-fleet-pool-snapshot fetches a sanitized read-only CLIProxyAPI pool snapshot from a remote helper over ssh, and ops-fleet is reworked into a read-only session plus gateway dashboard that uses it. The helper restricts the remote path to a plain safe-character path, rejects a destination or user beginning with a dash so ssh cannot read it as an option, confines the timeout to digits, and validates the remote output as JSON before emitting it. Fixed: ops-inbox now rechecks the live thread tail immediately before every send. Approval is not a license to fire a stale draft, so between the approval and the send call it re-reads the real channel for new inbound arriving after the draft was staged and for replies already sent from another session, the phone, or a different client, and rebuilds or drops the draft instead of double-replying. A scan from earlier in the same run does not count as current state.

v3.1.4 — 2026-08-15

Fixed: apply-patches.py Fix Q no longer appends a duplicate /api/app_state_status route. The idempotency sentinel matched the comment above the handler, which Fix Y later rewrote, so on any Fix-Y tree the check missed and a second http.HandleFunc for the same path was appended. Go panics at startup on a duplicate pattern, so the bridge died on the next go build. The sentinel is now the handler registration itself. Fixed: the plugin no longer assumes the WhatsApp MCP server is named whatsapp. Multi-account installs run one bridge and one server per account (whatsapp-) and have no plain mcp__whatsapp__*, so every hardcoded reference failed with an unknown tool. Adds CLAUDE.md Rule 8 (resolve the name at runtime, pick the account deliberately, never reply from the wrong number, Rule 6 applies to every variant) and points ops-inbox, ops-comms, comms-scanner and scripts/whatsapp/ENDPOINTS.md at it. Also warns that allowed-tools entries are exact strings and that host send-gate hook matchers pinned to the literal mcp__whatsapp__send_message stop firing silently when an account is renamed or added.

v3.1.3 — 2026-08-15

ops-merge no longer scans or merges repos the owner cannot push to. The registry lists every locally cloned project, including upstreams we only read, so the queue filled with unrelated contributors' PRs in repos we do not own. Push access is now checked fail-closed immediately before every create, merge and push, --repo is no longer exempt, the scanner accepts both --repo and a bare slug, and OPS_MERGE_INCLUDE_EXTERNAL takes a single slug instead of acting as a global bypass.

v3.1.2 — 2026-08-10

Runtime-first ops-speedup: CPU/RAM/GPU/PID/DNS/TCP health scoring, safer demotion defaults, and CI harness fixes.

v3.1.1 — 2026-08-03

• Update the Telegram server's transitive Hono dependency to 4.13.0, fixing GHSA-8j4g-w8fx-2239 (CORS middleware ReDoS).

v3.1.0 — 2026-08-03

• Added a portable CLIProxyAPI account provider with health, account inventory, and utilization support in ops-accounts.
• Standardized CLIProxyAPI discovery across CLIPROXYAPI_AUTH_DIR, CLIPROXYAPI_HOME, and XDG_CONFIG_HOME, with explicit environment configuration for optional proxy endpoints.
• Hardened release automation with required CI and CodeQL checks, bounded GitHub queries, stable-head verification, and exact-SHA squash merges without branch-protection bypass.
• Updated ip-address from 10.2.0 to 10.4.0 in the plugin and Telegram server dependency trees.
• Updated Telegram server fast-uri from 3.1.4 to 3.1.5, including the upstream security fix.
• Preserved existing release notes during first-time and interrupted GitHub wiki synchronization.
• Fixed gateway execution through symlinked or canonical paths and added a clear 503 response when the optional Grok endpoint is not configured.
• Removed ShellCheck warnings from the touched account and release commands.
• Removed deployment-specific browser login, CAPTCHA, reauthentication, and subscription automation from the public plugin.

v3.0.0 — 2026-08-03

Upgraded @hono/node-server to 2.0.12 for security and performance fixes, and aligned the Telegram server minimum runtime to Node.js 20+ (#771).