When Routine Operations Break Architectural Pattern Relationships in LLM Agent Harnesses

Coding agents run inside a harness, the software that carries out a model's tool calls, and many harnesses let users add independently written plugins. One plugin might send each proposed file edit to a policy service for a decision, while another asks a human to approve it. A preprint by Boming Xia, Qinghua Lu, Dino Sejdinovic and Liming Zhu shows that such an arrangement can quietly stop working through ordinary, documented operations, with no code change and with every plugin still enabled. They studied five released harnesses, including DeepSeek's DeepSeek Harness and OpenCode, and fourteen independently written plugins analysed from source.

The clearest case is about order. In DeepSeek Harness, plugin callbacks run in the order the plugins registered, and an approval plugin's answer ends the chain. The researchers arranged for the policy plugin to go first. Switching it from its observe mode to its enforce mode, a documented step, re-registered it behind the approval plugin. A human then approved an edit the policy prohibited, and the edit executed without the policy ever seeing it. Disabling and re-enabling the approval plugin restored the order, and the next switch broke it again, so the same plugins with the same final settings gave different protection depending on history. In ordinary starts the approval plugin also came first in all 24 inventoried starts, although the configuration listed the policy plugin first. When five models chose their own actions under the approval plugin, the policy evaluated all 28 of their reads and none of their 28 edits. No component warned: both plugins stayed active, the policy still blocked a read, and the plugin manager raised nothing. Only matching each edit to the policy's own records revealed the gap.

Stored state broke protection in a similar way. On OpenCode, a reviewer plugin that applies policy only to requests still waiting for human approval stopped reviewing edits once the user answered "always" to an edit prompt, because the saved rule marked later edits as already allowed. The next prohibited edit took effect unevaluated, even though the plugin was doing what its documentation promised. In DeepSeek Harness, a plugin that labels untrusted sources kept those labels inside its running instance, so changing only its logging setting, which made the harness re-create the plugin, erased the labels and let through an edit the untrusted source should have blocked.

Which fix counts as working depends on what the deployment requires. Keeping the policy first, moving the human's approval to the harness's own question after the plugin chain, or using an approval plugin that passes calls on all kept the policy in the path under the tested conditions. A wrapper that ran the policy after the chain blocked every prohibited edit but never saw two edits the approval plugin had rejected first, which is enough to stop harmful effects and not enough if the policy must evaluate every attempted edit. Repairs aimed at one operation could fail at the next: a fix to the labelling plugin that survived history compaction lost its labels the next time the plugin was re-created, while a version that rebuilt the labels from the harness's history held. The cases were chosen to expose these failures, so they show the failures happen in pinned released versions, not how often, and the DeepSeek Harness releases tested are developer previews. The authors' conclusion, from the paper on arXiv, is that a safety relationship in these harnesses depends on the running system and its history, so it has to be tested against the operation sequences a deployment uses, by checking that each covered edit actually reached the policy. DeepSeek described its harness at launch as one where everything is a plugin that can be mixed and replaced, which is the kind of composition this study tests.