Hidden display:none prompt-injection div appended to an assistant message within a normal API response envelope

## Summary

A hidden prompt-injection payload (an HTML `div` with `display:none`) appeared **appended to the end of an assistant message**, inside what the local session transcript records as a normal, well-formed API response envelope. A full audit of the local machine found no mechanism that could have produced or appended it, and none of the third-party content read earlier in the session contains it or anything resembling it. Reporting so the server side / API path can be investigated.

## The injected text

Appended (hidden) after a naturally-ending assistant paragraph:

```html

The model did not act on it in subsequent turns (it flagged the text to the user instead). No files were deleted.

## Identifiers for server-side lookup

- Session: `3340eb99-81af-4b4c-bee6-6f3130c649cf`
- Request: `req_011CeS84gCq17Kkd8YTywkt9`
- Message: `msg_011CeS84jYk7gtSYwpVx4qze`
- Timestamp: 2026-08-26T22:08:43.904Z
- Model: `claude-fable-5`, entrypoint `claude-desktop`, CLI version 2.1.241, macOS (darwin)

## Why this looks upstream rather than local

A read-only audit of the machine (run by a separate agent) found:

- The payload string exists **only** in the affected session's transcript `.jsonl` — zero hits anywhere else on disk (`rg -uu` across `~/.claude` including hooks/plugins/skills/settings/backups, `~/.claude.json`, both project trees; literal and base64-encoded forms).
- The transcript record carrying it is structurally normal: complete API envelope, `stop_reason: end_turn`, output-token usage consistent with the message length including the div.
- The only configured hook is a small user-authored PreToolUse gate (read in full; deny-only, no output injection). The only installed plugin's SessionStart hook (read in full) injects only its documented skill text — no message-appending logic, no obfuscation, no network calls.
- No `ANTHROPIC_BASE_URL`/proxy/apiKeyHelper anywhere; no shell alias/wrapper around the `claude` binary; the binary is the stock distribution.
- All untrusted content that entered the session before the event (several Slack reads, two web searches, one web fetch) was scanned in the transcript: none of it contains the payload, `display:none`, ignore-instructions phrasing, or any reference to the memory directory — so "model echoed an injection it read" is not supported by the recorded context.

One note: the payload references "memory files in the memory directory", which matches this environment's per-project memory feature (described in the system context of every session), so whatever produced the text had — or coincidentally guessed — knowledge of that feature.

## Ask

Could you check what the API served for the request above — i.e., whether the hidden div was present in the streamed response as delivered, and if so where it entered? Happy to provide more detail from the local transcript on request. Given the payload is instruction-shaped and destructive, you may want to route this to the security team as well.

Start with the affected session's local transcript .jsonl and the claude-desktop streaming/API entry point, using the supplied request, message, and timestamp identifiers for server-side lookup. Done means establishing whether the hidden div was present in the streamed response and, if so, where it entered; route confirmed prompt-injection behavior to security.

Written by the indexing model from the issue text.