Safety nets

Darwin AI is built so that changes can be checked before they happen and undone afterwards. This page explains each safety net in plain English: what it does, how long it lasts, and what you see as the site owner.

Permission levels are the first safety net: an agent can only do what its pass allows. They are explained in Passes (handoffs) and access levels. Everything below applies on top of them.

Dry runs: see the plan first

Every action that changes your site can be run as a dry run. A dry run works out exactly what would change and reports it, but changes nothing. This is a rule for every Darwin AI tool: one that changes things must offer a dry run.

• In the chat, this happens every time. When the assistant wants to change something, Darwin AI first runs the dry run. You see a card describing the change, with Apply and Decline buttons. Nothing changes until you click Apply. See Chat.
• Agents can ask for a dry run on any change, and are told to use one when unsure. The plan is returned to the agent, and the call is recorded in History.

Many changes are also checked as a whole before anything is written. For example, a bulk edit of up to 100 posts, a new menu structure, or an import is validated item by item first. If something is wrong, nothing is written.

Content snapshots and reverting

When Darwin AI changes an existing post or page (updating it, or replacing text across posts), it first saves a private copy of what it is about to replace. This copy is called a snapshot. Rank Math SEO edits on a post keep snapshots the same way, in their own store with the same limits.

• Snapshots are kept for 7 days.
• Up to 100 are kept at once. When a new one is needed, the oldest is dropped.
• There is also a total size limit (16 MB). If it is ever full, edits are refused until old snapshots are cleared, rather than going ahead without a way back.
• Snapshots last beyond the handoff that made them.

To undo an edit, an agent uses the snapshot reference the edit returned. The revert is refused if someone has changed the same fields since, so a later edit is never overwritten by accident. Reverting takes its own snapshot too, so a revert can itself be undone.

Separately, WordPress keeps its own revisions of posts. Darwin AI can put a post back to an earlier revision (title, body and excerpt). The state before the revert is kept as a new revision.

Elementor pages

Elementor keeps a revision every time a page is saved, including saves made by Darwin AI. An agent can list a page's Elementor revisions, with their dates, and put the page back to any one of them. Darwin AI also rebuilds the page's styles and clears Elementor's cache of the page's elements, so the restored version is what visitors actually see. The state before the revert is kept as a new revision.

File backups

Before Darwin AI overwrites or deletes a file, it copies the old version to a backup. This applies to theme files, must-use plugins (code that WordPress loads on every page, before normal plugins), and files in your uploads folder.

• Backups are stored in a protected folder that visitors cannot open. The copies are renamed so they can never run as code.
• The newest 300 backups are kept. Older ones are removed as new ones are made.
• An agent can list the backups and restore any of them. Before restoring, the current file is backed up too.
• Deleting a file without a backup needs the Owner level.

PHP and JSON files are also syntax-checked before they are written, without running them. A file with a syntax error is refused unless the agent deliberately forces it.

Plugin activation health check

When an agent activates a plugin, Darwin AI loads your home page straight afterwards, bypassing any page cache. If the page shows a server error or a PHP error, or cannot be checked at all, the plugin is switched off again at once. The site goes back to how it was, and the agent is told what happened.

An agent can skip this check only by asking for it explicitly, for hosts where the site cannot load its own pages. Darwin AI never deactivates or deletes itself through a tool.

Safe update

Updates to plugins, themes and WordPress itself go through Darwin AI's safe update. Agents have no other way to apply a pending update. Darwin AI itself is not updated this way; it updates through Darwin Labs (see Privacy, licence and updates).

A safe update needs the Owner level. Only one can run at a time. It works in steps, each a short call, so a slow host never hits a time limit.

1. Plan. Darwin AI clears WordPress's cached update list and checks again. It lists what will be updated, in a sensible order, with warnings. For example: Elementor updated without Elementor Pro, a plugin that needs another to be updated first, or not enough disk space for the snapshot. Warnings never stop an update; they are there for you or your agent to read.
2. Baseline checks. Before anything changes, Darwin AI tests the site as a visitor, a customer and an administrator would. It loads pages, styles and admin screens, submits forms, logs in, logs out, tries a password reset, checks the shop and reads the PHP error log. It does this twice, to learn what is normal. If your agent has the visual checker open, it also checks the pages in a real browser, at desktop and mobile widths.
3. Splash page on. Visitors see a holding page carrying your site's name, logo and accent colour. Search engines are told the site is briefly unavailable, not gone. You stay logged in and can use wp-admin as normal.
4. Snapshot. The code of each item being updated is zipped. The database is copied table by table, except logs, sessions and caches.
5. Update. Each item is updated in turn. If one fails, its code is put back at once.
6. Checks after. The same checks run again.
7. Verify. Darwin AI compares the results with the baseline. Anything that worked before and does not now counts as broken: a page error, a changed stylesheet, a form or login that stopped working, a new script error, a menu that no longer opens. If anything broke, the code and the database are rolled back automatically, while the splash page is still on.
8. Finish. The splash page comes off and the run's report is saved.

During the checks, any email the site tries to send (a form notification, a password reset) is caught and recorded instead of sent. Real visitors' email is never affected. Test logins use a temporary subscriber account that is deleted afterwards. Elementor Pro and Contact Form 7 forms are submitted with test data, and the stored test entry is deleted. A check that cannot run on your site, for example a form with a captcha, is reported as such. It is never counted as a pass.

Rolling back later

Each run, with its snapshot, is kept for 7 days, then deleted by a daily clean-up. An Owner-level agent can delete one sooner. If you spot a problem days later, an agent can roll the run back by hand:

• The code always comes back.
• By default, only the database tables the update itself changed are restored. Orders, form entries and posts saved since, in other tables, are kept. The settings table is often among the changed ones, so settings changed since may be undone too.
• Restoring the whole database snapshot loses everything written since it was taken. Once the splash page is off, this needs an extra confirmation.

Snapshots are kept in a protected folder inside your uploads folder, with a random name that cannot be guessed. If the uploads folder cannot be written to, a safe update will not start.

Other safeguards

• Permanent deletion of posts, media, menus and files needs the Owner level. For posts, pages, products and widgets, moving them to the bin (or the inactive widgets area) is the normal route, and can be undone.
• Before media is deleted, Darwin AI checks where it is used. Files still in use are skipped unless an agent names one file and forces it.
• Deleting an ACF field group, post type or taxonomy never deletes the stored data.
• WooCommerce refunds are not available to agents. Moving money stays a human decision.
• Every call is recorded in History, including refused ones.