Skip to content
try reference course saved
English
Level 6: Trust & Safety
Lesson 7 · +10 XP

Trusting a project

Open Claude Code in a folder you’ve never used it in before, and you’ll see a prompt unlike the others: “Do you trust the files in this folder?” It’s not asking you to approve an action. It’s asking you to vouch for the whole project.

It’s easy to click “yes” without thinking. Don’t.

What’s actually in a folder

Up until now you’ve thought of a codebase as: source files, plus maybe a README. From Level 3 you know it’s also configuration, dependencies, and metadata files like package.json.

What you might not know is that a folder can also contain files that instruct Claude itself:

  • A CLAUDE.md file that tells Claude how to behave in this project.
  • A .claude/ directory with custom commands, settings, and hook scripts.
  • Project-level skills that get loaded automatically.

These exist for good reasons — they’re how a team encodes “here’s how to work in this repo” so Claude is useful from minute one. You’ll write your own in Level 9.

But there’s a flip side.

A repo isn’t just data Claude reads. It’s also instructions Claude follows.

If someone hands you a repo from the internet, their CLAUDE.md is going to be loaded into the conversation. If it says “always commit secrets to git” or “run this shell script before doing anything,” Claude will see those instructions just like it sees yours.

This is sometimes called prompt injection: hostile or unexpected instructions hiding inside content Claude reads.

What to do about it

You don’t need to be paranoid. You do need to be deliberate.

  • Your own projects: trust freely.
  • Your team’s projects: trust, but glance at CLAUDE.md and .claude/ once if you’ve never opened the repo before. Most teams have nothing surprising in there.
  • A stranger’s repo from the internet: read CLAUDE.md, .claude/settings.json, and any hook scripts before trusting. They tell Claude how to behave; you want to know what they say.
  • A repo you’re investigating for a security issue: don’t trust at all. Read it without giving it the keys.

The trust prompt is the gate. Use it the way you’d use the front door — most days you let people in without thinking, but when someone unfamiliar shows up, you actually look.

The same instinct applies to content Claude reads even inside a trusted repo. A README pulled from a sketchy URL. A log file scraped from somewhere. A PR description from an external contributor. Anything that came from outside your team can carry instructions Claude will read like any other prompt.

You don’t need to police every file. You do need to remember: text Claude reads can change what Claude does.

What’s next

You’ve now got the full toolkit for what to do before something goes wrong: read the prompt, know the blast radius, pick the right mode, glance at the project. Next, the toolkit for what to do after — when you approved something and now wish you hadn’t.