Secrets & privacy
ConfigOps is local by design. Observation evidence is stored in the WordPress database and is not sent to pyrra or another ConfigOps service.
Data that can be stored
- observation mode, optional Change Session name, status, timestamps, and initiating user ID;
- request ID, actor ID, method, path, admin screen, and bounded source attribution;
- typed before/after option evidence and nested diffs where safe;
- classifications, adapter IDs, schema versions, capture-time component versions when resolvable, caller-versus-Settings-API source basis, and undo eligibility;
- value-free direct-write warnings and restore audit records;
- bounded identity for supported local media, content, and user references.
Secret handling
Tested adapter schemas and conservative key-name heuristics identify probable credentials. Redaction happens before mutation history is written. A redacted node carries only the fact that protected data changed; it cannot reconstruct the original value and is never eligible for undo.
The WooCommerce adapter treats its generated share key and every field in bundled BACS account records as protected. Store currency, tax-display rules, email design, and other mapped non-secret core settings remain reviewable; ConfigOps never stores bank account values in their clear form.
Opaque or structurally unsafe values can also become non-restorable. This favors losing rollback capability over retaining a value ConfigOps cannot safely interpret.
No heuristic can guarantee that an unusually named secret is detected. Plugin authors should provide explicit adapter schemas, and operators should restrict who can view local evidence.
Pack files
Pack export is stricter than History. If any protected or unsupported content prevents ConfigOps from reconstructing one complete option, the complete option is excluded instead of exporting a partially redacted desired state. Files contain no old values, autoload metadata, table names, SQL, callbacks, or executable templates.
A non-secret Pack can still contain private business configuration, site names, URLs, email addresses, and plugin choices. ConfigOps warns about common source-specific values but does not upload or sanitize the downloaded file after export. Store and transfer it as private deployment configuration. Import is an explicit local browser action; there is no ConfigOps cloud, catalog, telemetry, or remote Pack fetch.
Browser intent evidence
The admin observer can correlate a settings save with bounded field names and visible labels. It does not read field values. The short-lived local cookie is limited in bytes, field count, nesting depth, and age. It binds to a named session ID or remains unbound until the same save request lazily creates its automatic observation; malformed or ambiguous evidence is ignored.
Intent evidence may improve a label for review. It cannot change classification, adapter trust, or undo authority.
Access control
Version 0.7.0 uses separate WordPress capabilities for its site observation and Pack surface. The identifiers retain capture for API compatibility:
| Capability | Grants |
|---|---|
configops_view | Read ConfigOps state and observation evidence |
configops_capture | Start and stop named Change Sessions |
configops_rollback | Attempt mutation or whole-change undo |
configops_plan | Validate read-only restore plans; draft/export and preview private Packs |
configops_apply | Apply a previewed Pack or one automation mutation with its required acknowledgement |
These are the capabilities used by the site observation REST routes. Administrators receive the set on activation. Sites with custom roles should grant only the minimum active capabilities needed.
Native Abilities and wp configops use the same WordPress user and capability checks. Capture summaries are value-free, but mutation-list, mutation-inspection, Pack draft, and Pack preview responses can contain non-secret configuration values. A connected external client receives that evidence at the operator's request; ConfigOps itself does not initiate transmission. Use a dedicated service user and grant configops_view, configops_capture, or configops_plan independently. Grant configops_apply only when the user may intentionally change settings. Automated mutation undo still requires the exact danger acknowledgement; browser Pack Apply requires its one-use preview token, and both repeat their ordinary safety checks.
Changing the site-local generic array experiment requires WordPress's manage_options capability. The switch does not grant undo authority: using eligible verified key undo still requires configops_rollback. Its setting contains only an enabled/disabled flag and is removed on uninstall.
Network Admin evidence and mutation undo additionally require WordPress's manage_network_options capability. Network routes are available only in a Multisite Network Admin request, remain pinned to the current network, and do not accept a caller-supplied site or network identity. On Multi-Network installations, foreign Network Options values are excluded and internal site switches are checked against the site's actual network ownership. REST responses are capability-gated, private, and marked no-store.
Retention and removal
Completed and interrupted observations are removed after 30 days by default while ConfigOps is active. Site developers can change the period with the configops_retention_days filter. Cleanup is bounded and preserves history when dependent evidence cannot be removed safely.
Uninstalling ConfigOps removes its evidence tables, installation options, scheduled cleanup, and capabilities. Deactivation does not erase history; it closes an active Change Session as interrupted.
Suggested privacy disclosure
ConfigOps registers suggested WordPress privacy-policy text describing its local configuration evidence, user attribution, default retention, and lack of external transmission. Review that text against your organization’s access, backup, and retention policies before publishing it.