An agent working on your site should leave a trail. Sokket records every tool call in its own database table, so you can answer "what did it actually do?" without guessing.
Where to find it
Two places show the same data:
- Sokket → Dashboard → Recent Activity — the most recent calls at a glance, next to server status and active connections.
- Sokket → Settings → General → Recent activity — the same list underneath the server settings.
What each entry records
| Column | Meaning |
|---|---|
| Time (UTC) | When the call was handled. Stored in UTC so it lines up across servers and timezones. |
| User | The WordPress user the connection was bound to and running as. |
| Tool | The tool name, e.g. update_post. |
| Outcome | success, denied, or error. |
| Object id | The post, attachment, term, or comment the call acted on, where there was one. |
The entry also links back to the token that made the call, so you can tell two connections apart when several are active.
Reading the outcomes
success— the tool ran and returned a result.denied— a permission gate refused it: the tool wasn’t in that connection’s allowlist, the connection is read-only and the tool writes, or the bound user lacks the capability. A handful of these right after you connect a client is normal — clients probe. A sustained run of them means a credential is trying things it shouldn’t, and is worth a look.error— the tool was allowed but failed: a missing post id, an invalid argument, an upload that wasn’t really an image.
What is deliberately not logged
Tool arguments are never stored. Not the post content, not the search terms, not the reply text, not the base64 of an upload.
That’s a deliberate trade. Logging arguments would turn the audit table into a second, unmanaged copy of your content — a privacy and disclosure problem far larger than the debugging convenience it buys. Recording the object id instead gives you the thing you actually need: which post was edited, so you can open it and look at the revision history WordPress already keeps.
So the audit log tells you who did what, to which object, and whether it worked. For the content of a change, use WordPress revisions; for the comment queue, use the comment itself.
Retention and the row cap
The table is capped and prunes itself — it never grows without bound. The default is the most recent 500 rows; older entries are dropped as new ones arrive.
Developers can raise or lower that with the sokket_audit_max_rows filter (minimum 10):
add_filter( 'sokket_audit_max_rows', function () {
return 5000;
} );Uninstalling the plugin drops the table entirely.
Clearing the log
There is a clear action in the admin for wiping the log — useful after testing, when the early rows are noise. It’s irreversible, so treat it accordingly, and remember it’s a record: on a site where several people share admin access, clearing it removes evidence for everyone, not just you.
Using it in practice
- After you first connect a client, glance at the log to see which tools it calls unprompted. Clients often probe capabilities during the handshake.
- After granting write access, check the first few writes and their object ids against what you expected.
- When something looks wrong on the site, filter your attention to write tools around that time — the object id points you straight at the post or comment involved.
- Before revoking a token, look at what it’s been doing lately. If it’s idle, it’s an easy call.
Pro adds filtering by user, tool, outcome, and date range, unlimited retention, and CSV export — see Pro Features.