Fix Claude Code Bash Tool Execution Errors — Timeouts, Permission Denied, and Truncated Output

Understanding Bash Tool Errors in Claude Code

The Bash tool is the backbone of development workflows in Claude Code. From running npm install and git push to executing build scripts and test suites, nearly every coding task involves shell command execution at some point.

But things don't always go smoothly. You might run into situations where commands time out without returning results, fail with cryptic permission errors, or produce output that gets cut off before you can see whether the operation succeeded. These issues can bring your workflow to a grinding halt.

Here are the most common Bash tool errors you'll encounter:

• Commands timing out before completion
• Permission denied errors blocking file operations or command execution
• Output getting truncated so you can't see the full result
• ENOENT (file not found) errors causing script failures
• Environment variables not being set as expected

This guide walks through each of these problems with clear explanations of why they happen and step-by-step instructions to fix them. Bookmark it as a reference — you'll likely come back to it more than once.

Fixing Timeout Errors

What It Looks Like

When a command runs too long, you'll see something like this:

Command timed out after 120000ms

The default timeout is 120 seconds (2 minutes). Build processes, test suites, and large dependency installations frequently exceed this limit.

Why It Happens

There are three main reasons a command times out:

1. The command genuinely takes a long time. Large-scale npm install operations, full project builds, and integration test suites are inherently time-consuming.

2. The command is waiting for interactive input. Commands like git rebase -i or npm init (interactive mode) expect user input that will never arrive. The Bash tool runs in non-interactive mode, so any command that prompts for input will hang indefinitely.

3. An infinite loop or deadlock. A bug in a script can cause execution to continue forever.

How to Fix It

Step 1: Extend the timeout

Claude Code supports timeouts up to 600 seconds (10 minutes). For long-running builds and tests, request a longer timeout explicitly.

# For a long build process
# Set timeout to 300 seconds (5 minutes)
npm run build
 
# For integration tests, use the full 10-minute limit
npm run test:integration

Step 2: Convert interactive commands to non-interactive mode

Always use non-interactive flags when running commands through the Bash tool.

# ❌ Interactive mode (will timeout)
npm init
git rebase -i main
 
# ✅ Non-interactive mode (completes normally)
npm init -y
git rebase main  # Remove the -i flag

Step 3: Use background execution for long tasks

When you don't need to wait for a command to complete immediately, run it in the background.

# Run build in the background
npm run build > /tmp/build.log 2>&1 &
BUILD_PID=$!
echo "Build started with PID: $BUILD_PID"
 
# Check results later
wait $BUILD_PID && echo "SUCCESS" || echo "FAILED"
cat /tmp/build.log

Fixing Permission Denied Errors

What It Looks Like

You'll see errors like these when permission issues arise:

bash: ./script.sh: Permission denied
# or
EACCES: permission denied, open '/path/to/file'
# or
fatal: could not create work tree dir: Permission denied

Why It Happens

1. Missing execute permission on scripts. Shell scripts need the execute (+x) permission bit to be run directly.

2. File system write restrictions. Certain directories in Claude Code's sandbox environment have write restrictions.

3. Operations requiring root access. System-level operations that need sudo generally can't be performed in the Claude Code environment.

4. Lock file conflicts. Another process may be holding a lock on the file you're trying to access.

How to Fix It

Step 1: Check and grant execute permission

# Check current permissions
ls -la script.sh
# Output: -rw-r--r-- 1 user group 1234 Apr 8 10:00 script.sh
# → No execute (x) permission
 
# Grant execute permission
chmod +x script.sh
 
# Alternative: run via bash (no permission change needed)
bash script.sh

Step 2: Use writable directories

# ❌ Restricted directory
git clone https://github.com/user/repo.git /opt/repo
 
# ✅ Writable directory
git clone https://github.com/user/repo.git /tmp/repo

Step 3: Remove stale lock files

# Remove npm lock files
rm -f package-lock.json
rm -rf node_modules/.package-lock.json
 
# Remove git lock files
rm -f .git/index.lock

Fixing Truncated Output

What It Looks Like

Command output gets cut off partway through, making it impossible to see whether the command succeeded or what errors occurred.

# Running a verbose command
npm install
# → Output cuts off mid-stream, can't tell if it succeeded

Why It Happens

1. Output buffer limits. The Bash tool has a maximum output size. Commands that generate large amounts of log data will have their output truncated.

2. Mixed stdout and stderr streams. When standard output and standard error are interleaved, important error messages can get lost in the noise.

How to Fix It

Step 1: Redirect output to a file

# Save all output to a file, then check the end
npm install > /tmp/npm-output.log 2>&1
echo "Exit code: $?"
tail -20 /tmp/npm-output.log

Step 2: Filter for what matters

# Extract only error lines
npm run build 2>&1 | grep -E "error|Error|ERROR|failed|Failed" | tail -20
 
# Get just the test summary
npm test 2>&1 | tail -30

Step 3: Suppress verbose output

# Minimize npm output
npm install --silent
# or
npm install --loglevel=error
 
# Quiet pip installation
pip install package-name --quiet --break-system-packages

Fixing ENOENT (File Not Found) Errors

What It Looks Like

Error: ENOENT: no such file or directory, open '/path/to/file'
# or
bash: node: command not found
# or
/usr/bin/env: 'python3': No such file or directory

Why It Happens

1. Working directory mismatch. The Bash tool's shell state (including the current directory) can reset between command invocations. A cd in one command may not carry over to the next.

2. Incorrect path references. Relative paths can resolve to unexpected locations when the working directory isn't what you expect.

3. Missing commands or packages. The command you're trying to run may not be installed globally.

How to Fix It

Step 1: Always use absolute paths

# ❌ Relative paths are fragile
cd project && node scripts/build.js
 
# ✅ Absolute paths are reliable
node /tmp/repos/project/scripts/build.js
 
# ✅ Or chain cd with execution in one command
cd /tmp/repos/project && node scripts/build.js

Step 2: Verify file existence before operating

# Check if the file exists first
FILE="/tmp/repos/project/package.json"
if [ -f "$FILE" ]; then
  echo "File exists"
  cat "$FILE" | head -5
else
  echo "File not found: $FILE"
  ls -la "$(dirname "$FILE")"
fi

Step 3: Verify command availability

# Check where commands are located
which node
which python3
which npm
 
# Check the PATH
echo $PATH
 
# Use npx for locally installed packages
npx tsc --version

Fixing Environment Variable Issues

What It Looks Like

# You set an environment variable, but it's empty in the next command
echo $MY_API_KEY
# → (empty)
 
# Or .env values aren't being loaded
node -e "console.log(process.env.DATABASE_URL)"
# → undefined

Why It Happens

Each Bash tool invocation runs in its own independent shell session. Environment variables exported in one command don't carry over to subsequent commands. This is by design — each execution starts with a clean shell environment.

How to Fix It

Step 1: Set and use variables in a single command

# ❌ Separate commands don't share state
# Command 1: export MY_VAR="hello"
# Command 2: echo $MY_VAR  → empty
 
# ✅ Keep everything in one command
export MY_VAR="hello" && echo $MY_VAR
 
# ✅ Inline environment variables
MY_VAR="hello" node -e "console.log(process.env.MY_VAR)"

Step 2: Source .env files explicitly

# Load .env into the current shell
set -a && source .env && set +a && node server.js
 
# Or use dotenv (Node.js)
node -r dotenv/config server.js

Step 3: Persist in configuration files

For variables you need repeatedly, write them to project configuration files.

# Write to .env
echo 'DATABASE_URL=postgresql://localhost/mydb' >> .env
echo 'NODE_ENV=development' >> .env
 
# Use npm scripts for environment setup
# "scripts": {
#   "dev": "NODE_ENV=development node server.js"
# }

Verifying the Fix

After applying a fix, run through these checks to confirm everything is working:

# 1. Basic command execution test
echo "Hello from Bash tool" && echo "Exit code: $?"
 
# 2. File permission test
touch /tmp/test-permission.txt && echo "Write OK" && rm /tmp/test-permission.txt
 
# 3. Node.js / Python execution test
node -e "console.log('Node.js OK:', process.version)"
python3 -c "import sys; print(f'Python OK: {sys.version}')"
 
# 4. Network connectivity test
curl -s -o /dev/null -w "%{http_code}" https://api.anthropic.com/v1/messages
# → 401 means network is fine (auth error proves connectivity)
 
# 5. Git operations test
cd /tmp && git init test-repo && cd test-repo && echo "test" > test.txt && git add . && git commit -m "test" && echo "Git OK" && rm -rf /tmp/test-repo

If all tests pass, your Bash tool is functioning correctly.

Prevention — Best Practices to Avoid Bash Tool Errors

Building these habits into your daily workflow will dramatically reduce how often you encounter Bash tool errors.

1. Always use absolute paths. Store your project directory in a variable and reference it consistently rather than relying on relative paths.

WORK="/tmp/repos/my-project"
cd "$WORK" && npm run build

2. Chain cd with operations using &&. This ensures the directory change succeeds before the command runs.

cd /tmp/repos/my-project && npm test

3. Build in error handling. Use set -e to stop execution immediately when any command fails.

set -e
cd /tmp/repos/my-project
npm install
npm run build
echo "All steps completed successfully"

4. Manage output proactively. For any command you expect to produce heavy output, redirect to a file and check the tail from the start.

5. Avoid interactive commands entirely. In the Claude Code environment, always use -y, --non-interactive, or equivalent flags.

Looking back

Bash tool execution errors in Claude Code are predictable and fixable once you understand the patterns. Here's a quick reference for the most common issues:

• Timeouts: Extend the timeout limit, use non-interactive flags, or run tasks in the background
• Permission Denied: Grant execute permission, use writable directories, or remove stale lock files
• Truncated Output: Redirect to files, filter for relevant lines, or suppress verbose logging
• ENOENT: Use absolute paths, verify file existence, and check command availability
• Environment Variables: Set and use within a single command, or explicitly source .env files

When you hit an error, start by reading the error message carefully and matching it to the relevant section in this guide. Most issues can be resolved in just a few minutes.

You might also find these related articles helpful:

• Claude Code settings.json Complete Guide — Deep dive into configuration options
• Claude Code Not Working Checklist — Broader troubleshooting for Claude Code issues
• Claude Code Setup Troubleshooting FAQ — Common setup problems and solutions