Keys Live In .env, Never In Chat
A pasted key sits in chat history under whatever retention your settings dictate. Instead: 'create a .env file for secrets, add it to .gitignore, and verify it can never reach GitHub'. Then point the agent at the file — 'the key lives in .env, take it from there' — so the secret never crosses the chat.
Why it works
A key pasted into chat becomes chat history — stored under whatever retention your settings dictate, far outliving the moment. The .env pattern separates location from value: secrets live in one file, the file is excluded from version control by name, and the agent gets DIRECTIONS to the key rather than the key itself. One sentence sets the whole thing up, plus a proof.
How to do it
- Say: 'create a .env file for this project's secrets and add it to .gitignore.'
- Demand the proof, not the promise: 'verify the file can never be committed or pushed.'
- Put keys into the file yourself (or paste them there directly — the file, not the chat).
- From then on, reference by location: 'the API key is in .env under STRIPE_KEY — use it from there.'
- Grep your own history once: any key you EVER pasted into a chat gets rotated today.
- New machine or teammate? .env travels by secure channel, never by message.
Copy this
Create a .env file for this project's secrets, add it to .gitignore, and verify — show me — that it can never be committed or pushed to GitHub.
What to watch for
- .gitignore protects the repository, not the disk: an agent working in the folder can still read .env. That's the design — it needs the key to use the key — but it means work folders hold work secrets only.
- Screenshots count as pasting: an image of a terminal with a key in it is the same leak with worse searchability.
Sources