AI Coding Agent Gitignore: Five Mistakes to Catch

Most AI coding agent gitignore problems come down to five mistakes, and none of them show up as an error. The agent adds a line to .gitignore, says the file is now ignored, and the file keeps getting committed anyway. Or it ignores too much and quietly drops something you needed. The fixes are small once you know which mistake you are looking at, and git has commands that tell you in seconds.

Here is each mistake, how to confirm it, and what to do.

1. The file was already tracked

This is the classic. An agent creates .env, commits it, later notices, and adds .env to .gitignore. Nothing changes. The git documentation is direct about it: "Files already tracked by Git are not affected."

To stop tracking a file that is currently tracked, you remove it from the index while keeping it on disk:

git rm --cached .env
git commit -m "Stop tracking .env"

To find every file in this state at once, ask git which tracked files match your ignore rules:

git ls-files -ci --exclude-standard

Anything that prints is committed and supposedly ignored. If the file held a secret, untracking is not enough, because the old commits still contain it. GitHub's guidance on removing sensitive data from a repository says the first step is to revoke or rotate the secret. Rewriting history comes after, and may not be needed once the credential is dead. The full playbook is in what to do if an AI coding agent commits a secret.

2. The pattern does not match what you think

Agents write patterns from habit. .env matches a file called .env but not .env.local or .env.production. *.env matches prod.env but not .env itself in some setups. A pattern like .env* catches the whole family, but it also catches .env.example, which you usually want committed so teammates know what variables exist.

The way out is a negation:

.env*
!.env.example

Do not guess whether it worked. Ask git, with the path you care about:

git check-ignore -v .env.local

It prints the file and line number of the rule that matches. No output means the path is not ignored.

3. Ignoring a folder, then trying to re-include a file inside it

An agent ignores config/ and then adds !config/public.json to keep one file. It does not work. The git documentation says: "It is not possible to re-include a file if a parent directory of that file is excluded." Git does not even look inside excluded directories.

The fix is to ignore the contents, not the directory:

config/*
!config/public.json

Trailing slashes matter here too. A pattern ending in / only matches directories, so build/ ignores a directory called build but not a file with that name.

4. Ignoring the wrong things

This is the opposite error, and it is quiet in a different way. Agents sometimes ignore a lockfile because it looks like noise, or ignore a whole dist/ folder your host actually deploys from, or add *.json and take package.json out of version control with it. Everything works on the agent's machine because the files still exist locally, then a fresh clone or a deploy fails.

Test the repo the way a stranger would receive it:

git clone . /tmp/fresh-check
cd /tmp/fresh-check

Then install and build there. If it fails, something needed is missing from the commit. Lockfile churn is a related headache, covered in what a lockfile is and why AI agents change it.

5. Agent scratch files in the shared ignore list

Agents leave working files behind: notes, logs, cached plans, local settings. Teams often fix this by adding each tool's folder to the project .gitignore, which then lists every tool anyone ever tried. Git has a better place for personal clutter. Per its documentation, ignore patterns come from several sources, in this order of precedence: the command line, .gitignore files in the directory and its parents, $GIT_COMMON_DIR/info/exclude (that is .git/info/exclude in a normal repo), and finally the file named by core.excludesFile.

So put personal and tool-specific entries in .git/info/exclude for one repo, or in a global ignore file for all of them, and keep the shared .gitignore for things everyone building the project needs to skip.

An AI coding agent gitignore audit you can run in five minutes

Give the agent this as a task, then verify the output yourself:

1. Run git ls-files -ci --exclude-standard and report every tracked file that should be ignored.

2. For each of .env, .env.local, node_modules, the build output folder and the log folder, run git check-ignore -v and show the result.

3. Confirm .env.example is tracked and contains no real values.

4. Do a fresh clone into a temporary folder and run the build.

Put the rules where the agent reads them

Most of these mistakes repeat because the agent starts each session without remembering the last one. A few lines in your agent instructions file prevent a lot of them:

When you create a file that holds secrets or generated output, add its
ignore rule in the same commit and verify with `git check-ignore -v`.
Never ignore lockfiles or the folder the host deploys from.
Run `git status` and read it before any `git add`.

How to write that file is covered in how to write an AGENTS.md file. Reading the diff before it merges catches most of this too; reviewing an AI agent's git diff before merging lists what to look for, and using git with an AI coding agent safely covers the wider habits. For the bigger map of tools and risks, start at the AI coding tools guide.

Frequently asked questions

Why is my .gitignore not working?

The file is almost certainly already tracked. Run git ls-files to confirm, then git rm --cached on the file and commit. The ignore rule only applies to untracked files.

Does adding a file to .gitignore remove it from my repository history?

No. It only affects future tracking. Anything committed earlier stays in history until history is rewritten, which is why leaked credentials must be rotated.

How do I see which rule is ignoring a file?

Run git check-ignore -v path/to/file. It prints the source file, line number and pattern that matched.

Should AI agents be allowed to edit .gitignore?

Yes, but review the change like code. A one-line edit can untrack a lockfile or hide a needed folder, so check the diff and test a fresh clone.