OpenClaw's Control UI gained a major operator feature this morning: team-scoped secret management. PR #121724 adds a Settings -> Secrets page backed by new admin-scoped Gateway methods, closing a gap between the local CLI secret store and browser-based administration.
Before this change, operators could write team values into the SQLite secret store from the local CLI. A running Gateway and Control UI, however, did not have a typed management surface. That meant browser operators could not manage stored values directly, and runtime refresh behavior remained something the operator had to remember.
What Administrators Get
The new Settings -> Secrets page supports listing, adding, editing, bulk importing, and soft-deleting team values. Environment entries remain visible, while secret entries are structurally non-revealable and render as a fixed mask.
The Add form supports multiline PEM and JSON values. It also defaults the Secret checkbox using OpenClaw's shared sensitive-name classifier, which should reduce the chance that a token-like key is accidentally treated as a plain environment value.
Bulk Add accepts quoted multiline dotenv input and shows live detection counts. The implementation deliberately performs sequential secrets.store.set calls and reloads the table after each confirmed write, which makes partial failure visible without inventing a second bulk mutation contract.
Gateway Behavior
The PR adds three admin-scoped Gateway methods and keeps mutations with the existing auxiliary secrets owner. Set and delete operations collect exact canonical store:<provider>:<name> references from the active source config snapshot.
When a referenced value changes, Gateway queues a non-coalescing reload and denies last-known-good fallback for affected keys. That means a deleted or invalid replacement becomes cold instead of silently retaining the old credential. Unreferenced names skip the reload.
The page is also capability-aware. It requires explicit advertisement of all three new methods plus operator.admin; older Gateways hide unsupported actions and show an unavailable state instead of issuing calls they cannot handle.
What Is Still Separate
The local openclaw secrets store CLI remains a direct offline database tool in this PR. The author calls out why: safely routing that command through a local Gateway needs one authority owner before dispatch, and catch-and-replay fallback could double-write after an ambiguous transport failure.
The practical consequence is clear. Secrets changed through the UI trigger Gateway reload handling automatically. A CLI write to a config-referenced store value still needs openclaw secrets reload.
Tested Scope
The PR landed with focused Gateway, runtime-state, protocol, CLI, parser, and UI coverage. The final secrets run passed 112 tests, and captured Playwright tests covered CRUD, bulk import, non-disclosure, visible outcomes, contrast, and legacy Gateway method discovery.
For teams running OpenClaw as a shared operational surface, this is a meaningful quality-of-life and safety upgrade. Secret management is now where administrators expect it to be: in the same Control UI they already use to manage the running Gateway.