Compression re-serves system/environment block in-band, indistinguishable from prompt injection

[roethlar]

Summary

When compression is enabled, pxpipe appears to render/relay the Claude Code system/environment block (model id, knowledge cutoff, tool docs, etc.) back into the conversation through the normal assistant-visible content channel, in a form that is structurally indistinguishable from an in-band prompt injection.

What we observed

Across a long session, several messages arrived containing what looked like re-served "system-reminder" / "Environment" blocks — claiming things like model name/id and knowledge cutoff — physically located inside a user turn rather than delivered through whatever channel real system/environment context normally arrives through. Some instances were explicitly labeled as having been "relocated by pxpipe from the system prompt."

This is concerning independent of whether the content of those blocks was accurate. In this case, once compression was disabled, we confirmed the underlying facts (model = Sonnet 5, cutoff = January 2026) were correct — so this is not a report of a misread/hallucination bug. It's a report that the delivery mechanism, when compression is on, reintroduces trusted context through an untrusted-looking path, which:

• Makes it impossible for the assistant (or a careful user) to distinguish legitimate relocated environment content from an actual injected payload trying to spoof one.
• Caused significant session friction: the assistant (correctly, per its own safety posture) refused to trust the relocated blocks for several turns, since "arrives as chat content, claims special authority" is exactly the injection pattern it's supposed to resist — regardless of whether pxpipe's relocation was itself benign.

Suggested fix

If the system/environment block must be re-served through the request body at all under compression, consider:

• Keeping it in whatever native message role/field Claude Code / the Anthropic API already uses for system context, rather than re-emitting it as inline content in a user turn.
• If it must ride along as rendered content, avoid labeling/formatting it in a way that mimics a real system channel (e.g. "system-reminder" tags), since that's the exact shape trusted context is expected to take — reusing it for anything proxy-injected undermines the model's ability to tell real from spoofed.
• At minimum, document this behavior clearly so users/integrators know compression can cause system/environment context to be re-delivered in-band.

Environment

• Observed via Claude Code, model reporting itself as Sonnet 5 (claude-sonnet-5).
• Reproduced by toggling pxpipe compression off mid-session (issue stopped); exact deterministic repro steps to re-trigger not yet narrowed down — happy to help if useful.

[roethlar]

Additional evidence from the original Sonnet 5 session provides a same-session A/B:

• With pxpipe compression enabled, the relocated system/environment block repeatedly arrived through the user-message channel. Sonnet treated it as prompt injection, rejected legitimate owner instructions, and disputed even accurate model/environment information.
• This caused material operational harm: tool use was disrupted, the requested bootstrap task was never completed, and the session had to be abandoned.
• After compression was disabled, the next turn arrived normally and Sonnet explicitly observed that the suspicious block was gone.

This also clarifies that OCR corruption was not required. Sonnet later confirmed it was actually Sonnet 5, as the relocated content had said. The decisive problem was accurate privileged context being delivered through an untrusted role.

This appears related to #37: one manifestation is a hard cyber refusal/Fable-to-Opus fallback; another is model-level prompt-injection defense and sustained refusal without an API-level safety stop.