Builds & dev servers

The most common question about putting a vault between your secrets and your tools is "will this break my build?" No. Your build does not talk to enveigh, link a library, or know enveigh exists. It runs as a normal child process with the same environment variables a .env file would give it.

Nothing about your project changes

There is no SDK, no code change, and no enveigh-aware package. enveigh starts your build with the keys already in its environment. The build never asks for them.

you / your agent
 └─ enveigh run --env web -- npm run dev
      ├─ fetches web's bindings from the unlocked app   ← the approval policy applies here
      └─ spawns: npm run dev   (DATABASE_URL=…, STRIPE_SECRET_KEY=… already in its env)
           └─ node, vite, next: they just read process.env, same as ever

process.env.DATABASE_URL looks the same whether dotenv loaded a file or enveigh set it at spawn. Hot reload, ports, watch mode, and the child processes your build starts all work as before, because child processes inherit environment variables.

Two extra steps

1. The command gets a prefix. npm run build becomes enveigh run --env web -- npm run build. When an agent drives, it makes a run_with_env tool call instead. The agent skill teaches agents to add the prefix themselves, so you do not do it.
2. At most one approval per environment per session under the default policy. See the approval table. After the first approval, runs are silent. The app must be running and unlocked.

That is the full cost. You get no .env in the repo, nothing in shell history, and an agent that never sees a plaintext value.

Finite commands vs dev servers

Two run paths exist. Pick one by whether the command finishes:

# finite: let the agent use run_with_env, or run it from your terminal:
enveigh run --env web -- npm run build
enveigh run --env web -- npm test

# long-running: always the CLI, in the background like any dev server:
enveigh run --env web -- npm run dev

A dev server never exits, so run_with_env does not fit it. The tool call buffers output until the timeout kills the server. For long commands that do finish, pass timeout_seconds on the call, up to 21600. ENVEIGH_MCP_TIMEOUT_SECONDS in the client's MCP environment changes the default of 600. An agent that runs a dev server should use the CLI through its shell, in the background, as it would for a bare npm run dev.

Redaction is a run_with_env feature, not a CLI feature. The CLI streams your command's real output to your terminal. That is what you want at a keyboard. It is also why the agent skill tells agents to prefer run_with_env for anything that ends.

If a build can't find a variable

enveigh run starts the child from a scrubbed copy of your shell's environment. It removes credential-shaped variables before it injects the vault's values, so a stray export OPENAI_API_KEY=… in your profile cannot reach output an agent reads. SSH_AUTH_SOCK is kept. It is the ssh-agent's socket path, not a secret, so git over SSH inside builds keeps working.

If your build relied on a secret-looking variable that exists only in your shell profile, that variable is now missing. Vault it and bind it to the environment. enveigh then injects it on purpose.

What this is (and isn't) for

This is for your computer: the app or service must be running and unlocked, with you there to approve. It is not a CI secrets manager. Your CI runner should keep its own secret store, such as GitHub Actions secrets. enveigh covers the laptop, where the agents run.

Next: the CLI reference lists every command. The MCP server page shows what agents see.