VPN Tool Settings: Launch-Time Environment or a Hook Export?
A hook starts its own children, not the shell you already opened. A launch-time environment keeps the private endpoint on the one command that needs it.
A VPN hook that exports an API endpoint changes the environment of the processes it starts, not the terminal that was already open when the tunnel came up. That one distinction explains most "the tool still calls the public endpoint" reports. There are two workable places to put the setting, and the choice depends on who consumes it and how often it changes. Compare them before you add another startup script.
Two places the setting can live
Option one is a prefix on the command itself: the value exists for that one invocation and disappears with it. Option two is an export inside the connection hook, which reaches every process the hook spawns after that point. They differ in reach and lifetime, not in syntax, and that difference decides most failures.
| Property | Prefix on the command | Export from the hook |
|---|---|---|
| Who receives it | That invocation only | Children the hook starts |
| Lifetime | Until the process exits | Until the hook's own session ends |
| Leakage | Scoped to one command | Applies to later commands in that session |
| Repeat cost | Every invocation | Once per connection |
| Works for an open editor | No, unless the editor is started with it | No |
The table makes the hook look cheap and hides the real bill: it also selects a private endpoint for commands that have nothing to do with the task. Read each row as a constraint rather than a preference. If the endpoint changes per task, the prefix wins on precision even though it costs a keystroke.
Why the hook cannot reach a shell that is already open
Environment variables are handed to a process when the process image is created. A shell that started before the connection keeps the copy it received, and an export executed inside the hook is not a broadcast to every process on the machine. Only the hook's own children inherit it. A shell's own children take whatever the shell holds at the moment they start, which is why the same command can work in one terminal and fail in another.
The same applies to a graphical editor. Its extension host, integrated terminal and background language server were forked at launch and hold their own copies. Reopening a folder does not necessarily restart those children, so the setting you added still never arrives.
The cheapest test is to print the variable from the place that fails, not from the shell that works. If the failing process started before the tunnel, the export never had a chance.
The per-command form, written out
A prefix keeps the choice visible in the command that uses it, which helps when the endpoint changes between tasks:
env INTERNAL_API='https://internal-api.example.net:8443' my-work-toolThe command is illustrative: my-work-tool is a placeholder and INTERNAL_API is not a VPN standard, so substitute the documented setting of the program you actually run and your own approved host. Do not put a token or password on the same line, because it lands in shell history.
When several commands belong to one task, a short reviewed wrapper script sets the variables and then starts them. That keeps a single definition without making the value global to every future command in the terminal.
Reload, restart, or leave it alone
For a tool that is already running, prefer its own reload or workspace profile when it has one. Otherwise save work and restart the component that reads the setting, which is often a language server rather than the editor window. Restarting the window and assuming the child processes followed is how a reload appears not to work.
Disconnection is a separate decision. Pausing, closing or reconnecting belongs to the application, and the endpoint variable does not control it. Treat the variable as configuration that chooses an address, not as a rule about which network traffic may use afterwards, and the two concerns stay separable.