OpenClaw Drops BlueBubbles, Defaults to ChatGPT Login, and Rewires Codex Security Assumptions

The End of a Bridge

BlueBubbles served as OpenClaw's iMessage gateway for over a year. It worked — mostly. But it was always a third-party dependency sitting between the AI assistant and Apple's messaging stack, adding latency, complexity, and a maintenance surface that the OpenClaw team didn't control.

That chapter is now closed. OpenClaw has formally removed the BlueBubbles channel and consolidated everything behind its native imsg iMessage integration. A dedicated announcement document explains the rationale and provides a step-by-step migration path for existing BlueBubbles users.

The migration isn't a simple config swap. OpenClaw ships a new --channel flag on the channels status command that lets operators probe iMessage connectivity before routing live traffic. The recommended approach is cautious: verify the native channel is healthy, then cut over. The configuration guide now includes a full actions block for iMessage, covering attachments, catch-up mode, and group chat settings that BlueBubbles handled differently.

For operators who were already running the native channel, nothing changes. For BlueBubbles holdouts, the clock is ticking — the old channel code is gone, not just deprecated.

Six Tapbacks, Three Modes

In the same breath as killing BlueBubbles, OpenClaw taught its native iMessage channel to understand tapbacks. Previously, when someone loved or laughed at a message in an iMessage thread, the AI assistant either ignored it or treated it as a new text message — confusing the conversation flow.

Tapbacks now route through OpenClaw's reaction system as proper typed events. The six supported types — love, like, dislike, laugh, emphasize, and question — map directly to iMessage's built-in tapback vocabulary. Three notification modes control how they surface: "own" (the default) only triggers on reactions to the bot's own messages, "all" fires for any authorized sender's reactions, and "off" silences them entirely. Per-account overrides let operators fine-tune the behavior across multiple iMessage accounts on the same gateway.

ChatGPT First, API Key Second

Running --provider openai in OpenClaw's CLI used to drop users into an API key configuration flow. That made sense when OpenAI's consumer products were separate from their API platform. It makes less sense now that ChatGPT accounts can authenticate directly, and the Codex runtime has become the default for OpenAI agents.

The new default routes users through ChatGPT OAuth login with device-code pairing as a fallback. API key configuration is still available but requires an explicit --method api-key flag. The auth wizard lists ChatGPT login and device-code options before the API key path, signaling a clear preference hierarchy.

For existing deployments with API keys already configured, nothing breaks. The change affects new setups and re-authentication flows. But it signals a broader shift in how OpenClaw thinks about OpenAI integration: consumer-grade authentication first, developer-grade second.

Two Changes, Opposite Directions

Sunday shipped two Codex security changes that seem to contradict each other. The first tightens sandbox permissions. When an OpenClaw sandbox is active, Codex app-server turns are now automatically constrained to workspace-write — even if the Codex configuration specifies danger-full-access. The documentation now explicitly warns against mounting the host Docker socket into agent sandbox containers, closing a path that could have let a sandboxed agent escape its container.

The second change flips a default in the opposite direction. Migrated Codex plugins now have destructive actions enabled by default. Previously, allow_destructive_actions defaulted to false, requiring operators to explicitly opt in after migrating native plugins. The new default is true.

These aren't contradictory — they address different trust boundaries. Sandbox constraints protect the host system from agent behavior. Destructive action defaults control whether plugins can perform write operations within their authorized scope. Tightening the outer wall while opening the inner door is a coherent security posture: agents can do more within their sandbox, but the sandbox itself is harder to escape.

The Loop That Wouldn't Die

OpenClaw's tool loop detection has historically been cautious. Generic repeated calls — the same tool with the same parameters returning the same result — would generate warnings but never actually stop the agent. The rationale was avoiding false positives: sometimes legitimate work looks repetitive.

That caution has a cost. When an agent genuinely gets stuck in a no-progress cycle, it burns through API tokens, consumes compute, and produces nothing useful. The updated loop detection now escalates from warning to blocking when identical calls produce identical outcomes at the critical threshold. The key distinction is “no progress” — if the tool returns different results each time, the loop isn't flagged. Only perfectly static cycles get killed.

No More Ghost Sessions

When an OpenClaw gateway shut down or restarted, any sessions that were still active simply vanished from the process without firing their session_end hooks. Plugins that maintained session state — memory stores, analytics trackers, billing systems — were left with orphaned records that never got finalized.

The gateway now runs a bounded drain during SIGTERM and SIGINT signals, firing typed session_end hooks for every tracked active session. The reason field distinguishes between shutdown (process stop) and restart (expected restart), joining the existing vocabulary of session end reasons: new, reset, idle, daily, compaction, and deleted. Sessions that were already finalized get skipped to prevent duplicate firing.

The drain is intentionally bounded — slow handlers can't block process exit. This is infrastructure work that most operators will never notice, but plugin developers who maintain persistent state across sessions will stop finding unexplained orphaned rows in their data stores.

The Rest of the Stack

Three smaller documentation updates rounded out Sunday's batch. Media generation tools — both music and video — now honor configured timeout values instead of silently using hardcoded defaults. If you've set agents.defaults.videoGenerationModel.timeoutMs in your config and wondered why your video generation still timed out at the old threshold, that's fixed.

The Control UI gained a static HTML fallback panel that displays when the main app module fails to register within twelve seconds. Instead of a blank white page, operators now see actionable troubleshooting guidance: disable browser extensions with broad content scripts, try a private window, verify gateway connectivity. It's the kind of defensive UX that should have existed from day one.

And the project's build infrastructure completed its pnpm 11 migration, updating native dependency policies from the old onlyBuiltDependencies syntax to the new allowBuilds configuration format. Not glamorous, but anyone building from source will notice.

Documentation Changes at a Glance

What This Day Tells You

Sunday's changes have a theme, even if the team didn't plan it that way: replacing borrowed infrastructure with owned infrastructure. BlueBubbles was borrowed — now it's native iMessage. OpenAI API keys were borrowed credentials — now it's ChatGPT's own auth. Permissive sandbox defaults were borrowed trust — now the system enforces its own boundaries.

The Codex security pair is the most interesting read. Tightening the sandbox while loosening destructive action defaults looks like a contradiction until you understand the trust model: give agents more power inside a box they can't escape. It's the same pattern that container runtimes have used for years — broad capabilities inside narrow isolation. Whether OpenClaw's implementation of that pattern is airtight remains to be proven at scale, but the architecture is sound.

The session end hooks change is the one that will matter most to plugin developers. Ghost sessions were a known pain point for anyone building persistent integrations. The bounded drain is a pragmatic compromise — it won't wait forever for slow plugins, but it gives well-behaved ones enough time to clean up. That's the kind of infrastructure reliability that enables an ecosystem, even if no one writes blog posts about it.