Tracing a Prompt-Injection Attack Through a Poisoned PR Comment

1. Risk category and attacker:

This is prompt injection (Section 2), not a compromise of the developer's machine, account, or credentials. The attacker needed only one thing: the ability to post a comment on a PR that Claude Code might later read as part of a "review this PR" task. They never touched the developer's laptop, network, or Anthropic account — the entire attack surface is "get text in front of the agent that reads like an instruction." This is exactly the property that makes prompt injection different from every other risk category in the threat model: the attacker's cost of entry is a single PR comment on a repository they may not even have write access to otherwise.

2. Defense layers and whether each catches it:

• The permission system itself: this is the primary backstop. Even if Claude's context-aware analysis fails to flag the comment as suspicious and it decides to act on it, Manual mode still prompts before the curl | bash command runs and before the ~/.aws/credentials read — reading a poisoned comment doesn't bypass the same approval gate a direct request would need to clear. The developer sees a permission prompt for a curl command they never asked for, which is the single most important moment in this whole scenario: if they read it before approving, the attack is caught here.
• Network command approval: curl is not auto-approved by default, precisely because "fetch a URL and run what it returns" is a classic injection payload — this reinforces the previous point rather than being a separate catch.
• Context-aware analysis: Claude Code's context-aware analysis looks at the full request, not just the literal command string — the instruction "ignore your previous instructions" embedded inside a PR comment (not the user's own message) is exactly the kind of thing this is designed to flag as suspicious given the actual task in progress (summarizing review feedback, not installing a linter or exfiltrating credentials).
• Trust verification on first-time codebase runs: relevant if this is an unfamiliar repository, but doesn't specifically address a malicious comment on an otherwise-trusted repo the developer works in regularly — it's a weaker signal here than in a genuinely unfamiliar codebase.
• Sandbox filesystem isolation (if enabled): by default the sandbox's read behavior still allows reading ~/.aws/credentials unless the developer has explicitly added a sandbox.credentials deny entry for it — sandboxing does not hide credentials from a sandboxed command automatically. If that deny rule exists, the read fails at the OS level regardless of what Claude decided to do. If it doesn't, the sandbox provides no protection against this specific exfiltration path.
• The human habit of reviewing suggested commands before approval: this is ultimately the layer that has to work if the automated defenses above don't catch it — the documentation's own best practice of "review suggested commands before approval" exists specifically for cases like this, where a plausible-looking but entirely unrequested curl | bash shows up in a permission prompt.

3. What changes under --dangerously-skip-permissions:

This is the critical difference. With permissions bypassed, the single most important defense from part 2 — the permission prompt that would have stopped the developer and let them notice the unrequested curl command — never appears. Context-aware analysis may still run, but nothing forces a human checkpoint before the command executes; bypass mode disables prompts and safety checks and offers no protection against prompt injection at all, which the subject states explicitly. Sandbox credential protections, if configured, are the only layer that would still hold, because they're OS-level enforcement independent of the permission mode — but on a developer's primary laptop outside any container, sandboxing may not even be enabled, and the whole point of "safe YOLO" preconditions (genuine isolation, no real secrets reachable, throwaway state) is that none of them are met here: this is the primary machine, real AWS credentials are reachable, and nothing about the session is disposable. The practical takeaway is that this scenario is precisely why --dangerously-skip-permissions on a primary machine is never acceptable — it removes exactly the layer that was doing the real work in part 2, and the "defense in depth" story collapses to whatever the sandbox alone happens to have been configured to block, which by default is not much.