OpenClaw Main Adds a SQLite Secret Store—and Makes Stored Env Values Executable

OpenClaw has merged a Gateway-wide SQLite store for team secrets and environment values into main. It also merged the consequential second half: rows saved with kind env are assembled into agent exec environments.

This is not merely a nicer place to keep API keys. It creates two disclosure classes in the same database, and an upgrade can give existing env rows a new subprocess consumer. Operators should inventory the store before deploying a containing build.

Availability: the changes are on main; the evidence reviewed here does not establish a containing stable release.

The two kinds are intentionally different

PR #121559 adds a local openclaw secrets store workflow and a store SecretRef source. The official documentation describes the store as team-scoped and shared by Gateway processes using the same state database.

An entry is either:

• secret: write-only through the CLI and resolvable through a store SecretRef; or
• env: readable through store list/get operations and eligible for agent subprocess injection.

The kind controls disclosure, not whether a SecretRef can resolve the value. Most importantly, secret rows are not injected into subprocess environments. Converting a secret to env is therefore an authority decision, not a formatting choice.

Values are encrypted at rest with a host-local key according to the merged implementation and docs. That protects a copied database from casual inspection; it does not isolate a process already authorised to read the store, nor does it make backups and key custody somebody else’s problem.

Upgrade risk: existing env rows gain a consumer

PR #121773 feeds team env rows into the canonical exec-environment assembly path. The documented precedence puts them after inherited process values and before explicit per-call environment overrides.

Protected host variables and sandbox-blocked credential names are filtered rather than blindly forwarded. That is useful defence, but it does not change the central compatibility fact: a value previously disclosed only by store CLI reads can become visible to commands run by an agent after upgrade.

Action: before rollout, list names and kinds without printing values. Reclassify anything that should be available only through SecretRef resolution as secret. Treat every remaining env row as readable by allowed agent subprocesses.

Defaults now resolve by source

PR #121630 fixes default-alias handling so env and store resolve their own built-in defaults instead of accidentally borrowing a provider with the same alias from another source family. Non-default aliases, plus file and exec providers, still require matching explicit configuration.

That matters during migration: a name such as default is not proof that two providers share custody or semantics. Test each source independently.

Control UI can now manage the team store

PR #121724 adds Settings → Secrets for listing, adding, editing, bulk-importing and soft-deleting team-scoped entries. Secret values remain write-only after saving; there is no reveal RPC. Environment-kind values remain visible to administrators because that kind is already the readable disclosure class.

Bulk Add accepts dotenv assignments and can classify credential-shaped names as secret. Operators must still review the preview. A helpful name heuristic is not a data-classification authority, and clearing auto-detection can turn every imported value into readable env state.

Control UI mutations refresh the active secret snapshot when an affected name is referenced by active config. Local CLI writes remain offline database changes and require openclaw secrets reload before the running Gateway consumes them.

The page manages values, not SecretRef wiring. Saving OPENAI_API_KEY in the store does not automatically point a model provider at it.

Empty secrets now fail at the boundary

PR #121947 rejects an empty value for kind secret and classifies oversized input as validation rather than an internal failure. Empty env entries remain valid because an intentionally blank environment variable has a meaningful, readable state.

This matters operationally: accepting an empty write-only secret would produce a downstream authentication failure that administrators could not diagnose by reading the stored value.

Safe rollout

Use a disposable state copy and synthetic values:

1. back up the SQLite state and its encryption-key material under your existing secret-retention policy;
2. inventory store entry names, kinds and owners without emitting values into CI logs;
3. change unintended env rows to secret before introducing a containing build;
4. verify secret values resolve through source: "store" but never appear in list/get output or an agent subprocess;
5. verify an approved env row reaches local, sandbox and node exec only where current policy allows it;
6. attempt protected host-key and blocked credential-name overrides and require visible rejection or filtering;
7. run openclaw secrets audit --check and remove plaintext residue from config, .env, generated model files and migrated auth-profile storage; and
8. bulk-import synthetic dotenv rows in Control UI and verify the secret/env preview before saving;
9. require empty secret and oversized-value failures to appear as validation errors without persisting a row; and
10. test reload and restart with the state database unavailable or the key missing, requiring a fail-closed result rather than a fallback to plaintext.

Do not print a real secret to prove this works. Use a synthetic marker, assert presence or absence, then destroy it.

Bottom line

The SQLite store gives OpenClaw a useful shared SecretRef source, but env is deliberately a broad disclosure class. The operator decision is simple: store credentials as secret; use env only for values you are prepared to expose to every agent exec path that policy permits.