Environment variables
Named env sets with masked values, loaded into a pane in one click.
Environment-variable sets let you keep named bundles of env vars — a project's API keys, a staging config, your AWS_* trio — in Mel Drive and load them into a terminal pane on demand. Sets are stored as *.env.json files under ~/.local/share/mel/drive/.
The editor
Create a set via the Drive + menu → Environment variables, or click an existing one. The editor opens in the center panel with a Load ⌄ / Save header and a variables table.
- Values are masked by default (rendered as password fields) — no secrets on screen during a screen share.
- Click 👁 on a row to reveal a value while you check or edit it.
Value sources
Each variable has a source, chosen from a per-variable source menu. A value doesn't have to be a stored string — it can be resolved at load time:
| Source | What Load does |
|---|---|
| Literal | Uses the stored value as-is |
| Command | Runs the value with sh -c and uses its output |
| 1Password | Resolves via op read <ref> |
| LastPass | Resolves via lpass show <ref> |
The manager-backed sources mean the secret never has to live in the Drive file at all — the .env.json stores only the reference, and the actual value is fetched from your password manager's CLI (which must be installed and signed in) at the moment you load.
Loading into a pane
Click Load and Mel resolves every variable in the set — running commands, querying 1Password or LastPass, taking literals — and exports the resolved set into the active pane. A toast confirms the load.
From then on, every command you run in that pane sees those variables: under the hood Mel prefixes each command with the exports (export KEY='value'; …). The set applies to that pane only — other panes and tabs are untouched, which makes it easy to have staging credentials in one split and production-read-only in another.
Practical notes
- Loading is per-pane and lives for the pane's session; open a fresh pane if you want a clean environment.
- Because sets are files, you can keep a team-shared skeleton (with Command or manager sources, no literals) in a repo and drop it into your Drive directory.
- Combine with workflows: a workflow can assume its
$TOKENis present because you loaded the set first.