OpenClaw Exposes Full Prompt Layer Stack, Auto-Repairs Broken Plugins, and Ships Chat Width Controls

The Whole Prompt, Not Just Your Part

OpenClaw's prompt snapshot system is how operators and contributors verify what the AI model actually receives during a conversation. Until now, those snapshots only rendered the application-server components: developer instructions, parameters, user input, and dynamic tool definitions. The upstream Codex model instructions — the GPT-5.5 permission boundaries, safety directives, and behavioral constraints that sit above everything else in the prompt stack — were implicit. You knew they were there, but you couldn't inspect them.

That gap is now closed. Prompt snapshots render the complete reconstructed model-bound layer stack: Codex permission instructions, OpenClaw runtime directives, user inputs, tool references, and token estimates. Each snapshot includes an explicit disclaimer that this is a “deterministic reconstructed layer view, not a byte-for-byte raw OpenAI request,” which is an important distinction — the actual API payload may differ in encoding, but the semantic content is now fully visible.

A new synchronization script lets maintainers refresh the pinned Codex prompt from local model cache files, and CI now includes drift detection that catches any prompt composition changes that aren't accompanied by regenerated snapshots. The snapshot fixture directory was also renamed from a generic happy-path to codex-runtime-happy-path to accurately reflect what it actually contains.

For operators debugging unexpected agent behavior, this is a meaningful quality-of-life improvement. Instead of guessing what the model is working with, you can now see the full context stack in a single snapshot. For contributors, CI enforcement means prompt changes can't slip through without updated documentation.

Self-Healing Plugin Infrastructure

OpenClaw's plugin system supports configured downloadable plugins — extensions declared in config that get automatically installed from ClawHub or npm. The problem was that these installations could silently fail or break during upgrades, and the only way to fix them was manual intervention. The doctor command could detect the problem but couldn't do anything about it.

The new repair pass changes that. When running in doctor repair mode, OpenClaw will now detect missing or broken configured plugin installations and automatically reinstall them. The system prefers ClawHub as the installation source with npm as a fallback, records the installed state through existing index writers, and only marks the repair as complete when no warnings remain. The repair is gated behind explicit doctor repair mode — it won't run during normal startup, which is a deliberate security choice.

Documentation across six pages was updated to reflect the new capability, including the CLI doctor reference, gateway doctor guide, and testing documentation. The upgrade-survivor test suite also gained new fixtures to validate the repair path across version boundaries.

Wide Monitors Get Their Due

The Control UI's chat column has been locked to max-width: min(900px, 68%) since launch. On a standard 1080p display, that's fine. On a 4K ultrawide, it's a narrow strip floating in a sea of empty space. The configuration path that would fix this simply didn't exist.

A new gateway.controlUi.chatMessageMaxWidth setting accepts CSS width values: plain pixel or percentage values like 960px or 82%, and bounded functions including min(), max(), clamp(), calc(), and fit-content(). The setting includes input validation that rejects injection attempts — url(), semicolons, and var() references are all blocked.

Under the hood, the CSS now uses a custom property with the original value as its fallback: var(--chat-message-max-width, min(900px, 68%)). Existing deployments see no change. Operators who want wider chat on their ultrawide setups can set it and forget it. The configuration reference and Control UI documentation have both been updated.

No More Heartbeat Stampedes

OpenClaw's heartbeat system allows plugins and internal services to wake the background agent for health checks and scheduled tasks. The wake mechanism previously accepted unstructured string reasons — callers would pass something like "exec-complete" or "notification-arrived" and hope the system understood the intent.

The new implementation replaces those strings with typed source and intent fields. A notification plugin waking the agent now explicitly declares its origin and whether the wake is immediate, deferred, or manual. More importantly, a centralized flood-gate applies cooldown to event-driven wake paths — exec completions, notification arrivals, spawn events, and retries all pass through the gate. Manual wake-now calls from operators bypass it, which means an admin can always force a heartbeat even during high-activity periods.

This addresses a long-standing issue where multiple concurrent events could trigger duplicate heartbeat runs, wasting compute and creating confusing overlapping status reports. The SDK runtime documentation has been updated to reflect the new typed wake API, and the deprecated runtime.system.requestHeartbeatNow() call remains as an alias for backward compatibility.

Cache the Plan, Load the Plugin Only When Needed

Every time OpenClaw plans which tools to present to the AI model, it previously called each plugin's tool factory to get schema definitions, descriptions, and parameter shapes. For a deployment with a handful of plugins, the overhead was negligible. For one running a dozen extensions with complex tool registrations, it added measurable latency to every turn.

The new descriptor cache captures validated tool metadata at registration time — when a plugin calls api.registerTool(), the schema, description, and parameter definitions are stored keyed by plugin source, contract, and request context. Subsequent planning requests hit the cache instead of reloading the plugin. Actual execution still loads the full plugin runtime, so behavior is unchanged — only planning gets the speedup.

The cache includes a 256-entry eviction limit to prevent unbounded memory growth, and the plugin building documentation and tools index have both been updated to describe the new caching behavior. Plugin developers don't need to change anything — the cache is transparent to registration callers.

The Bigger Picture

Taken individually, these are incremental improvements. Taken together, they reveal a platform maturing in the right directions. Prompt transparency lets operators actually verify what their AI is working with instead of trusting implicit assumptions. Self-healing plugin infrastructure reduces the maintenance burden of running a production deployment. Configurable UI respects the reality that people use different hardware. Typed wake scheduling eliminates a class of duplicate-work bugs that waste compute. And descriptor caching makes the whole plugin system feel snappier without requiring any changes from extension authors.

None of these are flashy headline features. All of them are the kind of work that separates a project you tinker with from one you trust to run in production.