One substantial addition and two small changes. Unlike the last few releases, this one does change behaviour on update: a new database table is created and the activity log starts recording straight away. Nothing else moves — no settings reset, no reconnecting, no change to how assistants reach your site.
New: a log of what AI assistants actually did on your site
Every request an assistant makes, and every ability that ran to fulfil it, recorded together. A single "create a page" from an assistant may run several abilities underneath; the log keeps the request and its abilities linked, so you open one entry and read what actually happened rather than inferring it from the result.
Each entry records which assistant, how it authenticated, whether it worked, how long it took, what it was asked, and roughly how much of your content it read back.
Find it under MCP → Activity Log, or on an individual server's own tab.
The log is on from the moment you update, and bounded without being configured
Requests are kept 30 days, ability runs 7 — they are much noisier, several per call, and include anything run from REST, WP-CLI or the admin — and the whole log is capped at 50,000 entries. A daily job applies all three.
Every number is adjustable and either half can be switched off on the MCP settings tab.
Recording is on by default because a log nobody enabled is a log nobody has when they need it. It is bounded by default because a plugin that records without being asked should also tidy up without being asked.
If you would rather it recorded nothing, switch both toggles off on the MCP tab of the AcrossAI Settings page. The table is still created; it simply stays empty.
It tells you when it is failing
An empty log and a broken log look identical, which is how a logging fault stays invisible for weeks.
The screen and Site Health now both report when writes are failing, when the table cannot be reached, and when the daily cleanup has not run — that last one usually meaning WordPress scheduled tasks are not running at all on the site, which affects far more than this log.
Private by design
Values that look like credentials are redacted by key name before anything is stored, and response bodies are never kept.
WordPress's own personal-data export and erase both reach the log. Erasure clears the person from the record and keeps the event, so a subject-data request cannot be used to delete audit history.
One limit worth stating plainly: redaction matches sensitive key names. A secret pasted into a free-text field — a message, a search term — matches nothing and is stored as sent, subject only to truncation. Ability arguments are recorded, and the setting says so.
Changed: the connection wizard is now called "Connect"
It was "Quick Connect via AcrossAI" in the admin bar, the menu, the server list and the wizard's own header. Nothing moved and nothing behaves differently — the label just says less.
Fixed: a PHP notice on every page load
A database table was passing an index setting in a form newer PHP versions warn about. It had never had any effect — the table was not using it — so removing it changes nothing except that the notice stops. Only visible to sites with debug logging switched on.
Requires: WordPress 6.9+, PHP 8.1+. Full history in changelog.txt.