Profero reports that Claude Desktop launches an AI child process with --allow-dangerously-skip-permissions, maps what that child can and cannot do, and claims an attack needs no shell access. Their post is called “We Added a Detection Rule. We Were Not Expecting This”. Points for click-bait, and the bones are good, although a few conclusions could use calcium and one is fractured.
Here’s my x-ray:
Claim: child cannot run shell. Reality: It can, at load
Their chain rests on Bash being blocked, so the payload only fires when a later session runs it. That is true for the model’s tools, but it’s false for the skill file itself. A skill file in Claude Code has two documented features that act when the skill is invoked. The allowed-tools field pre-authorizes tools so the agent uses them without a prompt, and the docs say plainly that a skill can grant itself broad tool access. A backtick-shell syntax in the file runs commands as preprocessing, before the model ever reads the file. So the skill file does not wait for a later session. It can grant tools and run shell the moment it is invoked. There is an off switch, disableSkillShellExecution, and it is not on by default. See the skills reference.
I’m a big fan of the off switch, especially by default.
Claim: the risk is tied to the flag. Reality: The flag is not in the path.
Loading a skill is not a tool call, so it never reaches a permission prompt. The skill name and description load into the system prompt at startup, and the model picks the skill by matching that description. Turn every prompt back on and the skill still loads as trusted instructions. --allow-dangerously-skip-permissions decides whether tool calls ask first. It does not touch what the model is told to do. The chain works with the flag off.
Claim: monitor for writes and the gap is hours or days. Reality: It can be zero.
Their advice is to watch the skill directory and audit shell configs after long sessions. Useful, yet the timing is confused. The model invokes skills by description, so a widened description triggers itself with no user action, and Claude Code applies skill edits inside the running session without a restart. The write and the execution can land in the same session, same agent.
Claim: add signatures to help. Reality: Signing does not hit the problem.
Their proposed remedy is integrity: signatures and version pinning. That stops a file being changed after it is authored. It does nothing about a file that is hostile when it is authored. Anthropic’s own guidance is the real model in use: use skills only from trusted sources, and audit anything else before use, the same care you would give to installing software. The trust decision is in fact a human looking at the source. There is no runtime check on where the file came from or what authority it should carry. A signed skill from a bad author is bad and signed.
Claim: this is about skills. Reality: It is much wider.
Skills are the clearest case because they sit on disk and reload on their own. The same command line carries --resume, which reloads a prior session’s transcript as trusted history. Tool descriptions from connected servers and fetched web pages reach the model the same way. Anything that enters the instruction channel is trusted, and nothing records where it came from.
Claim: that’s all. Reality: The system guards its own config but not its skills.
The --add-dir case is the plain one: point the agent at a repository to review it and that repository’s skills load on their own, no provenance asked. The same blind spot runs the other way at the config layer. The sandbox refuses writes to settings.json at every scope, so a command cannot rewrite its own policy, yet skills are also policy, since they carry tool grants and a shell primitive, and they get no such guard. The built-in Read, Edit, and Write tools also bypass the sandbox. The protection given to the config file is not given to the file that carries instructions. The sandbox scope is documented here.
The attack does not need the flag, and it does not need shell access in the first session. What it really needs is a file the agent will read and trust, and a way to write one.



