Is the app Claude Code built secure?

Claude Code is Anthropic's coding agent. It works inside your project folder, reads files, edits code and runs commands, with a permission system that decides which of those it may do without asking. You control that in settings, and you can deny it access to specific files such as .env.

The app it writes is a separate question. Claude Code writes what the task asks for. If the task is to make a failing API call work, the quickest path can be one you would not choose on purpose, like calling the API from the browser with the key attached. Nothing on your host stops that from going live.

• A secret key moved into a NEXT_PUBLIC_ or VITE_ variable, or hardcoded in a component, to fix an undefined variable in client code.
• A .env file created inside public/ or static/, or a build step that copies it into the output folder.
• A .env committed to git because .gitignore was missing or incomplete when the project started.
• CORS loosened to reflect any origin with credentials to silence a browser error.
• Row level security disabled, or a policy set to true, to fix a permission denied error from Supabase.
• A new project with no security headers, because nothing in the task asked for them.
• Login cookies set without Secure or HttpOnly.

None of these are unique to Claude Code. They are the shortcuts any fast developer, human or agent, takes under pressure. The difference is speed: an agent can make several of them in one session.

Claude Code reads a CLAUDE.md file at the root of your project on every session. Rules written there apply to all the work it does:

## Security rules
- Never put secret keys in NEXT_PUBLIC_ or VITE_ variables or in client code.
- Calls that need a secret key go in server routes only.
- Never create or copy .env files into public/ or the build output.
- Never disable row level security or add a policy that uses true.
- Never set CORS to reflect the request origin with credentials.

You can also stop it reading secrets at all with deny rules in your project settings:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Claude Code has a built-in /security-review command that reviews your pending changes for vulnerabilities in the code. Run it before you merge. It reads source, so it can catch things like missing authorization checks that no outside scan can see.

It cannot see what your host actually serves. Headers, a stray .env on the live domain and cookie flags only exist on the running site. An outside scan checks those: secret keys in your HTML and JavaScript bundles, public .env and .git files, security headers, the https redirect, cookie flags and CORS. It does not read your repository, test logins or look for injection bugs, so the two checks cover different ground.

Review this project for security before I deploy. List any secret key that could reach the browser, including through NEXT_PUBLIC_ or VITE_ variables. Confirm .env files are in .gitignore and are never copied into public/ or the build output. Add security headers for our host. Make session cookies Secure and HttpOnly. Show me each change before you make it.

1. Run git log --all -- .env and git ls-files | grep env to make sure no env file was ever committed. Rotate anything that was.
2. Search the build output folder for .env and for key prefixes such as sk_live_, sk-, AKIA and ghp_.
3. Check every public-prefixed env variable. None should be a secret.
4. Run /security-review on your changes.
5. Add security headers in the config for your host.
6. Deploy, then scan the live URL and fix what it finds.