Glob tool does not follow symbolic links

Status Open
Maintainer reply None cached
Activity 9 comments · opened Jan 6, 2026

Summary

The Glob tool does not traverse symbolic links to directories. When a symlink points to a directory containing files, patterns like symlink/* or symlink/**/* return "No files found".

Reproduction Steps

  1. Create a directory with files:

``bash
mkdir -p /tmp/test-dir
echo "test" > /tmp/test-dir/file.txt
``

  1. Create a symlink in your project:

``bash
ln -sf /tmp/test-dir symlink
``

  1. Try to glob through the symlink:
  • Glob pattern: symlink/*No files found
  • Glob pattern: symlink/*.txtNo files found
  • Glob pattern: symlink (the symlink itself) → No files found
  1. Compare with direct path:
  • Glob pattern: * in /tmp/test-dirFinds file.txt
  1. Compare with Read tool:
  • Read: <project>/symlink/file.txtWorks correctly

Expected Behavior

Glob should follow symlinks by default (similar to find -L, standard glob libraries, or ripgrep's default behavior), or provide an option to enable symlink following.

Actual Behavior

  • Glob ignores symlinked directories entirely
  • Cannot match files inside symlinked directories
  • Cannot even match the symlink name itself as a pattern

Use Case

In GitHub Actions workflows (e.g., claude-code-action), we create symlinks to temp directories containing contextual data (JIRA tickets, Confluence pages). The CLAUDE.md instructions reference these symlinked paths with glob patterns, which fail silently:

# In GitHub Actions workflow
- name: Create guideline symlinks
  run: |
    ln -sf "$RUNNER_TEMP/atlassian" 'atlassian'
<!-- In CLAUDE.md -->
Check if "atlassian" directory exists. If so, read atlassian/*.xml files...

This pattern works for the Read tool but fails for Glob, creating an inconsistency between tools.

Suggested Solution

Either:

  1. Follow symlinks by default (most intuitive, matches other tools)
  2. Add a followSymlinks: true parameter to the Glob tool
  3. Document the limitation clearly

Environment

  • Claude Code CLI (latest via npm)
  • Linux (Ubuntu)
  • Also likely affects macOS

View original on GitHub ↗

8 Comments

github-actions[bot] · 6 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

steveash · 6 months ago

Yes this still occurs, please fix it provide a way for us to (like allowing us to rewrite arguments and pass glob arg to follow symlinks)

AlexanderBartash · 6 months ago

This is still relevant.

fizzfaldt · 5 months ago

This is still relevant

sophia-ai-dev · 3 months ago

Still seeing this — and dropping the root cause for whoever picks it up. We hit it while building our own agent tooling on top of the SDK.

The Glob tool is implemented on top of ripgrep --files --glob <pattern> --no-ignore --hidden. By default ripgrep does not traverse symlinks; it would need the -L / --follow flag, which the CLI does not pass. Likely candidate to patch is the file that builds the rg argv for the Glob tool (something like src/utils/glob.ts in earlier layouts).

One-line repro (no Claude Code involved):

mkdir -p /tmp/real && echo hi > /tmp/real/file.txt
mkdir -p /tmp/proj && ln -sf /tmp/real /tmp/proj/sym
rg --files --glob 'sym/*' --no-ignore --hidden /tmp/proj      # 0 results
rg --files -L --glob 'sym/*' --no-ignore --hidden /tmp/proj   # finds sym/file.txt

Same delta as find vs find -L. The fix is either passing -L by default, or exposing it as an opt-in — consistent with Read, which already resolves through symlinks.

Workaround for wrappers around the CLI: replace symlinks with hard-links. Hard-links share the inode with the source, so ripgrep sees them as regular files — verified working. (Doesn't help the GitHub Actions / CLAUDE.md use case from the original report, since cross-filesystem hard-links fail with EXDEV.)

/cc @bcherny @ashwin-ant @claude — flagging in case useful. (Yes, tagging Claude too — felt fitting. 🙃)

tihspmet · 3 months ago

Another workaround is to install ripgrep on the system, set USE_BUILTIN_RIPGREP=0 and make RIPGREP_CONFIG_PATH point to a file with --follow as the content.

sakuramiko-35 · 2 months ago

Yes this still occurs, please fix it

timajwilliams · 2 months ago

hacky workaround I have, register a PostToolUse on Glob, if no files found, check if path is symlink, if it is, Glob the target and return contents using updatedToolOutput

Showing cached comments. Read the full discussion on GitHub ↗