Claude Code Security on Mac: What Developers Should Know

I use Claude Code every day. It is the tool I reach for first when building CoreLock — writing features, debugging issues, refactoring modules, running tests. I have written thousands of lines of production code with it. It has genuinely changed how I work.

But I also build Mac security software. And the more I use Claude Code, the more I think about what it actually has access to on my system. This is not a hit piece — I am writing this as someone who loves the tool and wants other developers to use it safely.

What Claude Code actually is

Claude Code is Anthropic's agentic coding tool. It runs directly in your Terminal (or VS Code, or JetBrains) and can read your files, write code, execute shell commands, make network requests, and integrate with external tools through the Model Context Protocol (MCP).

Unlike chat-based AI assistants where you copy and paste code back and forth, Claude Code operates inside your development environment. It can see your entire project structure, modify files across your codebase, run your test suite, commit to git, and interact with APIs — all from a single conversation.

That level of access is what makes it powerful. It is also what makes security worth thinking about.

The access model: your Terminal's permissions

Here is the thing most developers do not think carefully enough about: Claude Code runs with your Terminal's permissions. Whatever your user account can do, Claude Code can do.

That means it can:

• Read any file your user account has access to — source code, SSH keys, .env files, browser data
• Execute any shell command — rm, curl, git push, package installs, whatever
• Make network requests — to APIs, to external servers, to anywhere
• Modify your project — edit files, delete files, create new ones
• Use MCP tools — external integrations that extend its capabilities even further

On macOS, your user account typically has access to everything in your home directory, including credentials stored in config files, SSH keys, browser profiles, and application data. Claude Code inherits all of that.

How I actually use it

I want to be specific here because the risks depend heavily on how you use the tool.

When I am building CoreLock, I typically have Claude Code open in a project directory. I ask it to implement features, write tests, debug issues, and refactor code. It reads my source files, runs npm test, edits TypeScript modules, and commits changes.

For this kind of focused project work, the risk profile is manageable. Claude Code is operating on files I created, in a directory I control, running commands I understand. The permission prompts let me review what it wants to do before it does it.

But the risk changes dramatically if you use Claude Code to process untrusted content — cloning unknown repositories, reading files from external sources, or connecting MCP servers you have not audited. That is where things get dangerous.

Real vulnerabilities: CVE-2025-59536 and CVE-2026-21852

This is not theoretical. Check Point Research discovered critical vulnerabilities in Claude Code that were assigned real CVE numbers.

CVE-2025-59536 (CVSS 8.7) — This vulnerability exploited Claude Code's configuration mechanisms, including Hooks, MCP servers, and environment variables. An attacker could craft a malicious repository with configuration files that executed arbitrary shell commands and exfiltrated Anthropic API keys when a developer cloned and opened the repo. The fix was implemented on September 22, 2025.

CVE-2026-21852 (CVSS 5.3) — This one was broader. If you started Claude Code in an attacker-controlled repository that had a settings file pointing ANTHROPIC_BASE_URL to a malicious endpoint, Claude Code would issue API requests before showing the trust prompt. Your API key would be sent to the attacker's server before you even had a chance to reject the configuration. The fix was implemented on December 28, 2025.

Both of these are supply chain attacks. A single malicious commit in a repository could compromise any developer who cloned it and ran Claude Code. Anthropic patched both issues, but they illustrate a fundamental challenge: Claude Code processes configuration files that live in repositories, and repositories can come from anyone.

Security researchers at Lasso Security also demonstrated indirect prompt injection attacks where malicious instructions hidden in source code comments or README files could manipulate Claude Code into executing harmful actions. The agent reads the content, interprets the hidden instructions, and follows them — because LLMs process instructions and data through the same channel.

The permission system: your first line of defense

Claude Code does have a permission system, and it is actually decent. By default, it uses strict read-only permissions. When it wants to edit a file, run a command, or use an MCP tool, it asks you first.

The permission configuration lives in .claude/settings.json and supports several modes:

• Default — reads freely, asks before writes and commands
• Plan — analyze only, no modifications or command execution
• AcceptEdits — bypasses permission prompts for file edits (but still asks for commands)
• BypassPermissions — disables the entire safety stack

You can also configure allowlists for specific commands. If you always want Claude Code to run npm test without asking, you can add it to the allowed commands list.

The permission system also handles MCP server trust. When a project includes MCP server configurations, Claude Code asks you whether to enable them. This is important — MCP servers can execute code, make network requests, and access your filesystem.

What the permission system does not protect against

Permission fatigue. If you are deep in a coding session and Claude Code has asked you to approve 30 commands in a row, you stop reading them carefully. You start clicking "Allow" automatically. This is human nature, and attackers know it.

The --dangerously-skip-permissions flag exists and does exactly what the name implies — it bypasses the command blocklist, write access restrictions, the permission prompt system, and MCP server trust verification. Everything. There have been documented cases of developers using this flag and accidentally running destructive commands. Do not use it in any context where you are working with untrusted content.

MCP servers: the biggest expansion of the attack surface

MCP (Model Context Protocol) is what lets Claude Code connect to external tools — databases, APIs, file systems, browser automation, and more. It is incredibly useful. It is also the most significant security risk in the Claude Code ecosystem.

When you connect an MCP server, you are giving Claude Code access to whatever that server can do. A database MCP server can read and write to your database. A filesystem MCP server can access directories outside your project. A browser automation server can interact with web pages on your behalf.

The risks:

• No built-in authentication for many MCP server connections
• Secrets stored in plaintext in configuration files
• No audit trails for tool invocations by default
• Cross-tool data flow — data from a low-risk MCP server (like a calendar) can be forwarded to a high-risk one (like a code execution server)

Only enable MCP servers you have written yourself or that come from providers you trust. Review the source code of any MCP server before connecting it. And never commit MCP configurations with credentials to a public repository.

Security best practices for Claude Code on Mac

Here is what I actually do to stay safe while using Claude Code every day.

1. Do not auto-approve everything

Keep the default permission mode. Read the permission prompts, especially for shell commands. Only add commands to your allowlist if they are genuinely harmless — npm test, git status, tsc --noEmit. Do not add git push, docker run, curl, or anything that touches external services.

2. Audit your MCP servers

Before enabling any MCP server, understand what it does and what access it has. Read the source code. Check whether it stores credentials in plaintext. Verify that it comes from a trusted source. If a cloned repository includes MCP server configurations you did not expect, do not enable them.

3. Be careful with untrusted repositories

The CVEs I mentioned above both exploited malicious repository configurations. If you are cloning a repository from an unknown source, do not immediately run Claude Code in it. Review the .claude/ directory, any MCP configurations, and the project's hook scripts first. This is the same caution you should apply to npm install in an unknown project — but with higher stakes.

4. Never use --dangerously-skip-permissions with untrusted content

The name has "dangerously" in it for a reason. If you use this flag, you are removing every safety barrier between Claude Code and your system. In a controlled environment with your own code, the risk is manageable. With untrusted content, it is an open door.

5. Monitor your processes during coding sessions

This is where I am biased, but it is genuinely good advice. When Claude Code runs shell commands, it spawns child processes. Some of those spawn their own children. A single npm install can trigger dozens of processes — postinstall scripts, native module compilation, network requests to registries.

Without visibility into what those processes are doing, you are trusting that every package, every script, and every command is doing exactly what it claims. That trust is frequently misplaced.

6. Keep Claude Code updated

Anthropic has been responsive about patching security issues. Both CVEs I discussed were fixed before public disclosure. But the fixes only help if you are running the latest version. Run claude update regularly, or check your version with claude --version.

7. Use sandboxing when available

Anthropic has been building sandboxing features that isolate Claude Code's filesystem and network access. Filesystem isolation restricts which directories Claude Code can touch. Network isolation restricts which servers it can connect to. In internal testing, sandboxing reduced permission prompts by 84 percent while actually improving security. Enable these features when they are available for your setup.

How CoreLock complements Claude Code

I built CoreLock because I wanted visibility into what is happening on my Mac — and that includes what happens during development sessions with AI agents.

CoreLock monitors processes in real time, including child processes spawned by Terminal commands. When Claude Code runs npm install or executes a build script, CoreLock can show you every process that gets created, what it is doing, and what network connections it makes.

Specifically, CoreLock helps with:

• Process monitoring — see every process Claude Code spawns, including nested child processes from package installs and build tools
• Network visibility — track outgoing connections during development sessions to catch unexpected data exfiltration
• Anomaly detection — get alerted when a process behaves unusually, like a build script making network requests to unfamiliar servers
• Permission tracking — monitor which apps and processes have access to sensitive macOS permissions

This is not about distrusting Claude Code. It is about having visibility. The same way you would not run a production server without monitoring, you should not run an AI agent with system access without knowing what it is doing.

The bigger picture

Claude Code is part of a broader shift toward AI agents that operate inside our development environments. OpenClaw, Cursor, Windsurf, Copilot — they all have some level of system access, and the security considerations are similar.

The core challenge is that these tools process untrusted content with trusted privileges. An LLM cannot reliably distinguish between legitimate instructions from you and malicious instructions embedded in content it processes. The permission systems help, but they depend on users actually reading and understanding what they are approving.

I will keep using Claude Code every day. It makes me significantly more productive, and Anthropic has shown they take security seriously by patching reported issues quickly. But I use it with my eyes open — permission prompts enabled, MCP servers audited, process monitoring running, and a healthy awareness that the tool I am trusting with my codebase runs with the same permissions as everything else on my Mac.

If you are a developer who uses AI coding tools, take ten minutes to review your Claude Code configuration. Check your .claude/settings.json. Audit your MCP servers. Make sure you are running the latest version. And consider whether you have any visibility into what those tools are actually doing on your system.

Download CoreLock to get real-time process and network monitoring during your development sessions. It is built for exactly this kind of use case — knowing what is happening on your Mac when AI agents are running.