The key to using Claude Code sensibly is to understand that it is not an autocomplete with a long answer but a closed loop. At each step the model gets the system prompt, instructions, the conversation history and the results of past tool calls, and then decides: answer with text or call a tool. If it is a call, the runtime matches it against permissions, hooks and the sandbox, the tool runs or is blocked, the result returns to the model - and the loop continues until the task is solved, a question is asked or the turn ends.
Tools split into categories, and each has its own risk profile. Reading (Read, Glob, Grep) risks leaking secrets and extra context. Editing files (Edit, Write) risks damaging sources, configs or generated files. Shell (Bash) is an arbitrary subprocess, the network and the file system. Web (WebFetch, WebSearch) brings external data and the risk of prompt injection. Agentic, integration and state tools add their own risks: parallel spend, actions in external systems, a wrong model of progress.
There is a subtlety important for rules and hooks: a tool's name in the transcript may differ from the canonical name by which permission rules and hook matchers work. A rule must use exactly the canonical identifier from the tools reference, not what is shown in the log. If an unknown name gets into deny or ask, newer versions show a startup warning - a hint that the rule is written past the real tool.
It helps to gather the tool categories and their risk into a table once, to see where the line of danger runs. Below is such a map - from reading to state. You return to it when configuring permissions and the sandbox: it reminds you that not all tools are equal, and that shell, web and agentic tools need narrower rules than the seemingly harmless reading, which can also leak secrets.
| Category | Examples | Risk |
|---|---|---|
| Reading | Read, Glob, Grep | Leaking secrets and extra context |
| Editing files | Edit, Write, NotebookEdit | Damaging source/config/generated |
| Shell | Bash, PowerShell | An arbitrary subprocess, network, FS |
| Web |
| WebFetch, WebSearch |
| External data and prompt injection |
| Agentic | Agent, Workflow, tasks | Parallel spend and conflicts |
|---|
| Integrations | MCP, Chrome, computer use | Actions in external systems |
|---|
| State | Todo, checkpoints, worktrees | A wrong model of progress |
|---|
The second important understanding is what the model actually knows. "The whole repository" does not enter the context automatically. Inside are the startup prompt and the definitions of available tools, CLAUDE.md, rules without a path constraint and auto memory, the text of your messages, files and outputs that were actually read, summaries after compaction, the content of loaded skills and the results of subagents (not their whole internal transcript). Everything else the model does not see until a tool reads it.
Hence a rule that saves you from false confidence: the claim "Claude understood the project" must be confirmed by evidence, not taken on faith. Evidence comes at four levels. Explanation - the model described the presumed cause. Static check - typecheck, lint, compilation or diff analysis passed. Dynamic - a test reproduces the behavior and passes after the fix. Product observation - the app is built, run, and the result checked via /run, /verify, a browser or a manual scenario.
A good task summary expresses these levels explicitly. It names the cause, the changed files, the commands run with exit codes, what exactly was checked by observation, what remained unchecked and which risks persist. It helps to see such a report template once - it turns a vague "done" into a checkable statement from which you see at which evidence level the agent stopped and where you need to trust versus recheck.
Finally, it is worth keeping in mind the line between a checkpoint and git. Claude Code automatically tracks file edits for rewind, but a checkpoint is a local session mechanism, not long-term history. Git remains the system of history, collaboration and review; before a risky change it helps to have a clean status or a separate worktree. The typical failure is taking an explanation for evidence and relying on a checkpoint as a replacement for a commit; the right approach is to demand verification by observation and keep git as real insurance.
Cause:
Changed files:
Commands and exit codes:
What was checked by observation:
What was not checked:
Remaining risks: