Claude Code has undisclosed access to the entire filesystem, shell history, credentials, and network — with no informed consent

Resolved 💬 4 comments Opened Mar 27, 2026 by ypsOmaniac Closed May 1, 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?

Summary

Claude Code is offered as a desktop app for macOS. The user installs it like any other app — via the App Store or a DMG — and reasonably assumes that the standard macOS security mechanisms apply: app sandbox, permission prompts for microphone, camera, contacts, and so on.

What the user is not told: The installation also deploys a CLI tool that runs outside the macOS sandbox. When launched in the terminal, this CLI automatically inherits the full permissions of the shell session — i.e., those of the logged-in user. This is disclosed neither during installation nor at first launch.

In practice, this means: while the user believes they are running a normal app subject to the usual macOS security layers, an autonomous agent is operating with silent read access to the entire filesystem, all environment variables, and the ability to make outbound network requests — without a single permission prompt.

The gap between what the user expects (an app like any other) and what actually happens (a CLI agent with overpowered shell-level access) is never communicated. There is no opt-in, no consent dialog, no subsequent explanation.

---

What Claude Code can access without disclosure

Filesystem — full read access, no permission prompt

  • All files in the user's home directory: Documents, Downloads, Desktop
  • All project directories — not just the one Claude Code was started in
  • Network-mounted filesystems (SMB, NFS, Seafile, Dropbox, OneDrive sync folders)
  • ~/.ssh/ — private keys and SSH configuration
  • ~/.aws/credentials, ~/.gcp/ — cloud provider credentials
  • ~/.gitconfig and stored Git tokens
  • .env files in any project — API keys, database passwords, secrets
  • ~/.zsh_history / ~/.bash_history — the complete record of every command the user has ever typed
  • Browser profile data (if file-based and accessible from the terminal)
  • Password manager vaults (if file-based)

Read access requires no user confirmation. It is silently granted by default.

Environment variables

Claude Code has access to all environment variables in the shell session. These routinely contain API keys, authentication tokens, database connection strings, and other secrets.

Network — outbound data transmission

Via the Bash tool, Claude Code can execute curl, wget, or any network command. This means it can transmit file contents to arbitrary external servers. Via WebFetch, it can make HTTP requests to arbitrary URLs.

Combined with silent read access, the technical capability exists to: read a file (no prompt) → transmit its contents via network request (one prompt that many users confirm reflexively).

Process execution

Claude Code can start background processes via Bash that continue running after the chat session ends.

---

The core question: Why not directory-scoped access by default?

The minimal viable approach is obvious and technically trivial:

  1. At first launch, Claude Code starts with access only to the working directory
  2. The user is told: "Claude Code can read and write files in /path/to/project. Do you want to grant access to additional directories?"
  3. Additional directories are added explicitly by the user
  4. Access to ~/.ssh, ~/.aws, shell history, and other sensitive locations is never granted by default

This is how every modern application works — mobile apps, browser extensions, desktop apps on macOS/Windows. The user grants scoped permissions. The application explains what it needs and why.

Why does Claude Code not do this?

A disclosure dialog ("we can access everything") is insufficient. The question is not whether the user is informed — the question is why full filesystem access is necessary at all. For a coding assistant working on a project, read access to the project directory and explicitly configured additional directories is sufficient. There is no technical reason to default to full filesystem access.

---

The structural pattern

Consider what Claude Code does, described neutrally:

  1. It presents itself as a project-scoped coding assistant
  2. It silently has read access to the entire filesystem
  3. It autonomously decides what to read — the user does not control or approve read operations
  4. Everything it reads is transmitted to Anthropic's servers for processing
  5. It can execute network requests to arbitrary external endpoints
  6. None of this is disclosed at any point

This is the structural pattern of a trojan: software that presents itself as one thing while silently operating with undisclosed capabilities that exceed the user's reasonable expectations.

The question is not whether Anthropic has malicious intent. The question is: what intent could a reasonable observer infer from the deliberate choice to not disclose these capabilities? And: would this design survive regulatory scrutiny under GDPR, the EU AI Act, or the Swiss Data Protection Act (nDSG)?

---

"Every CLI tool has the same access" is not a defense

The standard response is that any CLI tool (grep, git, node) has the same terminal permissions. This is technically true and fundamentally misleading:

  • grep reads exactly what the user explicitly tells it to read
  • Claude Code autonomously decides what to read based on AI inference
  • grep does not transmit file contents to external servers
  • Claude Code transmits everything it reads to Anthropic's cloud infrastructure
  • grep does not make network requests to arbitrary endpoints
  • Claude Code can, via Bash

The comparison to passive CLI tools obscures the fact that Claude Code is an autonomous agent with cloud-based processing and network access. It operates in a fundamentally different trust category.

---

The user base is expanding beyond developers

Claude Code is increasingly used by non-developers: executives, consultants, product managers, strategists. These users:

  • Work on machines containing client data, contracts, financial information, strategic documents
  • Have no reason to assume a "coding assistant" can read their entire filesystem
  • Are accustomed to applications that request scoped permissions
  • Would never knowingly grant an AI tool access to their SSH keys, shell history, or network drives

The absence of informed consent is not a minor UX oversight for this growing user segment. It is a fundamental trust violation.

---
Filed by a non-developer user who discovered the full scope of access only by explicitly asking Claude Code what it can read. Also this issue is written by Claude...

What Should Happen?

Recommendations

Minimum (immediate)

  1. First-launch disclosure: Clearly inform the user about the full scope of access, including filesystem, environment variables, network capabilities, and cloud transmission of data
  2. Audit visibility: Show which files were read and which data was transmitted in each session — prominently, not buried in a transcript

Proper solution (required)

  1. Directory-scoped read access by default: Limit to working directory + explicitly configured additional directories. No silent access to ~/.ssh, ~/.aws, shell history, .env files outside the project, or network drives
  2. Opt-in for sensitive locations: Require explicit user consent before reading outside the project scope, with clear explanation of why
  3. Network sandboxing by default: Outbound network requests beyond Anthropic's API should require explicit approval
  4. No reflexive permission patterns: If a capability can exfiltrate data, the permission prompt must make this consequence visible — not just show the command

Transparency

  1. Publish a clear security model: What does Claude Code access, when, and why? What is transmitted to Anthropic's servers? What is retained?
  2. Explain the design choice: Why was full filesystem access chosen as the default? What is the justification for not implementing scoped permissions from day one?

---

Error Messages/Logs

Steps to Reproduce

  1. install Claude app
  2. use Claude Code

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

all

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

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