August 25, 2026 · 6 min read

node_modules, .env, and Other Files You Should Never Paste Into an AI Chat

There are two different reasons a file shouldn't end up in an AI chat, and it's worth keeping them separate in your head. One is annoyance — the file is just noise, it'll waste space and add nothing useful. The other is real risk — the file contains something that shouldn't leave your machine at all, for anyone to see, AI chat or otherwise. Only one of these two categories actually matters if you're in a hurry. Here's how to tell them apart.

The noise category: wastes space, doesn't hurt you

Most of what people accidentally paste into AI tools falls here. It's not dangerous, it's just dead weight:

• node_modules/ and other dependency folders — third-party code the model doesn't need to see to help with your project.
• Lockfiles — package-lock.json, yarn.lock, and similar. Machine-generated, not something you're going to ask an AI to reason about.
• Build output — dist/, build/, .next/. Compiled artifacts, not source.

None of this will hurt you if it slips in. It'll just eat context budget for no benefit, which is annoying but recoverable — worst case, you trim it and try again.

The category that actually matters

This is the one worth being careful about, because the cost of a mistake here isn't "wasted tokens," it's "a credential is now sitting in a chat log somewhere outside your control."

• .env files — API keys, database URLs, third-party service credentials. Genuinely the single most common way secrets end up somewhere they shouldn't. Easy to grab by accident when you're selecting "all the config files" for context.
• Private keys — SSH keys, TLS certificates, anything ending in .pem or .key, or named something like id_rsa. These aren't project-specific secrets, either — a leaked SSH key can be reused well beyond the one repo it came from.
• Service account credentials — cloud provider JSON key files, often sitting quietly in a project folder because they were needed once for local development and never moved somewhere safer.
• Anything named "secrets" — secrets.yml, secrets.json, and similar. Usually exactly what the name suggests.

The uncomfortable part is that most people don't paste these on purpose. It happens while selecting "all the config files" in a hurry, or dragging an entire project folder into a tool without checking what's actually in it. The intent was never to share a credential — it just came along for the ride.

Why being in .gitignore doesn't help here

A common assumption: "it's in .gitignore, so it's fine." That protects the file from ending up in your git history, which is genuinely useful — but it does nothing for a tool that reads your local folder directly. .gitignore is a git convention, not a filesystem permission. A local-folder tool that isn't specifically checking for secret files will happily read a gitignored .env right alongside everything else, because as far as the filesystem is concerned, it's just another file sitting there.

What to actually do about it

The reliable fix isn't "be more careful" — that works until the one time you're not. It's using a tool that checks for this automatically, before anything gets included, rather than relying on you to remember every time. Filenames like .env, key file extensions, and known secret-file patterns are detectable without much cleverness — the hard part is remembering to check consistently, which is exactly the kind of thing worth automating away rather than doing by memory on a deadline.

repoprep blocks known secret and credential patterns automatically before they're added to any context — .env files, private keys, service account JSON, and similar — regardless of which workflow you're using.