[BUG][PRIVACY] Search tool scans personal cloud storage without user consent, causing hang
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:
- Exclude common problematic paths by default (Library/, CloudStorage/, .Trash/,
node_modules/, .git/)
- Respect .claudeignore patterns globally
- Timeout after a reasonable period (e.g., 60 seconds)
- Warn the user before scanning directories with 10,000+ files
- 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
- Have cloud storage mounted (e.g., Google Drive at ~/Library/CloudStorage/)
- Ensure cloud storage has large synced directories (1000+ files, such as source
code repositories)
- Start Claude Code in any project directory
- Ask Claude to investigate a configuration issue (e.g., "check what's wrong with
the notification system")
- Claude autonomously decides to search for config files with:
Search(pattern: "/.claude/", path: "/Users/<username>")
- Observe process hanging with "Dilly-dallying" message for 30+ minutes
- Run
ps aux | grep claudeto confirm high CPU usage - 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:
- Cloud storage mounts are extremely common on developer machines
- Users don't realize Claude is scanning their entire drive
- No visual feedback about scan progress or what's being scanned
- The Search tool was invoked autonomously by Claude (not directly by user)
- 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/
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗