Builds & dev servers

The most common question about putting a vault between your secrets and your tools: "will this break my build?" No. Your build doesn't talk to enveigh, doesn't link a library, and doesn't know enveigh exists. It runs as a normal child process with the same environment variables a .env file would have provided.

Nothing about your project changes

There's no SDK, no code change, no enveigh-aware packages. The direction of the integration is the whole trick. Your build never asks for keys; it gets launched inside them:

you / your agent
 └─ enveigh run --env web -- npm run dev
      ├─ fetches web's bindings from the unlocked app   ← Touch ID gate lives 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 identical whether dotenv loaded a file or enveigh set it at spawn. Hot reload, ports, watch mode, child processes your build spawns: all unaffected, because env vars are inherited down the whole process tree.

The only two "extra steps"

1. The command gets a prefix. npm run build becomes enveigh run --env web -- npm run build, or, when an agent is driving, a run_with_env tool call. The agent skill teaches agents to do this on their own, so in practice it's a habit they adopt, not a step you take.
2. At most one Touch ID tap per environment per session (under the default policy, see the approval table). After the first approval, runs are silent. The app does need to be running and unlocked.

That's the full cost. In exchange: no .env in the repo, nothing in shell history, and the agent never sees a plaintext value.

Finite commands vs dev servers

Two run paths, picked by whether the command finishes:

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

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

A dev server never exits, so run_with_env is the wrong shape for it. The tool call would sit buffering output until the timeout kills the server (ENVEIGH_MCP_TIMEOUT_SECONDS overrides the default 600). Agents running a dev server should use the CLI through their shell, backgrounded, exactly the way they'd background a bare npm run dev.

One honest nuance: redaction is a run_with_env feature, not a CLI feature. The CLI streams your command's real output to your terminal. That's what you want at a keyboard, but it's also why the agent skill tells agents to prefer run_with_env for anything that terminates.

If a build can't find a variable

enveigh run starts the child from a scrubbed copy of your shell's environment: credential-shaped variables exported in the launching shell are stripped before the vault's values are injected, so a stray export OPENAI_API_KEY=… in your profile can't ride into output an agent reads. (SSH_AUTH_SOCK is exempt: it's the ssh-agent's socket path, not a secret, so git-over-SSH inside builds keeps working.)

The consequence: if your build relied on a secret-looking variable that lives only in your shell profile, it won't ride along. The fix is the point of the tool: vault it and bind it to the environment, and it's injected deliberately from then on.

What this is (and isn't) for

This is for your Mac: the app must be running and unlocked, with you there to approve. It's not a CI secrets manager. Your CI runner should keep using its own secret store (GitHub Actions secrets, etc.). enveigh's job is the laptop, where the agents are.

Next: the CLI reference for every command, or the MCP server for what agents see.