Abu Bakar Ramzan

Posted on May 8

How I Fixed a Crashed AI WhatsApp Agent for NOVVEX in One Live Session

#ai #docker #automation #linux

The Problem
NOVVEX, a business running an AI-powered WhatsApp agent to handle customer communication, reached out to me with a critical situation.

Their AI agent, built on OpenClaw, running on a Hetzner Linux VPS — had completely stopped working. The Docker container was crashing every 30 seconds and restarting in a loop. The dashboard was inaccessible. WhatsApp messages were coming in with no replies going out. The business was effectively offline.

The client had tried to add a DeepSeek API key through the dashboard UI. When it wouldn't accept it, he ran a bash command to force it in. The key got saved — but something broke in the process, and the container never recovered.

He needed it fixed. Fast.

My Approach
I joined a live call and connected to the server remotely via VS Code's SSH extension. The goal was simple: diagnose first, fix second. Don't touch anything until we know exactly what's wrong.

Step 1 — Read the crash logs

docker logs --tail 80 openclaw-openclaw-gateway-1

The logs showed the container starting, getting through configuration and authentication, then dying silently with exit code 1. No clean error message. Just:

[gateway] loading configuration... [gateway] resolving authentication... [gateway] starting... [DEAD]
Exit code 1 with no visible error meant something was crashing the process from inside — not a config parse error, not an OOM kill. Something deeper.

Step 2 — Find the config files

find /root/openclaw -type f -name "*.json" | xargs ls -la
This revealed the key files:

/root/openclaw/config/openclaw.json — main gateway config
/root/openclaw/config/agents/main/agent/auth-profiles.json — API credentials
/root/openclaw/config/agents/main/agent/models.json — AI model configuration

Step 3 — Read each file

The auth-profiles.json revealed the first problem:

{ "openai": { "apiKey": "sk-xxxxxxxxxxxx", "baseURL": "https://api.deepseek.com" } }
The DeepSeek key had been saved under the "openai" provider name, but the base URL was pointing to DeepSeek's endpoint. This mismatch was causing authentication to fail on every startup.

The models.json had a second problem — the DeepSeek API key was stored as a placeholder string "DEEPSEEK_API_KEY" instead of the actual key value.

But neither of these explained the silent crash.

Step 4 — Catch the crash live

docker start openclaw-openclaw-gateway-1 && docker logs -f openclaw-openclaw-gateway-1
Watching the live stream revealed the real killer:

[openclaw] Unhandled promise rejection: CIAO PROBING CANCELLED [openclaw] wrote stability bundle openclaw-gateway-1 exited with code 1

CIAO PROBING CANCELLED — this was a Bonjour/mDNS network probe. Bonjour is Apple's local network discovery protocol. OpenClaw uses it to announce its presence on local networks.

On a Hetzner cloud VPS, there is no local network to broadcast on. The probe runs, finds nothing, fails hard, and throws an unhandled promise rejection that crashes the entire Node.js process. Every single time.

This was the root cause. Not the API key. Not the config. A background network plugin silently killing the container.

The Fix
With the full picture clear, the fix had three parts:

Fix 1 — Disable the Bonjour plugin permanently

nano /root/openclaw/config/openclaw.json

Added to the plugins section:

"plugins": { "entries": { "deepseek": { "enabled": true }, "bonjour": { "enabled": false } } }
One line. Permanent. No more crashes.

Fix 2 — Fix the API credentials

Updated auth-profiles.json with the correct provider structure:

{ "openai": { "apiKey": "sk-xxxxxxxxxxxx", "baseURL": "https://api.deepseek.com/v1" }, "deepseek": { "apiKey": "sk-xxxxxxxxxxxx", "baseURL": "https://api.deepseek.com/v1" } }
Fix 3 — Set DeepSeek as the default model

Updated openclaw.json to lock in DeepSeek as the permanent default:

"agents": { "defaults": { "model": "deepseek/deepseek-chat" } }

Fix 4 — Add the API key to the environment

Added directly to the .env file so it persists across container restarts:

OPENAI_API_KEY=sk-xxxxxxxxxxxx OPENAI_API_BASE=https://api.deepseek.com
Restart and verify:

cd /root/openclaw && docker compose down && docker compose up -d docker logs -f openclaw-openclaw-gateway-1
Logs confirmed:

[gateway] loading configuration... [gateway] resolving authentication... [gateway] starting... [gateway] starting HTTP server... [gateway] agent model: deepseek/deepseek-chat [gateway] ready (7 plugins: acpx, bonjour, browser, device-pair, phone-control, talk-voice, whatsapp) [heartbeat] started
No crashes. Clean startup. DeepSeek confirmed as active model.

WhatsApp Connection

With the container stable, the final step was connecting WhatsApp:

docker exec -it openclaw-openclaw-gateway-1 openclaw channels login --channel whatsapp
This generated a QR code. The client scanned it with his phone via WhatsApp Linked Devices. Connection established.

Test message sent. Bot replied. Done.

OpenClaw working on whatsapp

The Result

✅ Container running stable 24/7
✅ DeepSeek AI responding to every WhatsApp message
✅ NOVVEX AI MANAGER live and handling customer communication automatically
✅ Permanent fix — no more crashes on restart

What the client said:

"Abu Bakar fixed a critical bug in my AI agent setup that had completely taken it down. His technical expertise made the whole process smooth and fast. Highly recommend his work." — NOVVEX Client

Working OpenClaw dashboard

What I Learned

The most dangerous bugs on production servers are the silent ones. Exit code 1 with no error message could mean a hundred different things. The approach that worked here — reading live logs, isolating each config file, catching the crash in real time — is the same approach I use on every server debugging session.

The Bonjour crash is also worth noting for anyone running OpenClaw or similar Node.js applications on cloud VPS environments. Bonjour is designed for local networks. On a cloud server it has nothing to probe and will crash the process if not disabled.

Tech Stack Used