Zsh Export
You use zsh export to share a shell variable with child apps and scripts. Without zsh export, a variable stays locked inside your current terminal window. Engineering teams often use this setup to pass database keys and cloud roles to local tools. When those stored roles have wide permissions, any local script can run high-risk commands. How zsh export works in your terminal When you open a terminal, the shell creates a local memory space for variables. By default, a new variable stays privat
Export: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use zsh export to share a shell variable with child apps and scripts. Without zsh export, a variable stays locked inside your current terminal window. Engineering teams often use this setup to pass database keys and cloud roles to local tools. When those stored roles have wide permissions, any local script can run high-risk commands.
How zsh export works in your terminal
When you open a terminal, the shell creates a local memory space for variables. By default, a new variable stays private to that single shell session. If you start a script or app, the child process gets a blank slate. The export command marks a specific variable for inheritance by child processes.
Once marked, the shell copies that variable into every new tool you launch. This copy goes one way from the parent shell to the child app. If the child app changes the value, the parent shell does not see it. The variable vanishes when you close the terminal window unless you save it.
Where teams store exported shell variables
To keep variables across reboots, engineers write them into shell startup files. The shell reads these hidden files in your home folder when a session starts. Interactive terminals read one main startup file, while login sessions read a profile file. Putting export lines in the right file keeps your local tools working.
Developers also use folder-based tools to load variables when they enter a project folder. This method keeps project settings separate so test and production keys do not mix. Still, every variable sits as plain text inside your shell memory. You must check your startup files often to remove old or broken values.
Export: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What local shell variables leave open
Using exported variables makes local setup fast for command-line tools and apps. An app just reads the variable from memory and logs in right away. You do not have to type passwords or paths every time you run a task. This pattern follows classic design rules for building modern software.
Still, saving static keys in startup files creates a big security gap. Every background tool you run in that terminal can read those exported values. A bad package update or rogue script can steal your database keys in seconds. Also, static keys only control who logs in, not what commands run in flight. If an exported role has full admin rights, one mistake can wipe out tables. You also get no central log of which person ran which command. Masking rules cannot rewrite sensitive fields like emails or card numbers in local results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between setting a variable and using zsh export?
Setting a variable keeps the value inside your current shell window only. Exporting the variable copies that value into any child script or app you start.
Why do my exported variables disappear when I open a new terminal tab?
Running an export command in a live terminal only updates that single session. You must add the line to your shell startup file to make it stick.
Is it safe to store cloud keys and passwords in shell startup files?
No, because startup files sit on your disk as unencrypted plain text. Any app running under your user account can read those files and steal the keys.