Good initiative adding native WhatsApp support. The whatsmeow-based approach removes the need for an external bridge, which is a significant UX improvement. However, there are several issues that need addressing before this is merge-ready.

Critical issues

1. agentMu serialization bottleneck: The new agentMu sync.Mutex in loop.go serializes ALL message processing (processMessage, processSystemMessage, ProcessHeartbeat) across ALL channels through a single global mutex. This means if a Telegram message takes 30 seconds to process, every WhatsApp/Discord/Slack message queues behind it. This is a major regression for multi-channel deployments. The original design processes messages concurrently by design. If the goal is to prevent heartbeat/message races, scope the lock to per-session or per-agent rather than global.

2. Security: message content logged in base.go: The added log.Printf("Not Allowed: Received message from %s: %s", senderID, content) logs the full message content of rejected senders. This leaks user message content into logs. At minimum, truncate the content or remove it entirely.

3. Security: no message content validation: handleIncoming passes raw WhatsApp message content directly to the agent without any sanitization. While the existing channels do the same, WhatsApp messages can contain zero-width characters, RTL overrides, and other Unicode control characters that could confuse the LLM or cause display issues.

4. Empty messages forwarded: If both GetConversation() and ExtendedTextMessage.GetText() return empty (e.g., image-only, sticker, location messages), the empty string is still forwarded to the bus and processed by the agent. Add a if content == "" { return } guard.

Architecture concerns

5. log.Printf vs logger.InfoCF: The native channel uses raw log.Printf while the rest of the codebase uses the structured logger package. This should be consistent.

6. No reconnection handling: The whatsmeow client can disconnect (network issues, WhatsApp server restarts). There is no reconnection logic. The events.Disconnected event should be handled to attempt reconnection with backoff.

7. No media support: The comment says "for now we only forward text" but WhatsApp is heavily media-oriented. At minimum, document this as a known limitation or file a follow-up issue.

8. Heavy dependency footprint: whatsmeow + modernc.org/sqlite adds ~25 new transitive dependencies (visible in go.sum). For a project called "picoclaw" (ultra-lightweight), this is worth calling out. The whatsmeow approach is valid, but consider making it a build tag (e.g., //go:build whatsapp_native) so users who do not need it do not carry the binary size cost.

Minor

9. The agentMu changes in loop.go are unrelated to WhatsApp and should be a separate PR. Mixing concurrency model changes with a new channel implementation makes both harder to review and revert.

Please address items 1 (global mutex), 2 (content logging), and 4 (empty message) at minimum.

Thanks for addressing most of the feedback. Checked the new diff:

Fixed:

• Empty message guard is in place (if content == "" { return }) — good.
• Content sanitization via SanitizeMessageContent is a solid addition, and the test coverage is appreciated.
• Structured logging via logger.InfoCF replaces raw log.Printf — good.
• Reconnection with backoff in handleDisconnect looks solid.

Still outstanding:

1. Global mutex in loop.go — The comment on line 265 says "It uses the same mutex as processMessage so heartbeat and user messages never run concurrently." But I don't see the actual agentMu field or Lock()/Unlock() calls in the diff for loop.go. Either this was addressed differently (via runAgentLoop serialization?) or the comment is stale. Could you clarify how heartbeat/message concurrency is handled now? The original concern was about a single global mutex serializing ALL channels — if that's been scoped to per-session, that's fine.

2. content_preview still logged at INFO — Both base.go (line 572, 80-char truncated) and the WhatsApp handler (line 924, 50-char truncated) log message content previews at INFO level. While truncation helps, INFO-level logs are often shipped to external log aggregators where message content shouldn't appear. Consider moving these to DEBUG level, or making content logging opt-in via config. This was item 2 in the original review (slightly different form — now it's truncated rather than full content, which is an improvement, but still INFO).

3. shell_test.go permission literal changes — The 0755 → 0o755 and interface{} → any changes in shell_test.go are cosmetic and unrelated to WhatsApp. They should go in a separate cleanup PR to keep this diff focused. (Same feedback as item 9 in original review about mixing concerns.)

Items 1 and 2 are the remaining blockers from the original review. Item 3 is minor but worth splitting out.

I haven't thoroughly reviewed the code because there are many non-compliant areas in the directory and the scope of changes.
We hope to minimize the scope of changes for each PR. This PR modifies packages including build, agent, utils, etc., which are unrelated to the channel.