EnvPane: How a Windows Person Manages Environment Variables on a Mac

Confession up front: I'm mostly a Windows user. I love Windows Terminal — the tabs, the
profiles, and honestly the silly little thing that you can make the font bigger in about half a
second. For whatever reason, the macOS Terminal has never given me that same at-home feeling. So
on my Mac I just… don't live in the terminal the way Mac people do. Which means the usual macOS
advice — "put your environment variables in ~/.zshrc" — never stuck for me.
And I need a lot of environment variables. I run a small army of AI agents and various dev
tools, and they all want secrets: API keys, tokens, endpoints, model keys. I want those set
once, available everywhere, without babysitting a shell config file I rarely open.
That's the gap EnvPane fills for me, and it's the kind
of small, boring, does-one-thing-well tool worth telling people about.
What EnvPane is
EnvPane is a macOS preference pane — it installs into System Settings (System Preferences),
and it lets you set environment variables for all applications, both GUI and terminal, from a
simple key/value UI. By Hannes Schmidt, open source under Apache 2.0.
Two things make it genuinely useful rather than just convenient:
- It sets variables for every process — GUI apps included. This is the part shell-rc files
can't do.~/.zshrconly affects shells you launch interactively. A variable you need inside
an IDE you opened from the Dock, or an agent a GUI app spawned, won't see your.zshrc. EnvPane
sets the variable at the session level, so the launcher of everything knows about it. - Changes apply immediately — no logout/login. It restores macOS's old support for
~/.MacOSX/environment.plistand publishes your edits to the live environment right away,
whether you change them through the pane's UI or by editing that plist directly.
For someone like me, that's exactly the mental model I want from Windows: a list of variables in
a settings window, set once, seen by everything. No "which shell launched this, and did it source
the right file" guessing.
Why it fits the "lots of secrets for agents" workflow
When you're wiring up several agents and services locally, the secrets sprawl is real — a dozen-plus
keys, each needed by a different tool, some launched from a terminal, some from an app, some by
another process entirely. Putting them in EnvPane means:
- The IDE I opened from Finder sees
OPENAI_API_KEY(or whatever) without me exporting anything. - A terminal I do occasionally open sees the same values.
- A GUI app that shells out to an agent inherits them too.
One list, one source of truth, visible process-wide. That's worth a lot when you're juggling
secrets across a fleet of little tools.
Installing it (and the quarantine gotcha)
Release 0.8 targets macOS 12 "Monterey" and up, with code-signed universal binaries —
so it runs natively on both Intel and Apple Silicon. There's one wrinkle worth knowing before you
download:
It's code-signed but not notarized by Apple. That means when you download it with a
browser, macOS quarantines it and refuses to open it, with a mildly misleading error.
The workaround is the standard one for un-notarized software: right-click the preference pane in
Finder and choose Open to override the block (a user confirmed this on Ventura; the author
notes he couldn't confirm it on Monterey — see issue #34). It's the same dance you do for plenty of
small, independent Mac tools. If that makes you nervous, the source is on GitHub and you can build
it yourself.
The caveats — know these before you rely on it
EnvPane is sharp but it has two hard limits, and they're both worth internalizing:
- It can't set
PATH. This surprised me too. ForPATHyou're back to your shell config (or
/etc/paths.d). EnvPane is for your other variables — keys, tokens, config — not your
executable search path. (There's an FAQ entry on exactly this.) - It can't set
DYLD_…variables. That's a restriction macOS itself imposes, presumably for
security. Don't fight it.
So the honest framing is: EnvPane is the GUI home for your secret/config environment variables,
and PATH stays where macOS wants it. For my use — piles of API keys for agents and dev — that
split is totally fine, because none of those are PATH or DYLD_.
One word on secrets at rest
Since I'm using it for keys, the responsible footnote: EnvPane stores values in
~/.MacOSX/environment.plist as plain text on disk. That's the same threat model as a .env
file or exporting keys in .zshrc — fine for a personal dev machine, but it is not a vault. If a
secret is genuinely sensitive (production credentials, anything you'd rotate in a panic), keep it in
a real secrets manager and pull it in deliberately, not in a world-readable-ish plist. For local
dev keys, I think the convenience is a fair trade; just go in with eyes open.
Why I like it
It's not flashy. It doesn't have a roadmap full of AI features. It's a small preference pane that
makes one annoying thing painless — and for a Windows person who never bonded with the Mac
terminal, that's precisely the kind of tool that makes the platform livable. I set my agent keys
once in a tidy little window, everything sees them, and I get back to work.
If you, too, have been quietly suffering through export FOO=... lines you can never remember the
location of, give EnvPane a look. And if you've got a
slicker way to manage a wall of dev secrets on macOS, tell me — I'm always listening on the links on
the about page.