OpenClaw 2026.3.12: Faster Sessions, New Dashboard, and Security Defaults

OpenClaw 2026.3.12 is a pragmatic release: you get a more capable Control UI, a unified “fast mode” switch that works across chat/TUI/UI/ACP, and safer defaults around device pairing and plugin loading.

Source

GitHub release notes: v2026.3.12

1) A real “fast mode” you can flip per session (and verify)

If your usage pattern is “explore quickly, then tighten quality later”, this change removes a lot of friction.

What changed

A shared session-level fast toggle is wired through:
- chat command: /fast
- TUI
- Control UI
- ACP
The same toggle is mapped to provider-specific knobs:
- OpenAI/Codex: request shaping + per-model defaults
- Anthropic: direct service_tier requests (when using an API key tier that supports it)
The release mentions live verification for both Anthropic and OpenAI tiers, so you can tell whether your “fast mode” is actually being honored.

How to use it (practical)

Turn it on for the current session:

/fast on

When you’re done with a rapid iteration loop, turn it off:

/fast off

Why this matters operationally

You can keep “default = safe/quality” while still having an escape hatch for throughput.
It reduces accidental “fast everywhere” config drift because the toggle is session-scoped and shared.

2) Control UI / dashboard-v2: less hunting, more doing

The gateway dashboard refresh is not just visual polish: it adds structure and tools that support day-to-day ops.

Highlights called out in the release:

Modular views: overview, chat, config, agent, session views
Command palette
Mobile bottom tabs
Richer chat tools: slash commands, search, export, pinned messages

If you regularly debug sessions, export transcripts, or bounce between config + chat, this should cut your “where is that thing” time.

3) Security defaults that reduce footguns

Two changes here are worth treating as “read this before you upgrade” items.

Pairing codes now use short-lived bootstrap tokens

/pair and QR setup codes are switched to short-lived bootstrap tokens.
The explicit goal: the next release no longer embeds shared gateway credentials into chat or QR payloads.

Operational take:

Treat pairing as time-bound.
If you maintain internal docs, update any screenshots/scripts that assumed long-lived pairing secrets.

Workspace plugin auto-load is no longer implicit

“Disable implicit workspace plugin auto-load” so a cloned repository can’t execute workspace plugin code without an explicit trust decision.

Operational take:

If you relied on “clone repo → it runs a workspace plugin automatically”, expect to add an explicit trust/enable step.
This is a good change: it blocks a whole class of accidental supply-chain execution.

4) Model + tool-call reliability fixes (common pain points)

A few fixes in the changelog map to real-world breakages:

Kimi Coding tool calls: tools are sent in native Anthropic format again, avoiding the “tools degrade into pseudo XML/plain text” failure mode.
OpenAI Codex Spark: keeps gpt-5.3-codex-spark working via resolver fallbacks.
Ollama-hosted Kimi / Moonshot compatibility: wrapper applied so tool routing doesn’t break when thinking is enabled.
Moonshot CN baseUrl: explicit baseUrl resolution fixed to avoid 401 auth failures.

If your agents “suddenly stop calling tools” after a model switch, this release is worth the upgrade on that basis alone.

5) Cron/message delivery: fewer duplicate proactive messages after restarts

Isolated direct cron sends are kept out of the resend queue, preventing “transient-send retries” from replaying duplicate proactive messages after a restart.

If you run production reminders or scheduled summaries, this is the kind of fix that reduces user trust erosion.

Upgrade checklist (safe, minimal)

Upgrade as you normally do (your install method depends on how you deployed OpenClaw).
Re-test:
- /pair flow and any device onboarding docs
- any workspace plugins you depend on (explicit trust/enable)
- /fast behavior on the providers you use most
If you operate multiple surfaces (TUI + Control UI + chat channels), verify the fast toggle and model picker behavior across them.

FAQ for release-intent and upgrade triage

Is this a release worth prioritizing if your team mainly cares about operator speed, not new UI polish?

Yes, if your bottlenecks are session throughput, repeated surface switching, or noisy operational drift.

The highest-value changes here are not cosmetic:

the session-level /fast switch now works across chat, TUI, Control UI, and ACP
the dashboard refresh reduces the cost of finding session, config, and export controls
pairing and workspace-plugin defaults remove some easy-to-miss security mistakes

That combination makes this release relevant for operators even if they do not care much about interface aesthetics.

What should teams verify first after upgrading to 2026.3.12?

Start with the parts most likely to affect day-one operations:

whether /fast on and /fast off actually change behavior for your main provider
whether your pairing and onboarding flow still matches the new short-lived bootstrap-token model
whether any repo or workspace flow you rely on now needs an explicit trust step before loading plugins

Those three checks catch the most meaningful behavior changes faster than a generic smoke test.

If someone searches for "OpenClaw 2026.3.12 worth upgrading", what is the shortest honest answer?

If you want faster session toggling, a more usable dashboard, and safer defaults around pairing and plugin loading, this is a worthwhile upgrade.

If your current install is stable and you use none of those areas, the upgrade is still useful, but the urgency is lower.

Who should prioritize this update first?

This release should move up your queue if you are in one of these buckets:

operators switching between chat, TUI, Control UI, and ACP during the same workday
teams maintaining pairing or onboarding docs that can break when token lifetime assumptions change
admins relying on workspace plugins and wanting safer trust boundaries by default
model-heavy users who have recently seen tool-calling regressions after provider or baseUrl changes

If none of those apply, the release is still solid, but it is less urgent than for workflow-heavy operators.

What should operators verify immediately after upgrading, before calling the rollout successful?

Use a short post-upgrade checklist instead of a vague smoke test:

confirm /fast on and /fast off produce observable behavior changes on your main provider
confirm your pairing flow still works with short-lived bootstrap tokens
confirm trusted workspace plugins still load, and untrusted repos no longer auto-run plugins implicitly
confirm your most important tool-calling model still invokes tools correctly after the upgrade
confirm cron-driven proactive messages do not replay duplicates after a restart

That list covers the highest-risk changes in this release faster than browsing the UI and hoping nothing regressed.

References (from the release notes)

Dashboard refresh: PR #41503
sessions_yield for orchestrators: PR #36537
Plugin trust hardening (GHSA-99qw-6mr3-36qr): PR #44174

If you hit a regression that looks like “UI/chat weirdness after upgrade”, capture:

your surface (TUI / Control UI / channel)
your provider + model
whether /fast is on

…and include those in the issue report. It will save you a full back-and-forth cycle.