Claude Code asks before it edits a file or runs a command, and that is a genuinely good design — but it answers a different question from the one you are asking here. The permission prompt is about what the agent may do to your computer. It has nothing to say about whether the authorization check it just wrote is correct, whether the payment handler can be replayed, or whether one customer can read another’s data. You can approve every prompt correctly and still ship an app with a wide-open API. Those are two separate audits, and the second one is the one that reaches your users. Claude Code is not what most people picture when they say vibe coding, and the difference between an agent in your repository and a builder in a browser decides which checks matter.
First: there is no default stack, so find out what you built
Like Cursor and unlike Lovable or Base44, Claude Code ships no database, no login system and no framework. It works on whatever is in the folder you started it in. That means nobody — no article, no checklist, no scanner vendor — can tell you what to fix without reading your repository.
Start at the dependency manifest: package.json, pyproject.toml, requirements.txt, Gemfile, go.mod. That names the framework, and everything below depends on it. Read it rather than assuming, especially if several sessions have added things over weeks.
The check the permission prompt cannot make: can one customer read another’s data?
This is the most common serious bug in an AI-built app, and it is invisible to the permission system by construction. Approving “write to routes/orders.ts” says the agent was allowed to write the file. It says nothing about whether the file it wrote checks who is asking.
The failure has a shape. An endpoint takes an id — an order, an invoice, a document — looks it up, and returns it. What is missing is the line that also asks whether this id belongs to the person making the request. The app works perfectly in testing, because in testing you are always the owner.
Test it by hand, because this one is worth ten minutes. Sign up twice, two email addresses, two browsers. Create something in account A. Copy the address or the API call that loads it. Load it as account B, changing the id. If B sees A’s data, stop and fix that before anything else on this page.
What was in the folder when you started it
Claude Code reads files in the directory you launched it in. That is how it is useful. It also means anything sitting in that tree was readable context: a .env with live keys, a private key, an exported customer list you were poking at, a production log.
The absence of a write permission is not the point — the question is what was in scope to read at all. If sensitive files live inside your project directory, keep them out of scope with a .claudeignore, and move anything that is genuinely not part of the project out of the folder entirely.
And regardless: confirm .env is in your .gitignore, and check the repository history rather than the current files — git log -p | grep -iE "sk-|SECRET|PRIVATE KEY". A key committed in July and deleted in August is still in July’s commit.
The commands you approved quickly
Over a long session the prompts become rhythm, and the ones worth remembering are the ones with effects outside your machine: package installs, git push, anything touching a deployment CLI, database migrations, and any command that reads a secret out of the environment.
Two are worth a specific look before launch. Did a migration run against the live database rather than a local one — check which connection string was in the environment at the time. And did a package get installed that you have never heard of; open package.json and confirm you recognise the dependencies, because a plausible-looking name added mid-session is a real supply-chain route and is easy to wave through at speed.
If you ever used the flag that skips the prompts
There is a mode that bypasses permission checks entirely. It exists for containers and throwaway virtual machines, where the blast radius is the container. Used on your own machine, against a repository that holds live credentials, it removes the one control that was making the difference.
If you have run it outside a sandbox, treat that session the way you would treat a key that was briefly public: go back over what changed, and rotate anything the environment held at the time. Not because something certainly went wrong, but because the check that would have told you was switched off.
Read the generated code in three places, not everywhere
Reviewing everything an agent wrote is not realistic and not necessary. Three places carry most of the risk.
Anywhere money moves. Can the same request be sent twice and charged twice? Is the amount taken from the client, where a user can change it, or recomputed on the server?
Anywhere an identity is decided. Is the user id read from the verified session, or from something the caller supplied — a header, a body field, a query parameter? The second is the bug, and it reads almost identically to the first.
Anywhere a model is called with user input. Is there a ceiling on tokens and on spend? An agent will happily write a loop that calls a model per item with no upper bound, and that is a four-figure bill rather than a breach, which is its own kind of bad week.
The short version
The permission system is doing real work, and it is worth leaving strict rather than loose. But it is a fence around your machine. Your users are on the other side of the app, and nothing in that fence was ever checking the thing they will be affected by. Those checks are the ones above, and they are all things you can do in an afternoon without being a security engineer.
Written September 2026. Claude Code changes quickly; where a flag or a file name has moved, the question it answers has not.
Questions people ask
Does approving Claude Code's permission prompts make my app secure?
No, and this is the trap. The permission prompt governs what the agent may do to your computer. It says nothing about whether the authorization check it wrote is correct, whether a payment can be charged twice, or whether one customer can read another's data. You can approve every prompt correctly and still ship an app with a wide-open API.
What should I review in code Claude Code wrote?
Three places carry most of the risk, and reviewing everything is neither realistic nor necessary. Anywhere money moves: can the same request be sent twice, and is the amount recomputed on the server? Anywhere an identity is decided: is the user id read from the verified session or from something the caller supplied? And anywhere a model is called: is there a ceiling on tokens and spend?
Could Claude Code have read my .env file?
If it was inside the directory you launched from, it was readable context. The absence of a write permission is not the point - the question is what was in scope to read. Keep sensitive paths out with a .claudeignore, move anything that is not part of the project out of the folder, and check your git history rather than your working tree for keys that were committed and later deleted.
I used the flag that skips permission prompts. What now?
That mode is for containers and throwaway virtual machines, where the blast radius is the container. If you ran it on your own machine against a repository holding live credentials, treat that session the way you would treat a briefly public key: review what changed and rotate whatever the environment held at the time.
The same question, other tools
Each of these is a different problem rather than the same article renamed — what goes wrong depends on whether the tool wrote code you can read, or configured a platform you cannot.