[BUG] Bash Tool Silently Empties Environment Variables in Pipelines

[mhelvens]

Preflight Checklist

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

What's Wrong?

Bug report and tests written by Claude Code, but double-checked by me.

Summary

The Claude Code Bash tool silently expands all environment variables to empty strings when the command is a simple pipeline and does not have a # comment on a preceding line. This produces incorrect results with no warning, and the workaround (adding a comment) is non-obvious.

Impact

This is a silent correctness bug — commands produce wrong results with no error or warning. It is particularly insidious because:

• It's intermittent in practice. Developers (and AI agents) habitually add # descriptive comment lines before commands. When they do, the bug doesn't trigger. When they don't, it does. This makes it hard to diagnose.
• The failure mode is misleading. When a variable is used in a file path, the error looks like a path problem (bash: /scripts/setup.sh: No such file or directory), not an env var expansion issue. Agents waste time investigating the wrong cause.
• It was discovered by accident. A Claude Code subagent failed to run a script, retried 3 times, then worked around it by hardcoding the path — all because it happened not to include a # comment in its first few attempts.

Analysis

1. The variables exist in the process environment. env | grep VAR always shows the correct value. printenv VAR | cat also works. The variables are exported and present.

2. Shell $-expansion is broken, not the environment. The issue is specifically that $VAR syntax expands to an empty string. Commands that read from the environment directly (env, printenv) are unaffected.

3. The issue only manifests in pipelines. The same $VAR expansion works correctly when there is no | in the command.

4. A # comment on a preceding line is a reliable workaround. This suggests the Bash tool has two code paths for executing commands, selected based on whether a # character appears in the input. The non-# path has a bug where environment variables are not available during shell expansion of pipelines.

5. Compound commands (for, if/then) also work. These change how the shell parses the command, which may route through a different execution path.

6. The set -x trace confirms eval is used. Trace output shows (eval):1> prefixes. The bug likely lies in how the command string is passed to eval or in environment setup before eval runs, conditional on the presence of #.

What Should Happen?

Environment variables should expand identically regardless of whether the command contains a pipe, and regardless of whether a # comment precedes the command.

Error Messages/Logs

Steps to Reproduce

Just ask Claude Code to run the following bash commands.

Failing cases — env vars silently expand to empty

Test 1: Simple pipe — $HOME expands to empty, so echo prints a blank line, and cat outputs nothing.

echo $HOME | cat

Output: (empty)

---

Test 2: Quoting doesn't help.

echo "$HOME" | cat

Output: (empty)

---

Test 3: Brace syntax doesn't help.

echo ${HOME} | cat

Output: (empty)

---

Test 4: It's not just echo and cat. When the variable is in a path argument, the empty expansion produces a bogus path.

bash "$HOME/some/script.sh" | head -1

Output (stderr): bash: /some/script.sh: No such file or directory

---

Test 5: All variables are affected, not just $HOME.

echo "HOME=$HOME USER=$USER" | cat

Output: HOME= USER=

---

Test 6: Locally assigned variables are also affected.

X=hello; echo $X | cat

Output: (empty)

---

Test 7: Same with && instead of ;.

X=hello && echo $X | cat

Output: (empty)

---

Test 8: Same with a newline separator.

X=hello
echo $X | cat

Output: (empty)

---

Test 9: A preceding no-op command doesn't help.

: && echo $HOME | cat

Output: (empty)

---

Test 10: A preceding true doesn't help.

true && echo $HOME | cat

Output: (empty)

---

Test 11: A preceding echo doesn't help.

echo hi && echo $HOME | cat

Output: hi

---

Test 12: A blank preceding line doesn't help.

 
echo $HOME | cat

Output: (empty)

---

Test 13: A trailing comment on the same line doesn't help.

echo $HOME | cat # this is a comment

Output: (empty)

---

Passing cases

Test 14: Adding a comment line before the pipeline makes it work.

# comment
echo $HOME | cat

Output: /home/user

---

Test 15: Even an empty comment works.

#
echo $HOME | cat

Output: /home/user

---

Test 16: Wrapping in a for loop works too.

for i in 1; do echo $HOME | cat; done

Output: /home/user

---

Test 17: Wrapping in if/then.

if true; then echo $HOME | cat; fi

Output: /home/user

---

Test 18: Using command substitution with printenv (bypasses shell $-expansion entirely).

echo $(printenv HOME) | cat

Output: /home/user

---

Test 19: Without a pipe, variable expansion works fine.

echo $HOME

Output: /home/user

---

Test 20: Redirects work fine too.

echo $HOME 2>&1

Output: /home/user

---

Test 21: env and printenv in a pipe work because they read from the process environment directly, without shell $-expansion.

env | grep HOME

Output: HOME=/home/user

printenv HOME | cat

Output: /home/user

---

Diagnostic — set -x trace

Test 22: With set -x enabled, the shell prints each command after expansion. The trace reveals that the Bash tool executes commands via eval, and that $HOME has expanded to an empty string before execution.

set -x; echo "$HOME" | cat; set +x

Output:

+(eval):1> echo ''
+(eval):1> cat

+(eval):1> set +x

The (eval):1> prefix confirms the command runs inside eval. The trace shows echo '' — the variable expanded to an empty string.

---

Test 23: For comparison, the same command with a # comment prefix shows correct expansion.

# comment
set -x; echo "$HOME" | cat; set +x

Output:

+(eval):2> echo /home/user
+(eval):2> cat
/home/user
+(eval):2> set +x

Note (eval):2> instead of (eval):1> — the comment occupies line 1, pushing the command to line 2. The trace shows echo /home/user — the variable expanded correctly.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Best guess: 2.1.50 (but probably later versions still worked too)

Claude Code Version

2.1.62

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

iTerm2

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Environment variables expand to empty string when command contains pipe #18979
2. [BUG] Environment variables expand to empty strings when used in piped commands #17182
3. Bash tool: environment variables and command substitution break when piping #22419

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ticpu]

Additional test cases (tested on Linux, Claude Code 2.1.63 with Sonnet 4.6, 2026-03-01)

Building on the systematic work in this report, a few more affected cases worth documenting:

Also broken with | present

Expression	Without pipe	With pipe
$$ (PID special var)	works	empty
awk -v x=$VAR '...'	works	empty (x gets empty string)
{ echo $HOME; } | cat	works	brace group broken entirely ({: command not found)
echo $HOME; echo hi | cat	both work	$HOME empty (; doesn't protect it)

Key clarification on ; boundary

The | anywhere in the command string contaminates all $VAR expansions on the entire line, even those separated by ;:

# Both $HOME expansions are empty, even though one is before the pipe:
echo $HOME; echo hello | cat; echo $HOME
# output: (empty line) / hello / (empty line)

Safe exceptions (confirmed working with pipes)

• $(cmd) — command substitution works fine
• $((...)) — arithmetic expansion works fine
• Literal values (no $) — work fine

Workaround used in production (from our Claude Code system prompt / CLAUDE.md)

- **Any `|` in the command string strips all `$VAR` expansions** — affects `$VAR`, `"$VAR"`, `${VAR}`, `${VAR:-default}`, `$$`, and `awk -v x=$VAR`; also breaks `{ ... }` brace groups entirely
- `$(cmd)` and `$((...))` are NOT affected — they survive pipes fine
- The `|` anywhere on the line contaminates everything, even across `;`
- **`<<<` (herestring) is even worse** — strips both `$VAR` AND `$(cmd)` from its operand; only `bash -c` works
- **Preferred workaround for `|`**: use `$(printenv VAR)` instead of `$VAR` — simpler than `bash -c`, no quoting issues. Only works for exported/environment variables, not local shell variables
- **Workaround for `<<<` or local vars with `|`**: wrap in `bash -c '...'` with single quotes
- Do NOT use `bash -c` unnecessarily for commands with no pipes

We've been documenting this in our CLAUDE.md system prompt so the model knows to avoid the pattern.

[mhelvens]

@ticpu My own workaround has been to replace every occurrence of $FOO with $(printenv FOO), uniformly. And to instruct Claude Code to do the same. That seemed simpler to me, and it doesn't run into complications with nested '' pairs.

Do you see any drawback to this approach, or any reason you prefer bash -c?

[ticpu]

Do you see any drawback to this approach, or any reason you prefer bash -c?

In fact, it works much better in regards to preventing permission issues. I'll give it a try and edit my comment accordingly.

Edit: after letting Claude test it out, it is quite a better remedy for |, still needed for <<<

[wehriam]

@ashwin-ant would you mind taking a look at this one when you have a moment? It's very disruptive for common workflows.

[getaaron]

Root Cause Analysis

The bug is in the function DsD (minified name) which preprocesses Bash commands before execution. It's trying to insert < /dev/null, i think to prevent stdin blocking. The function has two code paths:

Safe path (lgH): Quotes the entire command as a single string

  // lgH(H) = quote([H]) + " < /dev/null"
  // e.g. 'echo $HOME' < /dev/null
  // $HOME is preserved as a literal in the quoted string, shell expands it at runtime

Broken path: Parses command into tokens, then re-quotes individually

For "simple pipelines" (no backticks, no $(...), no compound keywords like for/if/while), the function:

1. Calls shell-quote's parse() to tokenize the command
2. Finds the | pipe operator token
3. Inserts < /dev/null before the pipe
4. Re-quotes each token with shell-quote's quote()

The bug: shell-quote.parse() expands $VAR references to empty strings when no environment map is provided. This is by design in the shell-quote npm package, it treats unresolved variables as empty:

  const sq = require('shell-quote');
  sq.parse('echo $HOME | cat')
  // => ["echo", "", {op: "|"}, "cat"]
  //                ^^ $HOME expanded to ""

The re-quoted command becomes echo '' < /dev/null | cat

Decompiled DsD function (beautified w/ Claude)

  function DsD(command) {
    // Safe path: compound/complex commands get quoted as-is
    if (command.includes("`")) return lgH(command);    // backticks
    if (command.includes("$(")) return lgH(command);   // command substitution
    if (z$1(command)) return lgH(command);             // for/while/if/case/select

    let cleaned = Y$1(command);  // normalize backslash-newlines
    let parsed = Mq(cleaned);    // shell-quote.parse() -- THIS DESTROYS $VAR
    if (!parsed.success) return lgH(command);

    let pipeIdx = P$1(parsed.tokens);  // find first | operator
    if (pipeIdx <= 0) return lgH(command);  // no pipe → safe path

    // BROKEN: reconstruct from parsed tokens (variables already expanded to "")
    let parts = [
      ...LsD(parsed.tokens, 0, pipeIdx),
      "< /dev/null",
      ...LsD(parsed.tokens, pipeIdx, parsed.tokens.length)
    ];
    return W8([parts.join(" ")]);  // quote the reconstructed (broken) command
  }

Proposed fix

The fix should avoid round-tripping through shell-quote.parse() for the purpose of inserting < /dev/null. Instead, it should always use the safe lgH path quote([command]) + " < /dev/null"

Reproduction

  npm install shell-quote
  node -e "
  const sq = require('shell-quote');
  // This is what Claude Code's DsD function does internally:
  console.log(sq.parse('echo \$HOME | cat'));
  // Output: ['echo', '', {op: '|'}, 'cat']
  // $HOME is silently expanded to empty string
  "

Likely introducing change

v2.1.51 changelog entry: "BashTool now skips login shell (-l flag) by default when a shell snapshot is available" just guessing from the changelong entry but it might be where it was introduced or changed the DsD stdin-blocking prevention code path.