Governed ability
Delete user
aafm/delete-user Guarded write
Permanently delete a user and reassign their content to another user. Never deletes you or the last administrator. Requires the delete-users capability. Off by default.
How it is governed
The same model as every ability in the plugin, stated for this one.
- Off until you enable it
Like every ability, Delete user ships switched off. You turn it on one at a time, and an update never widens access on its own.
- Guarded write
Writes stay conservative, and the plugin re-checks the capability before the call runs.
- Capability gated
A connection only sees Delete user if the user you connected can run it, and the plugin checks that capability again before it executes.
- Every call audited
The call is written to the log in your own database, denials included, with the argument keys but never the values.
- It can delete
This ability can delete. Where WordPress supports it, items go to Trash and can be restored, and the last administrator can never be removed.
See it in action
An illustrative run. Your real calls and data stay on your own site.
Try it with a prompt
Example requests you could paste to your agent.
Delete user 305 and reassign their posts to user 214.
Remove the account for a former contributor and hand their content to editor Priya.
Delete user 88, moving everything they authored to user 12.
These are illustrative example prompts. The agent runs them as the user you connected, checked against that user's capabilities and written to your audit log.
Frequently asked
Short answers for Delete user.
What happens to the deleted user content?
Their content is reassigned to another user you name in the same call, so posts are not orphaned. The user record itself is removed.
What can it never delete?
It will never delete you (the acting account) and never delete the last administrator, so the site cannot be locked out. It requires the delete-users capability and is off by default.
Is a deleted user recoverable?
Deleting a user is a permanent removal of the account, not a move to Trash, so it should be treated as final. The action is logged in the audit trail with who ran it.
Governed by default, from the first call.
Delete user is off until you enable it, scoped to the user you connect, and logged like everything else. Turn on only what you need.
Every ability off until you enable it, capability-gated on every call.