WhatsApp integration fails to reconnect after Agent Zero restart due to stale disconnected bridge

## Summary After restarting Agent Zero, the WhatsApp integration does not always reconnect correctly. The Node.js WhatsApp bridge process is started and remains alive, but WhatsApp itself stays disconnected. The bridge health endpoint reports `disconnected`, and the QR endpoint reports `waiting_scan`. In this state, the plugin appears to have a running bridge process, but messages are not handled because WhatsApp is not actually connected. ## Environment - Agent Zero: v1.16, if applicable - A0 CLI: v1.10, if applicable - Plugin: `_whatsapp_integration` - Bridge mode: `self-chat` - Bridge port: `3100` - Runtime: Docker / Linux container ## Observed behavior After restarting Agent Zero: - The WhatsApp integration plugin is enabled. - A Node bridge process is started. - The process uses a temp session path similar to: `--session /a0/tmp/whatsapp/session --cache-dir /a0/tmp/whatsapp/media` - The health endpoint returns a response similar to: `{ "status": "disconnected", "queueLength": 0, "uptime": 123 }` - The QR endpoint returns a response similar to: `{ "status": "waiting_scan", "qr": "..." }` - The bridge process remains alive, but WhatsApp is not connected. - The plugin does not reliably recover unless the bridge/plugin is manually stopped and restarted. - In some cases, QR pairing is required again. ## Expected behavior After an Agent Zero restart: - WhatsApp authentication/session state should survive the restart. - The plugin should not treat a live Node process as healthy unless the bridge reports `status: connected`. - If an existing bridge process is found but `/health.status` is `disconnected`, it should be treated as stale and restarted. - The poll loop should periodically check bridge health and recover from a live-but-disconnected bridge. ## Steps to reproduce 1. Enable the `_whatsapp_integration` plugin. 2. Pair WhatsApp successfully. 3. Restart Agent Zero / the A0 container. 4. Check the bridge process and health endpoint with commands such as: - `ps -eo pid,ppid,etime,cmd | grep -Ei 'whatsapp|bridge.js' | grep -v grep` - `curl -s http://127.0.0.1:3100/health` - `curl -s http://127.0.0.1:3100/qr` 5. Observe that the bridge process is alive, but `/health` reports `disconnected` and `/qr` reports `waiting_scan`. ## Suspected causes Based on local debugging, there may be a few related issues: 1. WhatsApp auth/session state appears to be stored under a temp path: `/a0/tmp/whatsapp/session` This may not be a safe persistent location across restarts or cleanup. 2. `bridge_manager.py` appears to treat a live Node bridge process as success in some paths, even when WhatsApp is not actually connected. 3. `_wait_for_bridge_startup()` may return success after a timeout even if the bridge never reaches `connected` state. 4. The poll loop does not appear to periodically restart a bridge that remains alive but disconnected. ## Possible direction for a fix Potential fixes could include: - Store WhatsApp session/media data under a persistent path, for example `/a0/usr/whatsapp/session` and `/a0/usr/whatsapp/media`. - Optionally migrate existing temp session/media directories once. - Only adopt an existing bridge after restart if `/health.status == "connected"`. - Kill/restart stale bridge processes that are alive but disconnected. - Do not return startup success when `require_connection=True` unless the bridge actually reaches `connected`. - Add periodic health checks in the poll loop and restart the bridge after repeated non-connected health checks. ## Workaround The current workaround is: 1. Disable the WhatsApp plugin. 2. Stop the stale Node bridge process. 3. Restart Agent Zero. 4. Re-enable the plugin. 5. Re-scan the QR code if necessary. This works temporarily, but the integration should ideally recover automatically after Agent Zero restarts.