Feature request: first-class .env / environment-backed secret config UX

Summary

OpenClaw already supports environment-backed secrets well enough for runtime, but the UX still nudges users toward storing secrets directly in openclaw.json.

Using .env / environment variables is materially better for:

• security
• migration between machines
• backup hygiene
• separating runtime secrets from shareable config

However, once users move secrets out of config and into environment variables, the Control UI / config experience becomes worse:

• secret fields may appear blank in the config page
• it is hard to tell whether a value is intentionally sourced from env vs actually missing
• users lose confidence about whether the setting is active
• managing secrets becomes split between runtime success and config UI ambiguity

Why this matters

For real-world setups, users commonly want to keep these out of openclaw.json:

• gateway.auth.token
• channel tokens like channels.discord.token
• provider API keys
• search keys
• Notion / integration API keys

That improves security immediately:

• safer backups
• fewer accidental commits / screenshots / config shares
• easier rotation without editing the main config file
• cleaner separation between portable config and local secrets

But the current UX makes env-backed config feel second-class.

Current pain point

Example:

• user moves channels.discord.token, gateway.auth.token, tools.web.search.apiKey, or skills.entries.notion.apiKey to .env
• runtime works
• but the config page may show the field as empty / missing-looking instead of clearly showing that the value is coming from env

This creates a bad tradeoff:

• safer setup => worse visibility
• easier UI editing => more secrets left in config

Proposal

Treat env-backed secrets as a first-class configuration mode in both CLI and Control UI.

1. Secret source awareness

For secret fields, show source metadata in config views:

• config
• env
• unset

In UI, a secret should never look simply empty if it is being resolved from environment.

Suggested display:

• masked value placeholder like ••••••••
• source badge like From env
• optional resolved variable name like DISCORD_BOT_TOKEN

2. Preserve env references in config editing UX

If a field is set as ${DISCORD_BOT_TOKEN} or similar, the UI should recognize it as an env reference rather than flattening it into “blank” or forcing raw secret entry.

Suggested behavior:

• display From env: DISCORD_BOT_TOKEN
• allow switching between:
  • store in config
  • reference env var
  • unset

3. Add a dedicated “Secrets” / “Environment” helper

This could be minimal but still very useful:

• list which env-backed secrets are currently expected
• show whether each one is resolved
• show where it is referenced from config
• optionally point to .env as the recommended local secret file

4. Make migration/security guidance explicit

When the UI detects secrets stored directly in config, it could suggest:

• “Move this to environment for safer local storage”

Even a small affordance here would improve default security posture.

5. Keep values masked, but not invisible

The important point is not to reveal secrets, but to avoid ambiguous emptiness.

Good UX:

• masked
• source-aware
• editable

Bad UX:

• blank field that looks unset even though runtime is working

Expected outcome

This would let users get both:

• safer secret management via .env / environment variables
• confidence and clarity in Control UI / config pages

It would also make multi-machine migration and backup workflows much cleaner, since users can keep:

• openclaw.json as portable config
• .env as local secret material

Suggested scope

Even a small first step would already help a lot:

1. Detect env-backed secret fields in config views
2. Show From env instead of blank
3. Add a source badge in Control UI

That alone would remove most of the current UX penalty for doing the safer thing.