[Bug] Glob Pattern Processing Fails with Pipes, Replaces Pattern with "glob"

Bug Summary

Claude Code incorrectly processes shell glob patterns when used with pipes, replacing the glob pattern with the literal string glob, causing commands to fail with cannot access 'glob': No such file or directory errors.

---

Environment

• Claude Code Version: Current (as of 2025-09-12)
• Operating System: macOS Darwin 23.3.0 (arm64)
• Shell: zsh (default), with bash 3.2.57 (system) and bash 5.3.3 (Homebrew)
• Working Directory: path with spaces, e.g. /Users/[user]/Path With Spaces/project-directory

---

Reproduction Steps

Test 1: Basic glob with pipe

Command:

ls *.md | head -3

Result:

ls: cannot access 'glob': No such file or directory

Test 2: Cat with glob and pipe

Command:

cat *.txt | head -3

Result:

cat: glob: No such file or directory

Test 3: Glob with wc

Command:

ls *.json | wc -l

Result:

ls: cannot access 'glob': No such file or directory

---

Expected Behavior

Glob patterns such as *.md, *.txt, *.json should expand correctly, and the piped command chain should execute with the expanded filenames.

Actual Behavior

Claude Code replaces the glob pattern (for example, *.md) with the literal string glob, causing the shell to look for a file named glob.

---

Working Cases (No Bug)

1. Without pipes:

``bash
ls *.md
``

Works correctly.

1. Using bash -c wrapper:

``bash
bash -c 'ls *.md | head -3'
``

Works correctly.

1. Using Glob tool directly: Works correctly.

---

Root Cause Analysis

Based on testing and related GitHub issues (#5811, #5664), the bug appears to be in Claude Code's command parsing and reconstruction logic. When processing commands that include both glob patterns and pipes, the parser incorrectly uses the operation type ("glob") instead of the actual pattern value; the parser substitutes G.op where it should prefer G.pattern.

Suggested minimal change:

// use actual pattern if available, otherwise fall back to op
const patternOrOp = G.pattern || G.op;

---

Impact

• Breaks common shell workflows involving globs and pipes, reduces productivity
• Forces users to use workarounds for basic file operations
• Produces confusing error messages that obscure the real cause

---

Workarounds

1. Wrap commands in bash -c, e.g.

``bash
bash -c 'ls *.md | wc -l'
``

1. Avoid pipes, use intermediate files or variables
2. Use find, e.g.

``bash
find . -name "*.md" | wc -l
``

1. Use Claude Code's Glob tool directly

---

Suggested Fix

Update the command reconstruction function to prioritize the actual glob pattern over the operation type; for example, replace usages of G.op with G.pattern || G.op in the reconstruction code path that handles globs and pipes.

Example patch concept:

// before
reconstructed = G.op;

// after
reconstructed = G.pattern || G.op;

---

Additional Notes

• Bug is consistent across shells (bash 3.2, bash 5.3, zsh), therefore not shell-version specific
• Bug appears to be in Claude Code's internal processing, not in the shell itself
• The literal glob string in error messages is the smoking gun implicating the parser

---

Test Battery Results

• ✅ Confirmed: bug occurs with all glob patterns when pipes are present
• ✅ Confirmed: bug does not occur without pipes
• ✅ Confirmed: bash -c workaround is effective
• ✅ Confirmed: issue is reproducible consistently

---

Environment Info

• Platform: darwin
• Terminal: tmux
• Version: 1.0.112
• Feedback ID: d4637fd9-c249-4169-b18c-19e2b498e41d

---

Errors

[{
  "error": "Error: Request was aborted.\n    at new Q5 (unknown:1:28)\n    at new vY (/$bunfs/root/claude:842:1962)\n    at new aQ (/$bunfs/root/claude:842:2750)\n    at _createMessage (/$bunfs/root/claude:850:7955)\n    at processTicksAndRejections (native:7:39)",
  "timestamp": "2025-09-12T16:55:41.854Z"
}]