Why Does Claude Say Bash? What the Tool Is Doing

When Claude says "Bash" during a coding session, it is using a tool that executes shell commands in your environment. Claude Code can run build commands, install dependencies, run tests, move files and perform other terminal operations as part of completing a task. Tools like fenbs keep the project rules that should govern those actions in a shared record, so every connected assistant knows what it is and is not allowed to do before it reaches for the shell.

The Bash tool is one of several tools Claude Code can use. Others include file reading, file editing and web search. Bash is the one with the widest reach: a shell command can touch any file in scope, start processes, call external services and make changes that are not always reversible. That is why understanding what it is doing matters.

Why Claude uses Bash during coding tasks

Claude uses Bash because some tasks require it. Running tests to verify a change cannot be done by reading a file. Checking a build output requires compiling. Installing a package requires a package manager. For a coding agent to complete a multi-step task from plan to verification, shell access is often unavoidable.

Claude Code is designed to complete tasks end to end, which means reading code, editing it, running commands to verify the change and reporting the result. The Bash tool is how it handles the running and verifying part. Without it, Claude can suggest a fix but cannot confirm that the fix works.

What Claude is doing when it calls Bash

Before executing a Bash command, Claude Code displays the command it is about to run and, in many configurations, waits for your approval. The display is the Bash tool call: a command string, the working directory, and sometimes a brief explanation of why it is running the command.

Read the command before approving it. Common commands in a coding session include npm install, git status, python -m pytest, ls -la and file-moving operations. Less common commands that touch external services, delete files or modify system configuration deserve more scrutiny.

If a command looks unexpected, ask Claude why it is running before approving. Claude can explain the reasoning behind any tool call if you ask. An explanation that makes sense in context is a green light; an explanation that does not match the task you described is a reason to pause and clarify.

How to set boundaries on Bash access

Claude Code's default behavior is to ask for confirmation before each tool call, including Bash. You can configure how much autonomy it has. Keep confirmation on for commands that are unfamiliar, that touch files outside the project directory or that interact with external services.

For a project where you know the expected command set (tests run with pytest, builds run with make), you can pre-approve those specific commands. For everything else, confirmation stays on. This approach reduces friction for expected actions without opening the door to unexpected ones.

Write those boundaries as Decisions and rules in fenbs. A rule that says "run npm test autonomously but ask before any git push" is a project decision, not a conversation setting. It should apply to every connected assistant in every session.

Reviewing what Bash did after a session

After a Claude Code session that used Bash, review what changed. git status shows modified files; git diff shows the changes. Compare the changes against what the task was supposed to do. If Claude ran a command you did not review at the time, that is the one to examine first.

For anything that looks unexpected, check the session history. Claude Code logs tool calls in its output. Find the Bash call that produced the change and trace it back to the task step it was meant to serve. If the connection is unclear, ask Claude to explain it in a follow-up message.

Understanding common Bash patterns in Claude Code

Most Bash calls in a coding session fall into predictable categories: package management (npm install, pip install), test running (pytest, jest, go test), build commands (make, cargo build, gradle), file system inspection (ls, find, cat), and version control checks (git status, git diff). Familiarize yourself with the expected commands for your project so you can spot an unexpected one quickly.

Commands that fall outside those categories deserve more attention. A curl to an external service, a chmod or chown, a rm -rf, or a sed -i that touches a file you did not ask about are all worth pausing on before approving. None of them is automatically wrong, but each one has a higher potential impact than a test runner invocation.

How to do this with fenbs

1. Create a free account and add the project. Write the allowed command set and any off-limits operations as Decisions and rules. Every connected Claude Code session reads those rules first.
2. Add the current task to fenbs with the accepted scope. Include which directories and commands are in scope for this specific task.
3. Connect Claude Code over MCP from Integrations and ask it to read the project context before starting. It sees the Bash rules without you re-stating them in the chat.
4. During the session, review each Bash call before approving it. After the session, run a git diff to verify that the changes match what was planned.
5. If a Bash call produced an unexpected result, note it in the task. If the same category of unexpected action appears twice, add a Decisions and rules entry to prevent it.