Claude Code: Up and Running

Chapter 5. Permissions, Safety, and Trust Boundaries

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 5th chapter of the final book. The GitHub repo is active.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

Chapter 4 changed the shape of the lyrics-trainer. The app was still small, but the work was no longer casual. State, tests, project memory, and context management turned a doghouse into a cabin.

This chapter is about the question that comes next. Before Claude Code changes something that matters, what is it allowed to do?

Permissions sound like an administrative detail, the sort of thing you configure once and forget. In agentic work they turn out to be part of the design. They determine which parts of the system Claude Code can inspect, which parts it can change, which commands it can run, which services it can contact, and when it has to stop and ask you first.

The default answer in Claude Code is conservative. Reading files and exploring the project are low-friction, while editing files, running shell commands, and reaching out to external systems all require permission unless you’ve granted it ahead of time. That friction is useful, because it slows down the exact moment ...