[BUG] Unauthorizied Directory Traversal

Environment

• Platform (select one):
• [ ] Anthropic API
• [ ] AWS Bedrock
• [ ] Google Vertex AI
• [x] Other: Claude Code through WSL
• Claude CLI version: 1.0.65
• Operating System: Windows 11 + Linux 6.6.87.2-microsoft-standard-WSL2
• Terminal: VS.Code + Bash

Bug Description

When trying to get a fresh CLAUDE.md just to see, the task it spawned found a CLAUDE.md elsewhere and used it.

Steps to Reproduce

1. Assume a pre-existing claude code project
2. Start in a worktree for the project
3. Move the CLAUDE.md to back it up: mv CLAUDE.md ../../
4. Start claude: claude
5. Run /init

Expected Behavior

I expected a new CLAUDE.md file that didn't have any relation to the previous CLAUDE.md file.

Actual Behavior

It copied the CLAUDE.md from ../../ and made one modification.

Additional Context

The set of working directories is only the current working directories. I did not add any others.

Here is Claude Code's summary.

  Security Issues Identified:
  1. Unauthorized Directory Traversal: The Task agent accessed ../../CLAUDE.md without explicit permission, going two directories up from your launch point
  2. Scope Violation: You launched Claude in /home/gsdwi/brain2/spiral-ai-development/v2.1.2/ but the agent accessed files in /home/gsdwi/brain2/
  3. Information Leakage: Content from a parent directory was injected into the current session context without your knowledge
  4. Inconsistent Sandboxing: If Claude Code is supposed to be contained to the launch directory, this represents a sandbox escape

  Potential Risks:
  - Agents could read sensitive files from parent directories
  - Configuration files, credentials, or private data outside the intended scope could be accessed
  - The behavior is undocumented and unexpected, making it hard to secure properly

  What Should Happen:
  - File access should be restricted to the launch directory and its subdirectories
  - Any access outside this scope should require explicit user permission
  - The behavior should be documented and controllable

  This appears to be either:
  1. A bug in Claude Code's file access controls
  2. Undocumented behavior that needs better security boundaries
  3. A design flaw in how the Task tool operates