OpenClaw 2026.3.2 Breaking Changes: What to Check Before and After You Update

OpenClaw 2026.3.2 shipped a lot of fixes and one major new tool, but the release is most likely to trip operators on three changes: tool access defaults, ACP dispatch, and plugin HTTP registration.

If a previously normal setup suddenly lost read, write, or exec, started routing ACP turns you did not expect, or broke a plugin webhook after the upgrade, start here.

Quick Checklist

1. Back up ~/.openclaw/openclaw.json.
2. Run openclaw doctor.
3. Run openclaw config validate.
4. Check openclaw config get tools.
5. If you use ACP bindings, inspect acp.dispatch.enabled.
6. If you maintain plugins, search your code for registerHttpHandler(.
7. Run openclaw gateway restart.
8. Confirm the instance is healthy with openclaw health.

For the underlying commands, see OpenClaw CLI Commands. For a broader config walkthrough, see OpenClaw Configuration: The Settings That Actually Matter.

1. Tool Access Is the Messiest Part of This Release

This is the change that caused the most confusion right after the release.

The v2026.3.2 release notes say onboarding now defaults tools.profile to messaging for new local installs. Community reports in discussion #32815 show several operators restoring read, write, and exec access after changing a tools block that had become more restrictive.

There is one wrinkle: the current configuration reference still says local onboarding defaults new configs to coding when tools.profile is unset. Because those two sources do not line up cleanly, do not guess from defaults alone. Check the value in your own ~/.openclaw/openclaw.json first.

messaging is a narrow profile. It is meant for message delivery and session tools, not general coding or shell work. If you expected read, write, apply_patch, or exec, this is the first place to look.

If your file currently contains this:

{
  "tools": {
    "profile": "messaging"
  }
}

and you want the usual filesystem and runtime tools back, set the profile explicitly in ~/.openclaw/openclaw.json:

{
  "tools": {
    "profile": "coding"
  }
}

Use coding if you want the normal file and runtime toolset. Use full if you intentionally want no profile-level restriction. Leaving the profile unset is also equivalent to full.

That is also why you may see people suggest this shorter fix:

{
  "tools": {}
}

That advice is not magic. It simply removes the restrictive base profile.

Helpful reference:

• minimal: only session status
• messaging: message and session tools
• coding: filesystem, runtime, sessions, memory, image
• full: no profile restriction

After changing the file, run:

openclaw config validate
openclaw gateway restart
openclaw health

If the main session recovers but a routed channel session still does not, inspect any per-agent overrides under agents.list[].tools. Agent-level profiles and allow/deny rules can still restrict a channel-specific agent even when the global tools.profile is correct.

2. ACP Dispatch Is On Unless You Turn It Off

OpenClaw now enables ACP dispatch by default. The exact switch is acp.dispatch.enabled.

That matters if you use ACP bindings or ACP-backed agents and you only wanted /acp controls available on the server, not automatic turn routing. You now need to disable dispatch explicitly if that is still the behavior you want.

This is the config shape to check:

{
  "acp": {
    "enabled": true,
    "dispatch": {
      "enabled": false
    }
  }
}

Set acp.dispatch.enabled to false when you want /acp controls to remain available but do not want ACP to claim incoming turns automatically.

If you are not using ACP at all, this section is not the likely cause of your issue. If you are using persistent ACP bindings, it should be one of the first settings you verify after the update. The current ACP docs are here: ACP Agents.

3. Plugin HTTP Handlers Need a Code Change

If you maintain OpenClaw plugins, 2026.3.2 removed api.registerHttpHandler(...).

The replacement is api.registerHttpRoute({ path, auth, match, handler }). Dynamic webhook lifecycles should move to registerPluginHttpRoute(...).

The practical migration step is simple: search your plugin codebase for the old method name and replace every occurrence before you restart on 2026.3.2.

rg "registerHttpHandler\\(" .

Two details matter during the migration:

• Routes are now explicit. You register a route object instead of a single handler function.
• Auth is no longer implicit. Route registration now expects you to declare the auth behavior for that path.

If a plugin starts failing right after the upgrade and the failure mentions HTTP routes, webhook registration, or duplicate path handling, this is almost certainly why.

Safe Update Flow for 2026.3.2

If you have not updated yet, this is the low-drama order:

1. Back up ~/.openclaw/openclaw.json and your plugin code.
2. Update OpenClaw using your normal install path.
3. Run openclaw doctor.
4. Run openclaw config validate.
5. Check tools.profile, acp.dispatch.enabled, and any plugin route code.
6. Run openclaw gateway restart.
7. Run openclaw health and test one real message from a connected channel.

That sequence matters. openclaw doctor catches migrations and service issues. openclaw config validate catches invalid keys before the gateway tries to boot. Restarting only after both checks makes the failure mode much easier to understand.

If you update with openclaw update, remember that command already runs openclaw doctor and restarts the gateway by default. The extra openclaw config validate pass and the final health check are still worth doing after you inspect the changed settings.

Symptom to Cause Map

One More Thing: Validate Before You Restart

2026.3.2 added openclaw config validate. Use it.

That command is especially useful in this release because all three breaking changes can lead to startup confusion for different reasons: changed defaults, changed dispatch behavior, or changed plugin registration. Validating first gives you a precise config or schema error instead of a vague "the gateway seems wrong" moment.

If you want a broader reference after the upgrade, use the OpenClaw configuration reference, the official OpenClaw 2026.3.2 release notes, and the OpenClaw updating guide.