Open WP Visibility → Review queue and select the Activity log tab. The Review queue screen appears when the Autopilot module is on, and the log itself needs the Agent module; with Autopilot off, use the commands below. Calls are listed newest first, 50 at a time with Load more, and opening the tab verifies the log’s hash chain and reports the result at the top. To check the chain from the command line:
wp visibility agent verify-logwhich prints a line such as Success: Audit log verified: 1240 row(s), hash chain intact. or an error naming the row where the chain breaks.
What a row contains
The time, the WordPress user, the client label (the Application Password’s name, or wp-cli or wp-admin when no Application Password was used), the ability called, its target, a shortened excerpt of the input with license values redacted, the outcome, and how long it took. The tab shows the time, the actor (the client label, or the user ID when there is none), the ability, the target and the outcome; wp visibility agent log adds the user and duration, and the get-agent-log ability returns every field. Reads are logged as well as writes, so the log is a record of what the assistant looked at, not only what it changed.
The client label is what makes one password per client worth the minute it costs: two assistants connected as the same user are told apart here by nothing else.
What the chain proves
Each row stores a hash of the row before it. Verification walks the table and confirms every link. A break means rows were altered or removed after they were written, or, rarely, that two calls were logged at the same moment and forked the chain. It does not prove the history is complete, and it cannot protect the table from someone who can rewrite the database and recompute the hashes; it is a tamper signal, not a vault.
What is not in it
Only calls through the plugin’s ability surface are recorded. A change made through the WordPress editor, the core content REST routes, ordinary WP-CLI commands (including wp visibility commands), WP Visibility’s own settings and Review queue screens, or another plugin, by the same user, does not appear. Within the ability surface, a row is written only when a call completes: a call refused by a permission check or a pause, a call with invalid input, and a call that returns an error, including the hourly write limit, leave no row on WordPress’s standard execution path, because WordPress fires the after-execution hook the log writes from only when a call succeeds (WP_Ability::execute() in WordPress 7.0, checked September 27, 2026). If an assistant’s credential has an administrator role, it can reach those routes, and this log will not show it. The user’s role decides what an assistant can reach; the log shows what it reached through the plugin.
Retention
Viewing the log runs housekeeping: entries older than 90 days go, and the oldest entries above 10,000 rows go. There is no export button; to keep a copy, save the output of wp visibility agent log --limit=500 --format=csv before then. That command returns the newest 500 rows at most and leaves out the input excerpt; to reach older rows or the excerpt, page through the get-agent-log ability with its offset input.
From the command line and from an assistant
wp visibility agent log prints recent rows, 50 by default. The get-agent-log ability returns the same rows with the chain’s row count and hashes, so an assistant can be asked to summarize its own recent activity if its user has the manage_options capability (administrators do); the log is the source, the assistant’s summary is not.