Configurable masking patterns for EnvVarsPanel

[samkeen]

Background

EnvVarsPanel masks env-var values when the variable name matches /key|token|secret|password/i, rendering as •••••••• abcd (last 4 chars) until the user clicks to reveal. Behavior shipped 2026-05-10; lives at src/components/inspector/EnvVarsPanel.tsx (the sensitive flag) and src/lib/envSensitive.ts (the maskValue helper and the regex itself).

The pattern is hard-coded today.

The gap

That regex covers the common shapes but leaves real holes:

• ANTHROPIC_BASE_URL may embed credentials in a URL but doesn't match.
• *_AUTH, *_BEARER, *_PRIVATE_KEY_PATH, *_CREDENTIALS_FILE and similar don't match.
• A user with internal naming conventions (MYCO_API_TOK, MYCO_PROD_CREDS) gets nothing.

Conversely, some matching vars are harmless (e.g. a vendor SDK uses *_KEY for non-secret config IDs) and the mask is friction.

Ask

Surface masking as a user-configurable preference, accessed via a small admin UI in knobs.cc (likely a topbar settings affordance — possibly the existing ? help slot grows a sibling, or a new gear pill). Settings to expose:

• Add/remove regex patterns or literal substrings to the mask set.
• Per-name overrides — "always mask FOO", "never mask BAR".
• Toggle for the global default pattern (so a user can opt out of /key|token|secret|password/i entirely).

Tension with v1 read-only boundary

knobs.cc is locked to read-only inspection per spec/design-notes.md ("v1 scope: locked to read-only") and the Tauri capability surface deliberately excludes fs write plugins. An admin UI for masking preferences is itself a write surface — it has to persist user preferences somewhere, which means either:

1. A new write path through a tightly-scoped Tauri command (e.g. write only to ~/Library/Application Support/cc.knobs.knobs/preferences.json), keeping the broader read-only posture intact.
2. A localStorage-only approach (no Rust write surface, preferences are per-OS-user but per-webview-origin and don't survive a fresh install).

Option 2 is the lighter v1-compatible move if the preferences are demo-comfort tweaks rather than long-lived config. Option 1 is the right shape if knobs.cc starts to grow other user-preference surfaces (rail navigability mode, default panel, etc.).

This decision should land before any UI work — surface as a question, not a ticket.

Out of scope for this issue

• Editing the underlying env vars themselves (still v2-only).
• Project-scoped preferences (vs. per-user) — single-user OS account is the v1 assumption.

Related

• The masking code: src/lib/envSensitive.ts, src/components/inspector/EnvVarsPanel.tsx.
• Read-only boundary rationale: spec/design-notes.md § "v1 scope: locked to read-only" and § "Tauri 2 boundaries".