Open WP Visibility → Review queue, read the diff, and click Approve or Reject. Approve applies the change through the same code path the plugin uses for its own writes and confirms it; Reject marks the proposal rejected and changes nothing. Nothing in the queue touches the site until you say so.
Where the queue is
The queue appears in the menu once the Autopilot module is on. When proposals are waiting, the menu item shows a count, the way WordPress shows pending comments. The count covers proposals that need review, including stale ones.
The page has two tabs. Proposals is the review surface. Activity log is the record of ability calls, covered in Read the Activity Log. Above both sits a status bar with the assistant access state, a Pause agent button, the current guard mode, the write limit in use, and the last recorded activity.
Reading a proposal
Each card names its target, for example post #42 and the post title, its source, its status, and any note the assistant supplied. Treat the source and the note as context that came with the request, not proof of who wrote it. Post targets include an Edit post link.
Below that is a table with Field, Before and After. Before is the value read when you opened the diff; changed words are struck through on the left and underlined on the right. Long values such as an llms.txt body fold behind Show more. If the assistant gave a reason, it appears as Agent rationale.
Approve
Approve checks the proposal against the current state of its target and applies it. If the target changed since the proposal was written, the plugin stops instead and marks the proposal stale; see below. After a successful approval the confirmation offers Undo for a moment, and the card keeps a Revert this change action, described in Undo an Applied Change.
Reject
Reject marks the proposal rejected. The proposed values are not applied and the target is untouched. Rejected proposals stay visible under the Show filter for a while and are cleared by housekeeping later; the queue is not an archive.
Stale proposals
At proposal time the plugin stores a fingerprint of the fields the proposal covers and checks it again on approval. A mismatch means someone or something changed the target in between, so approval stops and the card shows Refresh diff. Refreshing sets a new baseline from the current values and returns the proposal to pending. Read the refreshed diff before approving; the change you are about to apply may no longer be the one that was proposed.
Bulk actions
Tick the box on each card, or use Select all needing review, then Approve selected or Reject selected. Every proposal in the batch goes through the same checks as a single approval, and stale rows are skipped and reported rather than applied.
From the keyboard
j and k move between proposals, a approves the focused one, r rejects it, x ticks its box. The keys are printed on the buttons and never fire while you are typing in a field.
From the command line
wp visibility proposals list
wp visibility proposals approve 123
wp visibility proposals reject 123The same checks apply. An administrator credential can also approve through the plugin’s REST route; approval is not something only the browser can do, so the user behind each credential is what to control.