Description

When a user enables WhatsApp via hermes setup (or manually sets WHATSAPP_ENABLED=true in .env), there is no corresponding way to disable it through the normal Hermes UI/CLI workflow.

Steps to Reproduce

1. Run hermes setup and enable WhatsApp
2. Try to disable WhatsApp later via:
   • hermes tools → WhatsApp not listed
   • hermes gateway setup → no "disable platform" option
   • hermes config edit → no whatsapp.enabled field, only whatsapp: {}
3. WhatsApp bridge keeps launching on every hermes gateway run

Root Cause

The WhatsApp platform is enabled via an environment variable (WHATSAPP_ENABLED=true in ~/.hermes/.env), not via config.yaml. This is an asymmetric enable/disable mechanism:

• Enable: env var or setup wizard
• Disable: must manually edit .env (invisible to average user)

The gateway code that checks this is in gateway/config.py (lines 1074-1079):

whatsapp_enabled = os.getenv("WHATSAPP_ENABLED", "").lower() in ("true", "1", "yes")
if whatsapp_enabled:
    config.platforms[Platform.WHATSAPP] = PlatformConfig()
    config.platforms[Platform.WHATSAPP].enabled = True

Other platforms (Feishu, Telegram, Discord) are enabled by having credentials configured — if you remove the credentials, the platform stops. WhatsApp is different because it uses a standalone env var.

Compounding Bug: WhatsApp Bridge Process Leak

Additionally, the WhatsApp bridge (scripts/whatsapp-bridge/bridge.js) appears to leak processes. When the gateway is restarted or the bridge reconnects, new Node.js processes are spawned without cleaning up old ones. In one observed case, 39 WhatsApp bridge processes were running simultaneously, each consuming 400-600MB of memory — totaling ~22GB on a 32GB system.

Expected Behavior

1. hermes gateway setup should include an option to disable platforms, not just configure them
2. Platform enable/disable should be symmetric — if you can enable via setup, you should be able to disable via setup
3. The WhatsApp bridge should detect and clean up existing processes before spawning new ones
4. Consider moving WHATSAPP_ENABLED into config.yaml for consistency with other platforms

Environment

• Hermes version: latest (installed via install script)
• OS: WSL2 (Windows Subsystem for Linux)
• WhatsApp bridge: scripts/whatsapp-bridge/bridge.js via Baileys

Impact

• User experience: confusing and frustrating — platform can't be turned off
• Resource leak: ~20GB+ memory wasted on zombie WhatsApp processes
• Particularly problematic on WSL2 where memory is shared with Windows host

Suggested Fix

1. Add a "disable platform" flow to hermes gateway setup
2. Add process deduplication to WhatsApp bridge's connect() method
3. Unify platform enable/disable to use config.yaml (or at minimum, ensure hermes tools / hermes gateway setup can toggle WHATSAPP_ENABLED)