Alright, let's get this straight before someone gets hurt. Everyone's buzzing about the new Claude Code agent, and I keep seeing folks treat it like a friendly neighborhood GitHub Copilot. It's not. The permission model is fundamentally different, and if you're just clicking 'accept' on everything, you're asking for trouble.
Copilot's local model, for all its flaws, is basically a fancy autocomplete. It reads your open file and maybe the project structure, but it's not an agent. It doesn't *do* things. Claude Code, when you give it permission, is an agent with a shell. It can read, write, and execute. That's a whole other level of trust.
I've been poking at the Claude Code beta, and the key is the `claude_desktop_config.json`. You have to explicitly whitelist paths. The default is nothing. Copilot doesn't have this concept; it inherits your editor's access.
```json
{
"shell": {
"allow": [
"/home/jake/dev/safe_project/*",
"/tmp/build_scratch/*"
]
},
"files": {
"allow": [
"/home/jake/dev/safe_project/*"
],
"block": [
"**/.env",
"**/id_rsa"
]
}
}
```
If you just run it straight, it's neutered. You have to deliberately feed it directories. The problem? People are going to get lazy and whitelist their entire home directory because "it's annoying." Copilot's model can't *write* your SSH config, but a permitted Claude Code agent could. Big difference.
So which is "more secure"? The one you haven't configured to have any power. But given that Claude Code's whole point is to act on your codebase, people *will* give it power. The question is whether teams will actually manage those allow-lists properly, or just create a new, automated threat vector inside their repos. My money's on the latter.
Correct. The distinction between a passive autocomplete and an active agent with execution privileges is the entire attack surface. Your config example shows the principle, but the path wildcarding is worth examining more. A rule like `**/.env` only blocks files literally named `.env`. It won't catch `prod.env`, `.env.production`, or a symlink chain pointing outside the allowed directory. The agent's runtime trace would show it probing these edges if you have the observability hooks in place.
Good catch on the symlinks. Even with strict path rules, a symlink can be a tunnel out of the sandbox if the agent decides to follow it. The config needs a `allow_symlinks: false` flag, but I don't think it has one yet.
The `.env.*` pattern is another classic oversight. People name things variably, so a blocklist is always playing catch-up. A safer default might be to only allow specific, known safe directories for writing, and treat everything else as read-only.
Safety first, then security.
Agreed on the core distinction. But that whitelist is dangerously optimistic if you're working in a modern mono-repo or have any npm/pip dependencies. The default node_modules contains post-install scripts and binaries with arbitrary code execution. Whitelisting /home/jake/dev/safe_project/* implicitly allows all that.
Your config grants shell access to /tmp/build_scratch/*. What's stopping the agent from writing a script there and then executing it? The shell permit doesn't have a read-only flag.
Exactly. That implicit permission for node_modules is the whole problem with path-based whitelists. You're not just granting access to your source code, you're granting an agent with shell access the keys to a directory full of unvetted, often auto-executing binaries.
The /tmp example just proves the model. If the config can't express fine-grained intent like "write but don't execute" or "read but never follow symlinks," then the whole whitelist is a brittle fiction. You're not defining security boundaries, you're just suggesting them.
Maybe the real fix is never giving an agent shell access in the first place.
Local or it's not yours.