[BUG] Model repeats non-scoping grep after timeout; searches filesystem for a path already in context

Status Open
Reported on v2.1.233
Maintainer reply None cached
Activity 0 comments · opened Aug 17, 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?

Two related failures in one session, both costing multi-minute tool timeouts before any edit was made.

  1. A timed-out scan was retried without changing its scope.

The model issued grep -ril <pattern> . | grep -v node_modules from the repository root. The trailing grep -v filters the output after the scan completes — it does not stop
node_modules from being traversed. The command hit the 120s timeout and was backgrounded. On retry, the model issued the same shape of command against a subdirectory that also
contains node_modules. It timed out again. --exclude-dir=node_modules was never used, and the first timeout did not change the second command's structure.

  1. A filesystem walk for a location already read into context.

After reading two files that named the target source file in their own prose, the model ran a repo-root find . -name "<file>*" — another full-tree walk — instead of using the
filename it had just read. A single ls <dir> would have resolved it.

The user's first message named the directory to work in. The model's first tool call was a content search rooted at a different, higher directory.

What Should Happen?

  • When a scan times out, the retry should narrow the scan's input (--exclude-dir, --glob, a tighter path), not just its output filter. Repeating a filter-only change after a

timeout should not happen.

  • A directory supplied by the user should be listed and read before any content search is issued against a broader root.
  • A filename already present in context should not be re-derived with a filesystem walk.

Error Messages/Logs

Steps to Reproduce

  1. Open a repo containing node_modules at the root and inside at least one subdirectory.
  2. Ask the model to modify files in a named subdirectory, referring to them by a phrase that appears in their contents (e.g. "in <dir>, update the email templates so the button

says X").

  1. Observe the first tool call.

Observed: an unscoped grep -ril ... . | grep -v node_modules, rooted above the named directory, which times out; then a retry of the same shape.

Not guaranteed on every run — this is a behavioral tendency, not a deterministic fault.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.233

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Not a tooling defect — Bash and grep did exactly what was asked. This is model command-construction and search behavior.
Impact: User-visible latency and token spend. Several minutes and multiple timed-out calls before the first edit, on a project whose claude.md instructions explicitly prioritize minimal tool calls and short timeouts.

  • Platform: Windows 11 Home 10.0.26200
  • Shell: Git Bash (POSIX sh)
  • Model: Opus 5 (claude-opus-5)
  • Claude Code version: 2.1.233
  • Permission mode: bypass permissions

View original on GitHub ↗