Bug: OpenClaw 2026.5.12 silently rebinds WhatsApp sessions to a trimmed runtime; agent loses all tools, gateway returns misleading "billing error"

Filed against: openclaw/openclaw
Affected version: 2026.5.12 (regression vs 2026.5.3-1, which is known-good)
Severity: high — full loss of agent functionality on the WhatsApp channel; misleading user-facing error masks the root cause
Discovered: 2026-05-18 ~00:49 BST after upgrading from 2026.5.3-1 to 2026.5.12

TL;DR

After upgrading to 2026.5.12, all WhatsApp messages to my running OpenClaw agent ("Paige") fail with one of two misleading errors:

⚠️ API provider returned a billing error — your API key has run out of credits or has an insufficient balance.

⚠️ Missing API key for provider "anthropic". Configure the gateway auth for that provider, then try again.

The real root cause is the WhatsApp channel session is silently bound to a different runtime ("OpenClaw Pi Default") with a different auth surface and a heavily-trimmed toolset, even when agents.defaults.agentRuntime.id is explicitly set to claude-cli. OAuth via Claude Max is healthy throughout. No migration note alerts the user; nothing in the gateway warnings flags the runtime swap; no telemetry surfaces the toolset reduction.

Three distinct sub-bugs

1. Silent runtime rebinding for the WhatsApp channel

Before upgrade — WhatsApp sessions inherit from agents.defaults and bind to claude-cli runtime → use my Claude Max OAuth → free, fully-toolled assistant.

After upgrade — WhatsApp sessions bind to a runtime labelled OpenClaw Pi Default, visible via session_status inside the WhatsApp thread:

🪡 Session: agent:main:whatsapp:direct:+447736454506 · updated just now
⚙ Execution: direct · Runtime: OpenClaw Pi Default · Think: off · Reasoning: on

openclaw.json is unchanged across the upgrade — agents.defaults.agentRuntime.id = "claude-cli" was set both before and after. No config edit was made. No CLI command was run that would have changed the runtime. The rebinding is invisible to the user.

Expected: the WhatsApp channel keeps using the configured agentRuntime (claude-cli).
Actual: silently swapped to OpenClaw Pi Default with no log, no warning, no migration note.

2. Trimmed runtime ("Pi Default") strips the agent of every workspace tool

The new "Pi Default" runtime exposes only session-inspection tools:

• sessions_list
• sessions_history
• sessions_send
• session_status

It is missing — relative to the claude-cli runtime — every workspace tool the agent normally has, including:

• file Read / Edit / Write
• exec / Bash
• browser
• peekaboo
• nodes (camera/screen)
• cron
• skill execution
• gateway tool actions (config.get / config.patch / restart)
• the OpenClaw message tool
• ... and the dozens of provider tools (gmail, github, browser-automation, etc.)

For an agent whose entire identity, memory, and operating context live in ~/.openclaw/workspace/ — this is the practical equivalent of full amnesia and paralysis mid-incident. The agent cannot read its own memory, cannot run a diagnostic, cannot write to its journal, cannot inspect its own config. The only thing it can do is reply with plain text via the existing message stream, which is itself blocked by sub-bug #3.

The trimmed runtime should at minimum:

• (a) refuse to run when the configured agentRuntime.id is not pi-default, OR
• (b) surface a visible warning ("⚠️ Running on degraded runtime — N of M tools available") on every reply, OR
• (c) be opt-in, not opt-out, on upgrade.

It should never be the silent fallback.

3. Misleading user-facing error for what is actually a runtime-binding/auth issue

Because Pi Default attempts the direct anthropic API path (rather than OAuth via Claude CLI), and the user account has no anthropic API key configured (because the whole point of Claude Max + claude-cli is that you don't need one), the user sees:

⚠️ API provider returned a billing error — your API key has run out of credits or has an insufficient balance. Check your provider's billing dashboard and top up or switch to a different API key.

This caused me to (a) panic, (b) top up Anthropic API credits I did not need (those credits now sit dormant), and (c) chase a billing problem for ~90 minutes before correctly diagnosing the runtime binding as the actual fault.

The same flow also produces:

⚠️ Missing API key for provider "anthropic". Configure the gateway auth for that provider, then try again.

Both messages are technically true at the API layer but misleading at the user layer — the gateway has perfectly good OAuth credentials, it just isn't using them because the runtime has been silently swapped.

Expected: if a runtime upgrade rebinds a channel to an auth path that isn't configured, the error should say so:

Channel whatsapp was rebound to runtime pi-default during upgrade. That runtime requires an anthropic API key, but none is configured. Either configure a key, or set agentRuntime.id: claude-cli on this channel/agent.

Compounding issue: Claude CLI first-run state blocks OAuth fallback

Even after re-running openclaw models auth login --provider anthropic --set-default, the WhatsApp channel still didn't resolve OAuth. Investigation found Claude CLI v2.1.126 was installed but never completed first-run on the user account — it was sitting on the welcome screen / theme picker.

It would be useful for openclaw models auth login --provider anthropic (claude-cli option) to detect this state and either:

• complete first-run non-interactively where possible, or
• surface a clear message: "Claude CLI v2.1.126 is installed but has not completed first-run setup. Open a terminal and run claude once to dismiss the welcome screen, then re-run this command."

Right now it silently succeeds and the user has no way to know the auth flow is incomplete.

What actually fixed it (workaround)

A pre-built local rollback script (~/Desktop/PAIGE-ROLLBACK-TO-OAUTH.command) restored the pre-2026.5.12 gateway wrapper. That immediately unblocked WhatsApp messages — agent responsive again, full toolset restored.

The user-built rollback should not be the only viable recovery path. Recommend adding either:

• a documented openclaw downgrade <version> command, or
• a documented snapshot/rollback flow that doesn't depend on user-authored shell wrappers.

Downgrade path was also broken

Tonight I attempted a manual downgrade from 2026.5.12 back to 2026.5.3-1. The downgrade process hung partway through — Paige unresponsive again, terminal stuck. Recovery required a hard shutdown of the Mac. On reboot, the downgrade had completed (npm/state had progressed past the hung step) and the agent came back fully online on 2026.5.3-1 with OAuth + full toolset.

Two issues there:

• Downgrade should not hang.
• If it does, there should be a documented recovery path that doesn't involve a forced power-off.

Reproduction

1. Configure OpenClaw with:
   • agents.defaults.agentRuntime.id = "claude-cli"
   • Claude Max OAuth authenticated and working
   • WhatsApp channel paired and a recent test message exchange working on 2026.5.3-1
2. Upgrade to OpenClaw 2026.5.12.
3. Send a WhatsApp message to the agent.
4. Observe: reply is ⚠️ API provider returned a billing error... or ⚠️ Missing API key for provider "anthropic"...
5. From the WhatsApp thread, invoke session_status — note Runtime: OpenClaw Pi Default (NOT claude-cli).
6. Inspect ~/.openclaw/openclaw.json — confirm agentRuntime.id = "claude-cli" is still set.
7. Attempt to read any file via the agent — note that file tools are not available in the session.

Environment

• macOS 24.6.0 (arm64)
• Node v22.22.2
• OpenClaw 2026.5.12 (regression); confirmed working on 2026.5.3-1
• Channel: WhatsApp (via OpenClaw native WhatsApp adapter)
• Model: anthropic/claude-opus-4-7 via Claude Max OAuth (claude-cli runtime)
• Owner allowlist: commands.ownerAllowFrom = ["+447736454506"]

Attached evidence

• Screen recording of the broken WhatsApp thread (00:49–03:48 BST 2026-05-18) — 7 keyframes available on request.
• Pre-edit config: ~/.openclaw/openclaw.json.before-owner-edit
• Pre-rollback config: ~/.openclaw/openclaw.json.bak
• Local rollback script that fixed it: ~/Desktop/PAIGE-ROLLBACK-TO-OAUTH.command (not shared publicly — workspace-specific paths)

Suggested triage priorities

1. P0: Stop silently rebinding channel sessions to Pi Default on upgrade.
2. P0: Replace the "API provider returned a billing error" message when the real cause is a runtime/auth misconfiguration. Misleading users into spending money on unnecessary API top-ups is a serious product correctness issue.
3. P1: Document the Pi Default toolset boundary and surface a visible "degraded runtime" indicator when it is in use.
4. P1: Document or provide a first-class downgrade path that doesn't require a hard reboot.
5. P2: Fix the Claude CLI first-run-not-completed detection in models auth login --provider anthropic.

Filed by: Daniel Crick (info@hiddenhome.tech, +447736454506) on behalf of Paige, the OpenClaw-resident assistant who was unable to file this herself last night because she had no file or exec tools.