### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Summary The Bash tool in a Claude Code session consistently fails on every invocation — including trivial, side-effect-free commands like echo hello — ret

Reproducing this on Fedora 44 as well, but on **aarch64 (Asahi Linux on Apple Silicon)**, so it is not x86-specific. - OS: Linux 7.1.6-400.asahi.fc44.aarch64+16k - Shell: bash - Model: Opus 5 (claude-opus-5) - Claude Code version: 2.1.278 - Install: - Working directory: a git repository Confirmed across **two independent sessions** on the same machine — a second, freshly started session reproduced it identically, so it is not session-local state. ### What I measur

[BUG] Bash tool persistently returns exit code 1 with no output in Claude Code session

Status Open

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 5 comments · opened Sep 12, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Summary
The Bash tool in a Claude Code session consistently fails on every invocation — including trivial, side-effect-free commands like echo hello — returning exit code 1 with no stdout, no stderr, and no error message, just a bare <error>Exit code 1</error> marker. The outage has persisted continuously for over 2.5 hours as of this report, across dozens of retries spaced from 90 seconds to 10 minutes apart.

Environment
Interface: Claude Code (VSCode native extension environment)
Model: Sonnet 5 (claude-sonnet-5)
Platform: Linux (host: Fedora, kernel 7.1.10-200.fc44.x86_64)
Shell: bash
Working directory: /home/ostri/ach (a git repository)
Session had been active and functioning normally (many successful Bash calls, builds, perf record runs, git worktree operations) for an extended period before the failure began.
Timeline
Session ran many successful Bash commands over an extended prior period, including: cmake --build, running compiled binaries, git worktree add, perf record/perf report, strace, file edits via other tools — all functioning normally.
At one point, mid-session, a routine command (for i in 1 2 3; do ./pacs8 ...; done) was issued and ran successfully in the background (confirmed via a completed task-notification with real stdout captured).
Shortly after, every subsequent Bash call began failing with exit code 1 and empty output — including the most trivial possible commands (echo hello, true, date).
This failure mode has been fully reproducible and 100% consistent since onset: dozens of retries over 2.5+ hours, at varying intervals (90s, 2min, 3min, 5min, 10min), all fail identically.
The failure occurs both in synchronous mode and in run_in_background: true mode (tested explicitly — background-mode invocation also failed, confirmed via its own task-notification reporting status: failed, exit code 1).
The failure was also reproduced in a freshly spawned subagent (via the Agent tool, general-purpose subagent type, brand-new context/conversation) — that subagent's own first-ever Bash call (echo hello) failed identically (exit code 1, no output). This rules out any state corruption specific to the parent conversation's context and points to the underlying execution sandbox/infrastructure itself.
Other tools in the same session remain fully functional throughout the outage: Read, Edit, Write, WebFetch, ScheduleWakeup, Agent all work normally. The failure is isolated to the Bash tool (command execution) specifically.

What Should Happen?

echo hello (or any equivalent trivial command) should succeed with exit code 0 and print hello to stdout, as it always had earlier in the same session.

Error Messages/Logs

Every Bash invocation, regardless of command content, immediately returns:


<error>Exit code 1</error>
with no stdout, no stderr, and no further diagnostic information surfaced to the model or (presumably) the user.

Diagnostic steps already taken (to save reproduction effort)
Confirmed the failure is content-independent: tried echo hello, echo test123, true, date, and various cd ... && cmake/git/... compound commands — all fail identically.
Confirmed it is not a transient blip: retried at 90s, 2min, 3min, 5min, and 10min intervals continuously for 2.5+ hours; zero successes.
Confirmed it is not synchronous-mode-specific: run_in_background: true also fails (task-notification shows status: failed, exit code 1).
Confirmed it is not conversation/context-specific: a freshly spawned subagent (separate context) hit the identical failure on its very first Bash call.
Confirmed other tool categories are unaffected: Read/Edit/Write/WebFetch/ScheduleWakeup/Agent (spawn) all continued working normally throughout.
Checked the public status page (status.claude.com) at multiple points during the outage: it reports Claude Code as "Operational", no matching incident — the only active incident listed is unrelated ("Claude Cowork" on Windows, a Microsoft-update-caused local-drive-access issue, not applicable here: this session is Linux-based, not Cowork).

Steps to Reproduce

Actual behavior
Every Bash invocation, regardless of command content, immediately returns:

<error>Exit code 1</error>
with no stdout, no stderr, and no further diagnostic information surfaced to the model or (presumably) the user.

Diagnostic steps already taken (to save reproduction effort)
Confirmed the failure is content-independent: tried echo hello, echo test123, true, date, and various cd ... && cmake/git/... compound commands — all fail identically.
Confirmed it is not a transient blip: retried at 90s, 2min, 3min, 5min, and 10min intervals continuously for 2.5+ hours; zero successes.
Confirmed it is not synchronous-mode-specific: run_in_background: true also fails (task-notification shows status: failed, exit code 1).
Confirmed it is not conversation/context-specific: a freshly spawned subagent (separate context) hit the identical failure on its very first Bash call.
Confirmed other tool categories are unaffected: Read/Edit/Write/WebFetch/ScheduleWakeup/Agent (spawn) all continued working normally throughout.
Checked the public status page (status.claude.com) at multiple points during the outage: it reports Claude Code as "Operational", no matching incident — the only active incident listed is unrelated ("Claude Cowork" on Windows, a Microsoft-update-caused local-drive-access issue, not applicable here: this session is Linux-based, not Cowork).

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

claude code

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

5 Comments

mildronize · 1 month ago

I got the same problem today on claude v2.1.270

mildronize · 1 month ago

It’s work now , after I restart the pc. I guess the kernel got the updated

kernel banner went 7.0.0-29-generic → 7.0.0-31-generic

ostri · 22 days ago

It was lack of space on /tmp drive. Claude code falsely reported as problem with bash tool.

From: Thada Wangthammang @.*>
Sent: Monday, September 14, 2026 12:22 PM
To: anthropics/claude-code @.*>
Cc: ostri @.>; Author @.>
Subject: Re: [anthropics/claude-code] [BUG] Bash tool persistently returns exit code 1 with no output in Claude Code session (Issue #93838)

<https://avatars.githubusercontent.com/u/3647850?s=20&v=4> mildronize left a comment (anthropics/claude-code#93838) <https://github.com/anthropics/claude-code/issues/93838#issuecomment-5662483733>

I got the same problem today on claude v2.1.270

—
Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/93838?email_source=notifications&email_token=ADDYSKQL4PS33UWFRVKDTU35O7BEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRWGI2DQMZXGMZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5662483733> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDYSKSSE6XW367HPNBZHJT5O7BEDAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TKNBTGQYTKOBTHE3KC5QC> .
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ADDYSKUQMX3L3BFZGJHOLED5O7BEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRWGI2DQMZXGMZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/ADDYSKX3XX27PKKUQY7GJPL5O7BEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRWGI2DQMZXGMZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA> . Download it today!
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/ADDYSKWEAJKOCXGEGDSEFWD5O7BEDBFCNFSM6AAAAAC7PKGMR6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACUMCUUK2M4TFMFZW63VGMF2XI2DPOI.gif> Message ID: @. @.> >

tobstarr · 22 days ago

Reproducing this on Fedora 44 as well, but on aarch64 (Asahi Linux on Apple Silicon),
so it is not x86-specific.

OS: Linux 7.1.6-400.asahi.fc44.aarch64+16k
Shell: bash
Model: Opus 5 (claude-opus-5)
Claude Code version: 2.1.278
Install: <npm / native installer / …>
Working directory: a git repository

Confirmed across two independent sessions on the same machine — a second, freshly
started session reproduced it identically, so it is not session-local state.

What I measured

| Command | Tool result |
|---|---|
| echo BASH_TEST_OK | Exit code 1, no output |
| echo before; echo "check: $?" | Exit code 1, no output |
| printf 'PRINTF_OK\n' | Exit code 1, no output |
| /bin/echo BINECHO_OK | Exit code 1, no output |
| cat /etc/hostname | Exit code 1, no output |
| echo TO_STDERR >&2; exit 0 | (Bash completed with no output) |

The pattern matches #86853 exactly: anything that would write to stdout comes back as a
bare Exit code 1 with no text, while a command that writes nothing to stdout "succeeds".
It makes no difference whether the command is a shell builtin (echo), an external binary
(/bin/echo, cat), or printf. In the stderr case the stderr line was not surfaced either.

One detail that differs from #86853

#86853 lists "write to a file, read it back with the Read tool" as a working workaround.
That does not work here:

echo BASH_TEST_OK > <scratchpad>/bashtest.txt; echo done
printf 'WRITE_TEST_%s\n' "$$" > <scratchpad>/bashtest2.txt 2>/dev/null

Both returned Exit code 1. Both target files were created, but reading them back with
the Read tool showed them empty — including the second one, which produces no stdout at
all and redirects stderr to /dev/null.

So the redirection is set up (the file appears), but the command body's output never lands
anywhere. That suggests the failure is upstream of stdout capture — the command payload does
not appear to execute at all — rather than purely a result-formatting/capture bug.

Unaffected

Read, Write and WebFetch all work normally in the same sessions. Only the Bash tool is affected.

tobstarr · 22 days ago

Correction to my comment above — in my case this turned out to be a local
cause, not a Claude Code regression. Leaving the details here anyway,
because the way it presented is a genuine reporting bug and may be what some
others in this thread are hitting.

### Root cause on my machine

My /tmp is a tmpfs mounted with usrquota, and my user had hit the quota:

$ quota -s
Disk quotas for user tobias (uid 1000):
Filesystem space quota limit grace files
tmpfs 6274M 6274M 6274M 35929

Exactly at the limit. A single Claude Code scratchpad directory accounted for
almost all of it:

$ du -sh /tmp/claude-1000/* | sort -h | tail -3
87M /tmp/claude-1000/-home-tobias-work-keyb
88M /tmp/claude-1000/-home-tobias-work-setup
6.0G /tmp/claude-1000/-home-tobias-work-claude-coach

The Bash tool stages stdout capture under /tmp. With the quota exhausted the
capture file can be created but not written, which produces exactly the symptom
pattern described in this issue:

command that writes to stdout → empty capture → reported as a bare Exit code 1
command that writes nothing to stdout → nothing to capture → "succeeds"
shell redirections → target file is created but stays 0 bytes
Read / Write / WebFetch → unaffected

Worth noting for anyone else here: this needed no update and no reboot to
appear. tmpfs lives in RAM and is only cleared on reboot, so on a machine with
long uptime (mine: 18.8 days) it fills up gradually until it crosses the limit.
I had initially assumed a kernel or package update was responsible; /proc/uptime
and the dnf logs ruled both out.

### The part that is still a bug

The underlying error is EDQUOT, and Claude Code has it — the Write tool
surfaces it verbatim:

Error: EDQUOT: unknown error, write

The Bash tool swallows it and reports a bare Exit code 1 with no text. That
single missing error string is the whole reason this is so hard to diagnose: the
failure is indistinguishable from a harness regression, which is why I filed the
comment above in the first place. Surfacing the underlying errno on the Bash path
the way the Write path already does would turn this from an hours-long
investigation into a one-line answer.

### Suggested triage step for others in this thread

Before assuming a Claude Code regression, check whether the filesystem backing
your TMPDIR is out of space or over quota:

quota -s
df -h /tmp
du -sh /tmp/claude-1000/* 2>/dev/null | sort -h | tail

If that is the cause, removing old session scratchpads
(/tmp/claude-1000/<project>/<session-uuid>) restores the Bash tool immediately —
unlink does not need free space. Note the scratchpads are never cleaned up
automatically, which is arguably a second bug: one project of mine had
accumulated 6 GB.