[BUG][PRIVACY] Search tool scans personal cloud storage without user consent, causing hang

Resolved 💬 6 comments Opened Nov 19, 2025 by santoshmano Closed Jan 19, 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?

The Search tool hangs for 30+ minutes when it recursively scans the home directory
on systems with cloud storage mounted (Google Drive, Dropbox, OneDrive, etc.).

The process gets stuck in node::fs::AfterScanDir scanning thousands of synced files
in ~/Library/CloudStorage/, consuming 16% CPU continuously and 1.1GB+ RAM, making
the session completely unusable. User must manually kill the process.

directory_info.txt
stack_trace.txt
system_info.txt

What Should Happen?

The Search tool should either:

  1. Exclude common problematic paths by default (Library/, CloudStorage/, .Trash/,

node_modules/, .git/)

  1. Respect .claudeignore patterns globally
  2. Timeout after a reasonable period (e.g., 60 seconds)
  3. Warn the user before scanning directories with 10,000+ files
  4. Not default to home directory for recursive pattern searches

Error Messages/Logs

No error message displayed. UI shows:
"✳ Dilly-dallying… (esc to interrupt · 37m 41s · ↓ 971 tokens)"

Process analysis shows:
- Stuck in node::fs::AfterScanDir (from stack trace)
- Repeated V8 garbage collection cycles
- File handles open to Google Drive directories in lsof output

Steps to Reproduce

  1. Have cloud storage mounted (e.g., Google Drive at ~/Library/CloudStorage/)
  2. Ensure cloud storage has large synced directories (1000+ files, such as source

code repositories)

  1. Start Claude Code in any project directory
  2. Ask Claude to investigate a configuration issue (e.g., "check what's wrong with

the notification system")

  1. Claude autonomously decides to search for config files with:

Search(pattern: "/.claude/", path: "/Users/<username>")

  1. Observe process hanging with "Dilly-dallying" message for 30+ minutes
  2. Run ps aux | grep claude to confirm high CPU usage
  3. Run lsof -p <pid> to see Google Drive directories being scanned

Minimal reproduction:

  • Execute Search tool with path="/Users/<username>" and any pattern
  • Have cloud storage with large directory trees

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.46

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Context: User had Google Drive mounted with an old openmpi-1.8.4 source code
repository (~2MB directory metadata, 1000+ files) synced at
~/Library/CloudStorage/GoogleDrive-<email>/My Drive/work/software/openmpi-1.8.4/

Stack trace analysis showed:

  • Process spent most time in node::fs::AfterScanDir
  • Repeated V8 garbage collection cycles from creating file objects
  • Physical memory footprint: 1.1GB (peak: 1.2GB)

The issue is particularly problematic because:

  1. Cloud storage mounts are extremely common on developer machines
  2. Users don't realize Claude is scanning their entire drive
  3. No visual feedback about scan progress or what's being scanned
  4. The Search tool was invoked autonomously by Claude (not directly by user)
  5. Multiple concurrent Claude Code sessions compound the issue

System specs:

  • Node: v24.9.0
  • RAM: 48GB total
  • 8 concurrent Claude Code processes were running (4GB+ total RAM usage)

Suggested implementation for default exclusions:
/Library/
/CloudStorage/
/.Trash/
/node_modules/
/.git/
/Google Drive/
/Dropbox/
/OneDrive/

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗