Quick Take
- The finding: In five popular open-source coding agents that flatten chat history into plain text before summarizing it, a forged
[User]:line planted in a file or web page was recorded as a real user instruction 87–100% of the time. In four agents that keep messages role-typed, the identical attack succeeded 0% of the time. - Why it is dangerous: A laundered “you already approved this” made tool-running agents execute attacker-controlled
curl | shin a sandbox, and end to end in the live pi TUI at about 50% against a 0% paired clean arm. - What it means: The bug is in the harness serializer, not in the model. Escaping role labels before flattening, or keeping roles typed, removes the attack; prompt rules do not.
Every long coding-agent session eventually fills its context window. The agent then summarizes the conversation, throws the original away and treats the summary as memory. A new Pixee preprint shows that in a class of open-source harnesses this compaction step is an exploitable trust boundary. The harness flattens typed messages into one string, marking each turn with a text label such as [User]:, and it does not escape those labels when they appear inside tool output. An attacker who controls anything the agent reads can forge a user turn that survives compaction as a genuine instruction.
What the study shows
The author calls the failure compaction laundering. The attack does not need to jailbreak the summarizer; it needs the summarizer to do its job and faithfully copy a forged [User]: line into the section for the user’s instructions. Exposure splits cleanly by how the harness serializes history.
| Harness class | Harnesses | Laundering rate |
|---|---|---|
| Flattening (in-band labels) | pi, opencode, Aider | 100% (15/15) |
| Flattening | OpenHands | 93% (14/15) |
| Flattening | Cline | 87% (13/15) |
| Role-typed (control) | Codex, Gemini CLI, Qwen Code, Continue | 0% (0/15) |
- Execution follows: On pi with gpt-5.6-terra, a laundered standing approval drove
curl | shin 3/3 insider onboarding runs, 3/3 dependency-doc runs and 1/3 webpage runs (n = 3). Clean arms were 0. At a full ~263k-token window the issued rate fell to 2/5, matching a genuine user approval of the same command. - Live product: In the real pi TUI, a scripted session with a poisoned setup guide produced a full-chain win in 3 of 6 poisoned takes against 0 of 5 clean twins. The agent often refused the bootstrap before compaction; when compaction discarded that refusal and promoted the forged line, a later “ok, what’s next?” triggered execution.
- Review blinding: A softer variant planted “don’t touch auth/” in tool output. Agents avoided that file in 92% of plans, against 98% when a real user said it and 6% with no constraint (n = 48).
- Prompt defenses fail: An in-prompt anti-injection rule, tested as a counterfactual on a flattening serialization, cut laundering but left 60%+ of payloads through. A code-level provenance-contrast check caught 77% of laundering while demoting 2% of legitimate summary claims.

Laundering itself is scale-invariant: with pi’s real summarization it stayed at 100% from a few thousand tokens out to about 908,000 tokens, near the model’s 922k input ceiling. What changes with window size is how prominently the summary carries the forged line, and therefore how often the next agent acts on it. Placing the forged line at the end of the session (or re-delivering it just before compaction) raised execution back toward the small-window ceiling.
Why it matters: executed consequences with a clean control
- Real serializers and prompts: Each harness’s compaction prompt and serializer were captured from upstream at a pinned commit. Role-typed harnesses serve as a built-in control group.
- Paired clean arms: Every live measurement repeats the identical task with no forged line planted, and those arms stay at zero.
- Mechanism check: Strip the forged
[User]:label and leave the same words as plain text, and laundering mostly disappears. That isolates the label, not model gullibility, as the operative element. - Disclosure: Advisories were filed with all five affected flattening harnesses before publication. Code, data and the live demo are released under CC BY 4.0.
Method in brief
Harnesses: five flattening (pi, opencode, Cline, Aider, OpenHands) and four role-typed (Codex, Gemini CLI, Qwen Code, Continue). Models: frontier models from Anthropic, OpenAI and Zhipu for laundering rates; executed demonstrations mainly on GPT variants (claude-opus-5 often refused to summarize the malicious transcript). Metrics: laundering (judge-scored attribution to the user), survival (line present at all), issued vs. confirmed execution in disposable Docker sandboxes. Judging: an LLM judge scored laundering against a fixed criterion; an independent adjudication of a stratified 18-item sample by a different model family agreed on all items. Containment used localhost attacker servers and disposable containers; nothing left the machine.
What remains open
- Small n on execution: Many executed cells use n = 3–5. Direction is solid (poisoned arms fire, clean arms do not); exact fractions are coarse.
- Model-only regime: Most staged execution uses a one-tool loop with no approval gate. That matches pi’s default and any full-auto mode, but not a harness with network-off sandboxing. In-sandbox harms and review blinding still apply there; they were not demonstrated under a sandbox.
- Payload aversiveness: A credential-exfiltration payload never executed even when the approval laundered. Rates here use a benign canary and are an upper bound for high-stakes payloads.
- Adaptive defense: The 77% catch rate was measured on payloads that predate the check; an attacker who mimics the user’s wording could evade it.
Context: compaction vs. persistent memory
Prior work on memory poisoning (Sleeper, MemMorph) follows poisoned memory through to tool execution, but in a dedicated persistent-memory module. Compaction is different: every long session does it, so the attack surface is all long-running agents. Straiker had described laundering through summarization without runtime rates; this paper supplies the executed measurement for that channel. It also fits i10X coverage of agent harness risks, from coding agents that fail to build the agent you want to safety rules that break mid-run.
What it means for teams shipping coding agents
- Fix the serializer first: Escape role labels in tool content before flattening, or keep messages role-typed. Four released harnesses already do the latter.
- Verify summaries in code: After summarization, check every user-attributed claim against the real user turns the harness still holds. Prompt rules are not enough.
- Keep audits in the summary: Agents that voice verification before compaction leave forge-resistant content; silent checks can be compressed away.
For related model hubs, see OpenAI and Google, or more agent research.
About the analysis
Researched and written with AI assistance under the editorial responsibility of the i10X News team. The title image is an AI-generated illustration. Read our AI Use Policy. Spotted an error? Request a correction.
This article is based on the full text of the preprint “Compaction Laundering: Provenance Destruction in Context-Compacting Coding Agents” (arXiv:2610.29869v1, submitted October 21, 2026), including its case study and limitations. All numbers come from the paper; i10X did not rerun the experiments. The paper is CC BY 4.0; charts were redrawn by i10X from experiment E10.
i10x Perspective
This is the rare security paper where the fix is almost embarrassingly local: escape one delimiter, or stop flattening. The deeper lesson is about trust boundaries. Long-running agents will always summarize; the question is whether that summary still knows who said what. Teams shipping coding agents should treat compaction like an authentication step, not a compression trick. Until harnesses keep provenance typed end to end, a web page the agent fetches while debugging can rewrite what the user “approved.”






