# Keeping credentials out of your coding agent’s model context > Source: > Published: 2026-09-22 10:33:39+00:00 I always had a slightly bad feeling about the credentials my coding agent could access. Did I secure things enough? Probably not. But I also didn't want to cripple it by blocking access to files it needed to understand my project. That left me doing nothing about it. When I learned about hooks in coding agent harnesses, I wondered: could I let the agent read the files, but remove the secret values from the output before it reaches the model? This became [ContextVeil](https://github.com/daniel-sc/contextveil), a small, local, open-source tool. When debugging an application, reading `.env.local` can be quite useful. The model might need to know which database you connect to or whether a feature flag is enabled. But the API token next to these settings usually isn't needed. Of course, credentials should generally live in a credential store. In practice, projects also have `.env` files, configuration files and environment variables containing secrets. And these are not necessarily limited to disposable development credentials. I see this as sensible hygiene: if the model doesn't need the credential, why put it into its context? A value that never reaches the model cannot accidentally be repeated by it in a generated example or a response. For example, Claude Code might run `cat .env.local` and receive: ``` DATABASE_URL=postgres://localhost/my_app API_TOKEN=cv_example_canary_not_a_real_token LOG_LEVEL=debug ``` If you have selected `API_TOKEN` for protection, ContextVeil changes the supported tool result before it reaches the model: ``` DATABASE_URL=postgres://localhost/my_app API_TOKEN= LOG_LEVEL=debug ``` The command still runs and the file is still read. Your application can still use the actual token. The model gets the remaining configuration and can see that an API token is configured. This was the important part for me: I wanted something I would actually enable, without worrying about it refusing legitimate file reads or commands. There are two parts to ContextVeil: `.env` files and supported configuration and credential files. You review the suggestions and choose what to protect. There is no runtime classifier deciding whether some arbitrary output looks suspicious. Matching is exact and deterministic, runs locally, and needs no network connection or additional model. The configuration stores references, such as “the `API_TOKEN` entry in `.env.local`”, rather than copies of the credentials. When that file's value changes, ContextVeil picks it up on the next turn. When you add credentials in new entries or files, rerun setup to include them. ContextVeil supports Linux (including WSL) and macOS. Install it with: ``` curl -fsSL https://raw.githubusercontent.com/daniel-sc/contextveil/v1.0.0/install.sh | bash ``` Then, from your project directory, run the interactive setup in your terminal: ``` contextveil setup ``` Review the suggested sources and select your integration, e.g. Claude Code. Restart the agent and check the installation: ``` contextveil doctor ``` Claude Code is the production-supported integration. Codex CLI, GitHub Copilot CLI and OpenCode are also available as experimental integrations. I personally use it with Codex and OpenCode. For Codex, approve the installed hook through `/hooks` or the **Hooks need review** screen before running the check. ContextVeil reduces accidental exposure of selected, exact secret values. It does not sandbox the agent or prevent commands from using credentials directly, and transformed values such as Base64 are outside its matching scope. Coverage depends on the harness integration; see the [support details](https://github.com/daniel-sc/contextveil#support-and-security-limits). If you've also been uneasy about credential access but reluctant to restrict your coding agent, [give ContextVeil a try](https://github.com/daniel-sc/contextveil). I'd especially like feedback on the setup suggestions and whether it fits into your daily workflow. What would make you keep it enabled—or turn it off?