Five AI setup mistakes that quietly cost you

Every one of these is silent. Nothing turns red, nothing fails, and you find out in March. That is the category of problem I spend most of my time on, so here are the five I see most.

1. A .claudeignore file that does nothing at all

People create one because the name looks like .gitignore and assume it is keeping files away from the AI. It is not. From the permissions documentation:

If your project has a .claudeignore file, it has no effect, so move its entries into Read deny rules.

So the file sits there looking like protection and providing none. If you have one, the fix is to move each line into a Read deny rule and delete the file so nobody is reassured by it again.

2. Treating a deny rule as a security boundary

This one is stated unusually plainly by the vendor, which I respect:

It doesn't match the same program invoked in a different form, so a deny or ask rule covers the invocation Claude usually produces and isn't a security boundary around the program.

Their own example: a rule blocking curl * stops curl https://example.com but does not stop /usr/bin/curl https://example.com or sh -c 'curl https://example.com'.

These rules are excellent at stopping the normal path, which is what almost every real mistake travels down. They are not a wall. If something genuinely must not happen, the control belongs somewhere the AI cannot reach at all, like a credential it was never given.

3. A missing space that changes what a rule matches

A rule written Bash(ls *) requires the space, so it does not match lsof. Written Bash(ls*), with no space, it matches lsof too. One character, two different rules, no error either way. Worth reading your own rules once with this in mind.

4. Not knowing where "don't ask again" went

When you click "Yes, and don't ask again", that is not a preference for the moment. The documentation is explicit: the rule is saved to .claude/settings.local.json at the root of your repository, and it applies to future sessions anywhere in that repository, including subdirectories.

That is good behaviour, and it means your permission list is a real document that grows every time you are in a hurry. Open it occasionally and read it as if someone else wrote it. If there is an entry you would not grant today, delete it.

5. The job that finishes clean having done nothing

This is mine rather than the documentation's, and it is the most expensive one on the list.

A job that crashes gets fixed on Tuesday, because something told you. A job that runs, finds nothing to do because a connection quietly broke, and exits successfully will sit there for months looking healthy. Every dashboard says green. Nothing was done.

The fix is not clever: make every job state what it did, what it skipped and why, and make zero work a result it has to announce rather than a silence it can hide in. I run that on my own system and it has caught me more than once.

The thread running through all five

Four of these are things that look like protection and are not, and the fifth is success that looks like success and is not. The habit worth building is to make each control prove itself once: try the thing the rule should stop, and watch it get stopped. A rule nobody has watched fail is not a rule yet, it is a hope.

If you would rather have someone go through this with you against your real setup, the consultation is free and you leave with the list written down either way.

Sources, both fetched 1 October 2026: Configure permissions · Settings files and precedence.