Found three issues running hermes claw migrate --overwrite --migrate-secrets against a real OpenClaw install.

Environment

• Hermes Agent v0.12.0 (2026.4.30)
• Linux 6.17, Python 3.11.15, OpenAI SDK 2.32.0
• Source: optional-skills/migration/openclaw-migration/scripts/openclaw_to_hermes.py

1) WhatsApp channel block is silently dropped during migration

channels.whatsapp from openclaw.json is not written into whatsapp: in config.yaml, even though Discord's channel config IS migrated. After migration:

whatsapp: {}

Source openclaw.json had:

"whatsapp": {
  "enabled": true,
  "dmPolicy": "open",
  "allowFrom": ["*"],
  "groupPolicy": "open",
  "sendReadReceipts": true,
  "ackReaction": {"emoji": "👀", "direct": true, "group": "mentions"}
}

--migrate-secrets does bring WHATSAPP_ALLOWED_USERS into .env, but the channel block itself is never ported. Result: WhatsApp is effectively disabled post-migration even when the user had it configured. Expected: a whatsapp-config migration item analogous to whatever migrates the Discord side.

2) --overwrite on full-providers appends instead of upserting

Re-running with --overwrite against a config.yaml that already had a claude-max entry under custom_providers: produced a duplicate entry (same name twice, contents identical). YAML still parses, but the migrator should upsert by provider name.

Repro: have custom_providers.claude-max already defined → run hermes claw migrate --overwrite --migrate-secrets → observe claude-max listed twice.

3) hermes gateway status reports stale PIDs as running

After a transient hermes gateway run subprocess exited, hermes gateway status still reported:

✓ Gateway is running (PID: <stale_pid>)

…but kill -0 <stale_pid> failed and nothing was bound on the gateway port. Suggested fix: kill -0 the PID (or read /proc/<pid>/comm to confirm it's the gateway binary) before reporting "running".

Happy to PR fixes if maintainers want — flagging first.