Skip to Content
Docs

Audit and logs

Cmdop keeps two audit records in two places. Every permission decision — allowed, asked, or denied — is recorded on the machine that made it and read there with cmdop permissions audit. The relay keeps its own audit trail, readable in the web console. Neither is a centralized compliance archive; retention is yours to arrange.

Cmdop keeps two separate records, in two places, for two purposes.

Permission decisions, on the machine

Every decision the permission rules make — allowed, asked, or denied — is recorded on the machine that made it. Read them there:

cmdop permissions audit cmdop permissions audit --tail 200 cmdop permissions audit --follow

Each entry carries the decision, the target, the rule that matched, and the timing. Read it beside cmdop permissions list to tell “a rule matched” apart from “the current mode decided”. A request the rules do not cover leaves no entry at all — see Review permission decisions.

Per-machine policy, recent decisions, and granted OS directories are also readable from Machines in the web console.

Relay audit records, in the console

Open Server → Logs for the relay’s own audit trail. Filter by minimum severity or exact event type, and search the loaded records by event type, message, machine id, and caller.

Retention is yours to decide

Both records are local operational evidence. Cmdop does not run them as a centralized compliance archive and does not promise a retention window. If your organization needs durable retention, export them into your own logging system.

Common questions

Where are Cmdop audit records?

Permission decisions live on the machine that made them and are read with cmdop permissions audit. Relay audit records live in the web console under Server → Logs.

Is there one central audit log?

No. Cmdop keeps separate operational records in the place that made them. Export records into your own logging system if your organization needs centralized or durable retention.

Why is there no permission audit entry?

The request may have failed before reaching the permission policy, or it may have used a path the rules do not cover. Compare the audit with cmdop permissions list and the machine’s connection state.

Last updated on