Plugin Documentation Gets a Navigation Overhaul
OpenClaw's plugin ecosystem has grown considerably in 2026. The documentation, however, was still organized as though the plugin system was a single concern. A flat “Building plugins” section tried to serve three distinct audiences simultaneously: operators installing plugins, developers building them, and maintainers working on the plugin infrastructure itself. None of those groups were well served by sharing a sidebar.
That section is now split into three dedicated reference tiers. The Plugin Reference covers plugin inventory, dependency resolution, and install overrides — the operational surface that administrators interact with. The Plugin SDK Reference homes in on the developer surface: subpath conventions, entrypoint contracts, runtime hooks, agent harness integration, setup, testing, and manifest authoring. And a new Plugin Maintainer Reference collects the internal architecture documentation, migration guides, compatibility matrices, and channel-specific technical details that were previously scattered across the building section.
The top-level “Plugins” section now focuses purely on installation and management, while “Bundled plugin guides” retains its own space. A new channel ingress SDK page was added to the SDK reference as part of the reorganization.
No existing routes were removed. Every page that had a URL before still has the same URL now. The reorganization is purely navigational — a nav-audit script confirmed zero broken links after the change.
It's a structural change that reflects a maturity milestone. When a project's plugin system is simple enough for one docs section, that's fine. When it has an SDK, a maintainer internals layer, and a growing list of bundled extensions, the flat structure becomes a tax on every reader who has to scroll past content written for someone else.
The OpenAI Gateway Learns Token Caps
OpenClaw's OpenAI-compatible HTTP gateway — the endpoint that lets any OpenAI SDK client talk to OpenClaw agents — now supports two request parameters that developers have been expecting: max_completion_tokens and max_tokens.
The first is the preferred field, matching the Chat Completions API convention. The second is treated as a legacy alias for backward compatibility. When both are present in the same request, the newer max_completion_tokens takes precedence. Values are forwarded to upstream providers with the field name selected based on what each provider expects.
The practical effect: developers who use OpenClaw's gateway as an OpenAI drop-in can now control generation length per-request, the same way they would against OpenAI directly. It also means orchestration frameworks that set token budgets — like LangChain, LlamaIndex, or custom cost-control layers — no longer have their caps silently ignored when routed through OpenClaw.
Docker Deployments Stop Losing OAuth Credentials
If you ran OpenClaw in Docker and used OAuth-backed auth profiles — for example, connecting a ChatGPT or Codex account through the browser-based login flow — there was a quiet problem: the encryption key that protected those stored tokens lived inside the container. Every docker compose down && docker compose up destroyed it. The tokens were still on disk, but the key to decrypt them was gone. Every rebuild forced a full re-authentication.
A new environment variable, OPENCLAW_AUTH_PROFILE_SECRET_DIR, now points to a host-mounted directory where the encryption key is persisted. The Docker setup script creates this directory with 600 permissions, adds the appropriate volume mount to the Compose configuration, and ensures ownership is fixed during prestart. The key directory is kept separate from the main config directory — a deliberate isolation choice that prevents backup scripts from accidentally sweeping up cryptographic material alongside configuration files.
For existing Docker operators: the setup script handles creation of the new directory automatically. After the next update, OAuth-backed auth profiles survive container rebuilds without re-authentication.
Telegram Stops Escaping Its Own HTML
Telegram's Bot API supports a specific subset of HTML: bold, italic, underline, strikethrough, code, pre, blockquote, and links. Everything else gets rejected. OpenClaw's Telegram integration handled this by escaping all HTML before sending — the safest possible approach, and the laziest. The result: when a model replied with <b>important</b>, users saw the literal text <b>important</b> instead of important.
The fix introduces a tag-validation layer that identifies Telegram's supported HTML tags and preserves them through the rendering pipeline, while continuing to escape anything the Bot API would reject. A separate change removes the generic plain-text sanitizer from the Telegram outbound adapter, which was double-escaping content that the new tag-aware renderer had already handled.
The documentation update is a single line: “Raw model HTML is escaped to reduce Telegram parse failures” becomes “Supported Telegram HTML tags are preserved; unsupported HTML is escaped.” One sentence. But the behavior change behind it is significant for anyone whose agents generate formatted output.
Migration Keyboard Controls Get a Quiet Fix
A smaller documentation update landed for the Codex migration CLI. The interactive migration selector — the prompt where operators choose which Codex skills to migrate — had a keyboard interaction problem: pressing Enter was supposed to activate the highlighted row and continue, but it wasn't behaving correctly when items were pre-selected. The “Skip for now” and bulk-selection rows in particular were affected.
The migration documentation now clarifies the intended controls: Space toggles individual rows, Enter activates the highlighted row and proceeds. The underlying code was also fixed to match, with a new reconciliation function that handles Enter key activation without deselecting previously chosen items.