glob tool returns false negatives — misses files that exist on disk

Description

Summary

The glob tool silently returns "No files found" for files that provably exist on the filesystem, as confirmed by ls -la. This causes the agent to draw incorrect conclusions (e.g., "a file is missing") that can trigger hard-stop workflows or wrong diagnoses, with no indication that the tool result is unreliable.

Reproduction

Workspace root: /workspace. File in question: /workspace/src/main/java/ARCHITECTURE.md. Calling glob with these patterns returned "No files found" for both: - pattern: /workspace/src/main/java/**/ARCHITECTURE.md - pattern: /workspace/src/main/java/ARCHITECTURE.md (exact absolute path) Independently, ls -la /workspace/src/main/java/ARCHITECTURE.md confirms the file exists and is readable: -rw-r--r-- 1 node node 11839 Aug 29 01:40 /workspace/src/main/java/ARCHITECTURE.md

Expected behavior

glob should return the matching path when the file exists on disk.

Actual behavior

glob returns "No files found" for both patterns, despite the file existing.

Additional context

• The failure appears pattern-specific rather than total: a glob call for **/PACKAGE.md in the same tree succeeded and returned 14 results earlier in the same session. So the tool is not entirely broken; this looks like an intermittent or path-specific false negative. - Environment: linux, working directory /workspace. - Observed twice in one session, against the same file, with two different patterns (one **-wildcard, one exact path).

Impact

An agent relying on glob to determine whether a file exists can be misled into reporting a file as missing — which in agent workflows built around "missing file ⇒ hard stop" can cause the agent to halt unnecessarily or, worse, proceed past a real condition after rationalizing the false negative. There is no signal attached to the result that distinguishes "no match" from "search failed."

Suggested investigation

• Confirm whether glob is backed by an index/cache that may be stale relative to the filesystem. - Consider returning a distinguishable result (or an error) when the tool cannot reliably complete a search, rather than an empty result indistinguishable from a genuine "no match."

Plugins

no plugins

OpenCode version

1.18.25

Steps to reproduce

Here is what the agent said:

I see an ARCHITECTURE.md file at src/main/java, why don't you see it there?
  ls src/main/java/
  ARCHITECTURE.md  Makefile  overview.html

+ Thought: 534ms
Good catch — let me verify what's actually there.
✱ Glob "/workspace/src/main/java/ARCHITECTURE.md"

  $ ls -la /workspace/src/main/java/ARCHITECTURE.md 2>&1; echo "---"; ls /workspace/src/main/java/ | head -20

  -rw-r--r-- 1 node node 11839 Aug 29 01:40 /workspace/src/main/java/ARCHITECTURE.md
  ---
  ARCHITECTURE.md
  Makefile
  overview.html

+ Thought: 6.1s
You're right, it's there. The fault was mine, not the filesystem: the glob tool returned a false negative. I ran two searches that both came back "No files found":
- glob for /workspace/src/main/java/**/ARCHITECTURE.md — no results
- glob for /workspace/src/main/java/ARCHITECTURE.md (the exact path) — no result
s
Yet ls -la shows it at 11839 bytes, dated Aug 29. So the file exists and is readable; the glob tool failed to find it both times, and I trusted that result without cross-checking against ls or the read tool. A single verification would have caught it.                                                                                                                                         

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response