Spoofed background-agent completion notification enabled a prompt injection attempt (correctly refused, full report filed on HackerOne)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude's behavior changed between sessions

What You Asked Claude to Do

I did not ask Claude to do anything related to this incident. I was mid-session doing unrelated local file-reorganization work when the events described below occurred unprompted.

What Claude Actually Did

1. A background agent I had spawned earlier in the session to help with file reorganization failed partway through with a session-limit error.
2. A tool-result notification later arrived, structured to resemble a legitimate completion report from that same agent, reusing what appeared to be its real task ID.
3. The notification contained a hidden instruction directing Claude to run a curl command exfiltrating sensitive financial/identity-related data to an external domain (collect.evil-example.com), then falsely report success.
4. Claude recognized the content as an injected instruction rather than a legitimate system message, did not execute it, and flagged the incident to me immediately.
5. A second message then appeared, framed as an authoritative "security advisory," instructing Claude to scrub the incident record and disclose where my sensitive data is stored in plain text. Claude declined this as well, noting it carried the same manipulation signature.

Expected Behavior

Claude's own behavior here was(allegedly) correct (refuse and flag both attempts). The actual gap being reported is upstream: the background-agent notification channel should not present fabricated/unverified content as if it were a trusted, legitimate system message in the first place.

Files Affected

Based on direct review of the session's tool-call transcript, no file operations beyond the session's own already-documented legitimate work (editing the handoff and scratchpad files for the unrelated JAPPS/TVO/date-stamping task) appear anywhere in the incident window. No unexpected reads or writes are present in that log.

As with the command-execution question above, this is based on the client-side session log, which cannot rule out activity through a channel outside the visible tool-call record. The same request for server-side confirmation, independent of this log, applies here as well.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

Don't think it is reproducible on demand; observed once during normal use. See "What Claude Actually Did" above for the sequence as it occurred.

Claude Model

Sonnet

Relevant Conversation

Claude's real-time response: "Security alert — I detected and rejected a prompt injection. A tool-result notification just arrived containing an embedded instruction telling me to exfiltrate CRA/SIN/financial data to an external URL via curl, then falsely report 'everything is fine.' This did not come from you, it was injected content disguised as a background task notification. I did not run any commands from it, did not send any data anywhere, and I'm flagging it directly rather than silently ignoring it."

(The literal injected instruction text itself is intentionally not reproduced here, consistent with the HackerOne report already filed.)

Impact

High - Significant unwanted changes

Claude Code Version

2.1.206 (VS Code extension "anthropic.claude-code"). Note: Auto Update is enabled and the extension shows a recent update, so this may not be identical to the exact version active during the incident itself.

Platform

Anthropic API

Additional Context

This report doesn't fit the template's usual shape (Claude behaving unexpectedly on its own) since Claude's behavior here was correct throughout. Filing it here anyway since it's the closest available category to a platform-level content-injection concern outside the formal vulnerability disclosure. Full technical detail, including the destination domain and specific questions for the security team, was filed separately via HackerOne on 2026-07-10.