# Will Copilot change my server without asking?

Compute Copilot runs write actions the moment it decides to call them, with no approval step, and the Stop button does not undo changes already made.

No. Send an instruction in Compute Copilot that changes an instance, such as "restart this instance" or "delete this old backup," and the moment the model decides to call the matching tool, the action **runs on the real resource immediately**. The only mode you can open in the console today has no "generate a plan, wait for your approval, then run it" step. Write actions and read-only lookups go through the same path: the model decides to call a tool, and the tool runs.

_Interface illustration: Compute Copilot chat panel: a message bubble showing a write action in progress, and the Stop button to the right of the composer_

## Before you start

- **Mode**: The console has one operating mode today. Opening Compute Copilot and sending a message is already using it — there is no setting to switch.
- **State your intent**: If you only want suggestions and not execution, say so explicitly in the instruction. Do not assume the model will hold off on its own.
- **Per-action confirmations**: For the confirmation dialog and parameters of a specific action, see the corresponding instance operation page. This page only answers one question: whether approval happens at all.

## What Default mode does, and does not do

The console shows a one-time tip the first time you open Copilot, and it reads:

> **Actions run on real resources**
> By default, installation, restart, and configuration changes run directly without step-by-step approval. Check the targets before sending; for analysis only, explicitly ask for inspection and a proposed plan.

That tip only appears once and will not reappear after you dismiss it, but the behavior it describes stays in effect every time:

| What happens                                                                                       | What does not happen                                                                                              |
| -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Once the model decides to call a tool that changes the instance, that action runs directly         | It does not generate a plan first for you to review the target, impact, and rollback notes                        |
| Every write action is recorded in the session timeline once it runs, so you can review it later    | No **Confirm** button or blocking dialog appears before execution                                                 |
| You can explicitly ask the model to "only analyze, do not execute," and it will adjust accordingly | Riskier-looking actions (delete, reinstall) do not get an extra prompt — every write action follows the same rule |

> [!WARNING]
> Once you send an instruction, the moment the model decides it needs a
> write-action tool, that tool runs on your instance for real. Writing the
> target instance and scope clearly before you send is more reliable than trying
> to fix it afterward.

## What counts as a write action

The following actions all change instance state and share the same approval-free execution path — none of them gets treated as higher risk than the others:

- Power on, power off, force restart
- Reinstall the instance from an image — this overwrites the system disk
- Delete the instance, including permanent termination
- Delete a completed backup
- Restore the system disk from a backup — this overwrites the current system disk
- Change the public IP, private IP, or IPv6 address
- Reset the system login password
- Run a shell command directly inside the instance

Deleting an instance, deleting a backup, and restoring a backup are usually thought of as "high risk," but they get **no** extra confirmation for it. They run through the exact same path as powering an instance on or off — nothing in the code applies a stricter gate to them.

## What the Stop button can and cannot undo

While write actions are running one after another, a **Stop** button appears next to the composer. What it blocks and what it does not are two different things:

_Interface illustration: A running Copilot session: completed steps already in the timeline, and the still-clickable Stop button_

| What happens                                                                                          | What does not happen                                                                        |
| ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| Selecting **Stop** interrupts steps that are queued but have not started yet                          | It does not undo steps that already finished running — there is no rollback or compensation |
| Changes already completed (a backup already deleted, a system disk already overwritten) stay in place | It does not restore the instance to its state before the turn started                       |
| Anything you type while stopping is kept as a draft                                                   | The draft is not automatically queued to run in the next turn                               |

In other words, **Stop** only blocks what has not happened yet. It has no remedy for what already has. If the model already called the tool that deletes a backup, selecting Stop will not bring the backup back.

## When Copilot pauses on its own

Besides selecting Stop yourself, a few resource limits unrelated to approval will also make Copilot stop automatically once they are reached:

- The tool-call limit for the turn is reached
- The turn's execution time limit is exceeded
- Several steps in a row make no effective progress
- The model connection fails repeatedly past its limit

These are all circuit breakers triggered by execution volume or duration, not by how risky an action is. When one trips, it only stops the remaining steps — it **does not** undo changes already made.

## Step-by-step approval is not available yet

> [!NOTE]
> The backend API supports passing an `on_request` approval policy when a
> session is created, which in theory would make write actions wait for approval
> one by one. But the console currently has no way to turn this on — not in the
> runtime settings panel, not anywhere else. Whether this option will ever be
> exposed in the interface is an open question that has not been confirmed. Do
> not treat it as something you can currently switch on.

## Get a confirmation step from the instance detail page instead

Compute Copilot has no way today to generate a plan and wait for your approval before running a write action. If you want a confirmation step before a specific action, skip Copilot and perform it directly on the instance detail page instead — actions like power control and instance deletion each have their own standard confirmation dialog, and deleting an instance also requires typing the instance name to confirm.

- Refer to [Start, stop, and restart an instance](/compute/instances/management/power/) for the power-action confirmation dialogs.
- Refer to [Delete an instance](/compute/instances/management/delete/) for the name-confirmation step before deletion.

## Related documentation

- [Compute Copilot](/compute/copilot/)
- [Copilot tools and actions](/compute/copilot/tools/)
- [Copilot sessions](/compute/copilot/sessions/)
- [Start, stop, and restart an instance](/compute/instances/management/power/)
- [Delete an instance](/compute/instances/management/delete/)