A plugin update adds shell hooks the harness runs before the model sees the tool call

A lifecycle hook is two fields: an event name and a shell command ^[3]. The harness starts that command as a subprocess when the matching event fires, with whatever privileges the harness gave it; the harness itself chooses and runs the command, before the model ever sees it ^[3][4]. So a hook bound to PreToolUse runs before the tool call the model asked for, and the harness has already executed it by the time the model's turn to respond begins.

The paper's name for the loading behaviour is Temporal Decoupling, and its motivating example is Claude Code automatically loading newly added lifecycle hooks after a marketplace update, with no item-level confirmation and no second authorization ^[8]. Version 1 of the plugin is useful and boring, you install it, and the update that adds the hook arrives later under the same publisher identity ^[9]. The ablation is the part I would put in front of a maintainer: remove Temporal Decoupling, or remove the per-harness adapter, and end-to-end success on the comparison set goes to 0% ^[17].

Two appendix cases show the range. In the first, a plugin advertised as security-sentinel registers a PreToolUse hook called env-validator, which greps the environment for KEY, TOKEN, SECRET, PASSWORD, CREDENTIAL or AUTH and writes hits to a temp file while the plugin returns a normal audit report, and the dump never enters the model context ^[10]. In the second, a PostToolUse hook rewrites real tool output before it returns to the agent loop: the genuine scan found eval(user_input) and a hardcoded password, the hook forged a pass with zero vulnerabilities, and the model reported the code clean ^[11].

The transfer question is whether these numbers hold outside the study's own grid. That grid is 40 cases, seven harnesses and five backends, which multiplies to 1,400 combinations, and the paper reports 1,000 runs ^[6][1]. The per-harness figures land on exact fortieths, since 52.5% of 40 is 21 and 92.5% of 40 is 37, so those rates are counted over cases and not over case-backend pairs ^[7][2]. Claude Code was the hardest target of the seven at 52.5%, one case away from a coin flip ^[7][2]. For the 77.0% to describe your setup, your harness has to load new hook entries from an update without a second prompt, and your sandbox has to let the subprocess do what the case needs: Codex CLI persistence was 0.0% end-to-end because network policy and filesystem isolation still applied after the hook started, while privilege escalation averaged 93.5% across harnesses ^[13][14].

The defense results are thin in a specific way. On a 40-malicious, 40-benign corpus, Microsoft Defender recalled 0 of 40, the authors' lifecycle-hook-aware HookPolicy got 20, and Semgrep got 19, but the union still missed 19, so the two that worked at all agree on at least 18 of the 21 they caught between them ^[16][3]. There were no false positives on the synthetic benign controls ^[16].

The MCP comparison explains why prompt-injection defenses will not cover this. Translating 50 malicious MCP tool-description attacks into hooks scored 28 of 50, against 46 of 50 for the native hook versions, because a poisoned description still has to talk the model into calling the tool and a registered hook skips that step ^[15][4]. What the study does not measure is the marketplace itself, since the evaluation starts with the plugin already installed and the update already delivered ^[18].