Approving dangerous changes
A dangerous change waits for you on the dashboard’s Approvals page when you
have no authenticator app set up. An ordinary write only needs your OK in the
chat. A dangerous write also needs the current code from your authenticator app
or, without one, an approval at /approvals. That approval is yours alone,
lasts 10 minutes and covers one send.
What does Claude need before it changes the controller?
Section titled “What does Claude need before it changes the controller?”The answer depends on the write and on your organisation’s write guard policy. The guard checks these in order:
| Situation | What happens | What Claude gets back |
|---|---|---|
| Your role is viewer or operator | Refused, whatever the policy | write_blocked: “This person’s role in the organisation (operator) is read-only, so this write was not sent. An org admin can change their role.” |
| Read-only mode is on | Refused | write_blocked: “Read-only mode is on for this organisation, so this write was not sent. An org admin can turn read-only mode off on the dashboard.” |
| Confirm every write is off | Sent at once, logged as “guard off” | The result |
| An ordinary write | Not sent. Claude shows you a preview and re-sends once you agree | confirm_required, with a preview and a confirm token |
| A dangerous write, and you have an authenticator app | Not sent. You agree, then give Claude the current 6-digit code | confirm_required, then totp_required |
| A dangerous write, and you have no authenticator app | Not sent. You approve it on the dashboard | approval_required, with a link to /approvals/<id> |
A write is dangerous when it matches a ticked category on the Dangerous actions list, or one of your organisation’s own rules, and Extra check for dangerous actions is on. With that check off, a dangerous write needs only the confirm in chat.
The diagram shows the same order as the table. A viewer or operator, or any
write in read-only mode, stops at write_blocked. A write that is not dangerous
needs your agreement in chat. A dangerous write needs a code if you have an
authenticator app, and a dashboard approval if you do not. Each path ends with
the write sent once.
How do I approve a change on the dashboard?
Section titled “How do I approve a change on the dashboard?”Open the link Claude gives you, or go to Change › Approvals in the sidebar. The sidebar shows a count of approvals waiting for you.
The Approvals page lists what is waiting under Waiting, each row marked REVIEW. With nothing waiting it reads: “Nothing is waiting. When Claude asks for a dangerous change (a reboot, a firmware upgrade, a restore), it shows here and in the sidebar count.” The same list appears as Waiting for your approval on the Write guard card at Configure › Controller.
Each approval opens at /approvals/<id> under the heading Claude wants to
make a dangerous change, with these cards:
| Card | What it shows |
|---|---|
| The change | The action (method and path), what it does, the API (Wi-Fi (WSG) or Switch (SwitchM)), why it needs approval (the matching category or rule), the fields sent and when it was requested |
| What it sends | The request body, with secret-looking values shown as ••• |
| Current state | The target as it was read just before the request, when it could be read |
| Decision | Approve and Deny |
The page warns: “Check that this is what you asked for. If you didn’t ask for it, deny it: names and messages on the network can try to talk Claude into actions.”
Once you decide, the page shows one of these:
| Status | Text on the page |
|---|---|
| Approved | ”Approved. Claude can now send it (once).” |
| Denied | ”Denied. Claude will not send it.” |
| Used | ”Approved and already sent.” |
| Expired | ”This request expired. Ask Claude to try again if you still want it.” |
Can someone else approve my change?
Section titled “Can someone else approve my change?”No. An approval belongs to the person whose chat asked for the change. The Approvals page lists only your own approvals, and only you can approve or deny them. An organisation admin cannot approve on behalf of an engineer. If the person asking cannot approve, the alternative is for them to set up an authenticator app on the Write guard card.
How long does an approval last?
Section titled “How long does an approval last?”10 minutes, for one send.
| Step | Limit |
|---|---|
| Approving or denying | Within 10 minutes of the request. After that it is expired, and Claude must ask again, which creates a new approval |
| Claude waiting for your decision | await_approval waits up to 15 seconds per call, then reports pending, approved, denied, used, expired or not_found |
| Sending | Claude re-sends the identical request with the approval id. The approval is then used and cannot cover a second send |
| The list | Shows at most 20 pending approvals |
If Claude re-sends before you decide, it gets approval_pending: “The user has
not approved this on the dashboard yet.” If you denied it, it gets
approval_denied: “The user denied this action on the dashboard. Do not retry
it unless the user asks again.”
How is a MOP approval different?
Section titled “How is a MOP approval different?”A MOP with writes is approved once for the whole run, not once per write.
mop.start goes through the same guard as a single write: a MOP whose steps
are ordinary writes is confirmed in chat, and one with a dangerous step needs a
code or, without an authenticator app, a dashboard approval.
That dashboard approval is headed Claude wants to run a change procedure
(or Claude wants to schedule a change procedure for mop.schedule). Its
The procedure card says what you are agreeing to: “approving lets this run
send the writes below, and only these, for 12 hours”. For a schedule it reads
“approving lets every scheduled run send the writes below, and only these,
until the schedule ends”. The card also shows:
- the MOP, its version, and an Open as a document link;
- how many steps there are and how many change the controller;
- the parameter values;
- for a schedule, when it runs and when the approval ends;
- If a step fails: Reverse what it changed or Stop and wait;
- the change window, if any.
A Writes card lists every write with its request and its rollback, and a Warnings card repeats the MOP linter’s warnings.