v2.1.158 (Opus 4.8): main session missing Grep/Glob, Bash storms, duplicate Bash commands, fabricated branches/commits/files, excessive shell text commands

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/63525
2. https://github.com/anthropics/claude-code/issues/52121
3. https://github.com/anthropics/claude-code/issues/62193

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

Quantified evidence from local session transcripts (full)

Measurement note: A single turn's parallel tool calls are split across multiple transcript JSONL lines sharing one requestId; the metrics below group by requestId (per-line counting would undercount parallelism to ~0). Sample = the 30 most-recent project sessions in config dir A, plus the last-hour project sessions in config dir B.

1 — Main session has no Grep / Glob

• Tool-call counts in the sample: Bash 2075, Read 699, Edit 614, Grep 34, Glob 5.
• Search is performed through Bash instead: grep 154 + find 28 + rg 94 = 276 shell search invocations. (The 39 native Grep/Glob calls originate from subagents; the main loop exposes neither tool.)

2 — Bash storms (parallel)

• Config dir A: 139 turns with ≥2 parallel Bash, 61 with ≥3; single turns observed with 12, 13, 16, 17, 18, 19, 21, 23, 26, 33, and 35 parallel Bash calls.
• Config dir B: 16 turns with ≥2, 15 with ≥3, max 20 in one turn.

3 — Duplicate Bash commands within one session

• Same command repeated: go vet ./... ×6, go run . ×5, go build ./... ×5, git status --short ×3, golangci-lint run ... ×3.

4 — Cascading No such file failures from working-directory drift, acting without verifying

• The Bash tool's working directory persists across calls. After a cd worktrees/<name> in one call, later calls using a relative path such as git -C worktrees/<name> … resolve against the drifted cwd and fail with cannot change to 'worktrees/<name>': No such file or directory — even though the directory exists (verified: worktrees/577-cellmodules-rename is a live worktree). The agent then issued several more such commands (some in parallel) before ever checking pwd.
• Example sequence (single session): 4 consecutive git -C worktrees/577-cellmodules-rename … calls all failed with cannot change to … No such file or directory; a 5th was issued in parallel and interrupted; only then did pwd reveal the cwd had already moved into that worktree.
• 46 tool results in the sample returned does-not-exist errors. They are a mix of (a) the cwd-drift/relative-path failures above, (b) deliberate existence probes (e.g. ls /nonexistent-xyz-probe-12345), and (c) git revision args reported as unknown revision or path. Genuine fabricated references cannot be cleanly separated from cwd-drift errors and removed-since ephemeral worktrees, so no fabrication count is claimed.

5 — Frequent echo

• Config dir A: 873 of 1934 Bash calls (45%) contain echo. Config dir B: 8 of 139 (6%).

---

Cancelled: parallel tool call Bash in the UI corresponds to these large parallel Bash batches being issued and then interrupted.

This is likely a duplicate of one or more of these:
anthropics/claude-code#22264 covering the cascading cancelation
anthropics/claude-code#64047 where batch tool cancellations get picked up by the model as user denials or interrupts, so model blames user or the environment

Related, but not likely encountered during your session:anthropics/claude-code#63147 (thinking blocks corrupted by the cancelation issue)

I have been experiencing similar issues since the Opus 4.8 release. Claude keeps making duplicate bash commands, or variations of that same command in a very short time period. One clue I have noticed is that new commands continue to queue in the background while Claude Code is displaying a prompt for the user to approve the previous command. My best guess is that the model is not getting feedback that it needs to stop and wait for approval, either from the user or the auto classifier, before attempting the same tool call again.

I have submitted a bug report inside Claude Code Feedback ID: bd6577f8-12a0-472d-8300-46f441cfa456
I am running Claude Code 2.1.158 inside PowerShell on Windows 11

Additional reproductions — same env (v2.1.158, Opus 4.8 1M, macOS)

Two more real-session repros that strengthen the original report's item 2 (Bash storms) and item 4 (Fabricated facts). The fabrication case is materially worse than "invents branches/files": the agent overrode a correct, explicit tool result and hallucinated the entire task, then carried that hallucination through plan → implement → merge.

A. Fabricated task definition — agent ignored a clean tool result

An issue-driven workflow was invoked with an issue number. Per its instructions it ran gh issue view <N> --json title,body,labels,state as the first step.

• The tool returned cleanly and correctly — full, accurate title/body/labels for the real issue (call it topic A).
• The agent's own narration right before the call: "I'll start by fetching issue #N to understand the task."
• The very next assistant turn — with zero intervening reasoning text — spawned three explore subagents for a completely unrelated task (topic B). Nothing about topic B appears anywhere in the issue.

The agent then planned, wrote tests, implemented, reviewed, and merged a full PR for the hallucinated topic-B task. Every commit, the branch name, the plan file, and the PR body carried Closes #N pointing at the unrelated topic-A issue. The auto-generated plan even rationalized the contradiction as "correcting a first-round tool-glitch misread" — but there was no glitch; the tool output was correct and complete. The agent simply substituted a task that was never in the issue.

Failure-containment notes:

• The only reason it did not auto-close an unrelated, still-open issue on merge was an unrelated accident: the Closes #N keyword happened to sit inside backticks, which GitHub does not parse. A formatting fluke was the sole thing preventing a wrong-issue closure.
• No workflow step ever echoed the issue's real title/body back to the human for confirmation, so the topic-A-vs-topic-B mismatch was never surfaced. The confirmation prompt only asked about "solution direction," not "does this match the issue."

Takeaway: the model can latch onto (or hallucinate) a task prior and then treat a correct, contradicting tool result as background noise instead of ground truth.

B. Bash storms → cascade cancellation + repeated hook trips (items 2, 5)

A separate session:

• The agent emitted 16 parallel Bash calls in a single turn. The environment guards/serializes Bash, so one failure cancels the whole batch — every call returns Cancelled: parallel tool call … errored. All 16 wasted.
• It acknowledged this twice in-session ("I sent 16 at once and they got collectively cancelled; I must wait for each result before sending the next") — then did it again the next turn.
• A repo hook rejects any Bash command containing echo/awk/sed/cat (or in-shell file mutation). The agent kept hitting it (… 2>&1 | head, in-shell formatters, echo "EXIT=$?"), re-tripping the same guard repeatedly instead of switching to Read/Edit.
• The same session also pursued a fix target (a symbol) that did not exist in the target file; an "Error editing file" was the only thing that halted the dead-end — another case of acting before verifying (item 4).

Cross-referencing #64881, which I've just closed as a duplicate of this issue's item 4 ("Fabricated facts — references non-existent files without verifying first").

#64881 is a single-bug write-up of that specific failure, with some additional detail that may help whoever works it:

• it occurs in a Plan subagent, not only the main loop;
• the agent re-queried a path after the correct path had already appeared in its own tool results;
• the fabrication propagated into a delivered plan as a wrong mechanism claim ("no PYTHONPATH injection in run_pcbnew_script" — the real file does set env["PYTHONPATH"]);
• observed on v2.1.156, so this behavior predates the v2.1.158 regression framed here.

Closing #64881 in favor of this issue to keep the signal in one place; the detailed evidence remains there for reference.

confirmed bug still present on 2.1.168