Running Commands: the Bash Tool and Why Permissions Matter
Running Commands: the Bash Tool and Why Permissions Matter
~6 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026
Reading and changing files alone isn't enough to move a software project forward - at some point commands need to run: running tests, installing packages, starting the server. That's exactly what the Bash tool is for: it lets Claude Code run commands directly in your terminal, the same way you would yourself.
What the Bash tool can do
With the Bash tool, Claude Code can in principle run anything you could run in your own terminal: start a test command, add a package via npm install, create a directory, check the current git status, kick off a build script. That's the key difference from a plain chat assistant: Claude Code doesn't just suggest a change, it can implement it, run it, and check the result - for example whether tests are still passing after a change.
npm test
git status
npm run buildClaude Code doesn't run such commands "secretly" - every call to the Bash tool is visible to you, so you see exactly which command runs and what output it produces.
Why permissions matter so much here
Unlike the pure read tools from chapter 6, the Bash tool can potentially have far-reaching effects: a command can delete files, change data in a database, trigger network access, or change system settings - depending on exactly what's run. A typo or a misunderstood instruction can, in the worst case, cause real damage - for example if the wrong folder gets deleted by accident.
That's why Claude Code asks for confirmation by default before running a command through the Bash tool - you see the planned command and decide whether it's allowed to run. That's not a formality, it's a real safety layer: you remain the one with final control over actions that could have far-reaching consequences.
Achtung: Especially for commands that could delete or overwrite data (delete commands, database migrations, force-pushing in git), always check exactly what's about to run before approving it - even if the command looks reasonable. When in doubt, ask one extra question rather than confirming an unwanted action.
Good practice with the Bash tool
- Read the proposed command before confirming it - even once it becomes second nature to move fast.
- For unclear commands, ask for a brief explanation of what the command does.
- Be especially alert for irreversible actions (deleting, force-pushing, production deployments).
- Where possible, use test environments instead of production systems when trying out commands.
How you deliberately control this confirmation behaviour - from "always ask" to "never ask" - is explained in detail in the next chapter: Claude Code's different permission modes.