“OpenClaw change was cancelled because its run ended”: the approval card, explained

What you are looking at

The two lines arrive in the same chat as the agent’s ordinary replies, marked with a warning sign and a tick:

⚠️ OpenClaw change was cancelled because its run ended
✅ OpenClaw change approved and applied

They are not from your agent. They come from what the docs call a “built-in system agent” that “speaks as ‘OpenClaw’” and handles “local setup, repair, and configuration” (it was called Crestodian before the 2.0 rename). When your agent decides a configuration change is the right response to what you asked (a new default model, a setting it needs), it hands the change to that system agent instead of writing the file. The system agent shows a plan, something like “Plan: restart the Gateway. Reply /openclaw yes to apply,” and does nothing until an owner says yes.

Why it was cancelled

The proposal lives inside the run that made it. The docs are specific: “If that run ends or loses authority during preparation, OpenClaw stops before starting the next persistent write,” and the result is “a non-applied outcome instead of leaving the agent reporting a pending change.” In practice that means the agent asked the question, you read it, and by the time you typed a reply the agent had already finished its turn and moved on. The change is dropped on purpose. A half-approved edit to a running agent’s configuration would be worse than no edit. Pending write approvals also expire on their own after 15 minutes, so an approval typed the next morning has nothing to approve.

Here is the sequence as we watched it on one of our own machines, on OpenClaw 2026.9.1 over Telegram. The owner asked the agent to make a different model its default. The agent proposed the change; the owner read it, and the turn ended first: the warning line appeared. The owner asked again, and this time typed “approved” while the proposal was open. The tick line appeared, the configuration reloaded within a second, and no restart was needed. One detail worth knowing from that same session: the conversation kept answering on the model it had been pinned to with /model -s until that pin was cleared, because a session-scoped pick outranks the default. The default had changed; the chat in front of us had its own opinion.

What counts as approval

The approval is deliberately unforgiving. The docs describe “a closed deterministic list” of accepted replies, phrases like “yes,” “sure,” “go ahead,” and “not now” to decline, and the permission-modes page adds the sentence that explains the whole design: “conversational claims of approval never authorize the change.” Your agent saying “the owner agreed” authorizes nothing. Only a message from an explicit owner identity does; the docs rule out “wildcard sender rules, open group policy, unauthenticated webhooks, or anonymous channels” as sources of a yes. A session running with full access applies its operations automatically, which is the one configuration where you will never see the card.

The reason is the one that governs every agent with tools: an agent that can rewrite its own configuration is an agent that a poisoned web page can reconfigure. Routing every change through an owner-approved, audited operation (“every applied rescue operation is audited”) closes that door without taking the capability away.

Getting it to land first time

• Reply while the proposal is open, in one short word from the list. “Yes” and “go ahead” work; a paragraph of caveats may not parse as approval.
• If you missed the window, just ask again. Nothing was half-applied; the docs note that only workspace files the agent created earlier in the turn are left in place.
• Check the result with the command that reads the setting rather than by asking the agent: /model for the default model, /think for the reasoning effort, openclaw config get <key> for anything else.
• Some Gateway-level changes still need openclaw gateway restart to take effect; the docs say so for those. A model default did not, in our session.
• If you are in a conversation that carries its own /model or /think pin, clear it (/model default -s, /think default) before expecting the new default to show up there.