Glob with broad wildcard pattern silently truncates results, leading to wrong conclusions about file existence

Summary

When a user provides a file path or filename directly in their message, Claude Code uses Glob with a broad pattern (e.g. folder/**) instead of reading the file directly. When the folder contains many files, Glob silently truncates results. Claude then incorrectly concludes the file doesn't exist — even when the user explicitly stated it does.

Steps to Reproduce

1. Tell Claude: "in docs/plans/phase1/ we have readme files, explain X"
2. Claude runs Glob("docs/plans/phase1/**") — folder has 100+ files, results truncate
3. README.md is not in the truncated output
4. Claude says "I don't see README files" and pivots elsewhere, ignoring what the user stated

Expected Behaviour

When a filename or path is provided by the user, Claude should use Read directly — no Glob needed. If Glob is used, truncation should be treated as incomplete results, not as evidence the file doesn't exist.

Root Cause

Two compounding issues:

1. Broad Glob pattern (folder/**) chosen when the specific filename was already known from the user's message
2. Truncated Glob output treated as definitive rather than incomplete — overriding the user's explicit statement that the file exists

Suggested Fix

• When the user explicitly names a file or provides a path, use Read directly without a preceding Glob
• If Glob results are truncated, Claude should retry with a more specific pattern rather than concluding the file doesn't exist
• Truncation warnings in Glob output should trigger a fallback to a narrower search, not a false-negative conclusion