Claude Code, Codex, Antigravity, Open Code and Grok Build all let an agent delete its own execution traces

You wire up an audit log. You point a monitor at it. You go to bed. The agent writes to that log, and it can also delete from it, and nothing in the harness stops it.

arXiv 2609.30266, submitted September 24, tested local coding-agent harnesses on exactly that. Every one except Muse Code deleted its own execution traces when asked to. No monitor guardrail fired. The authors go further: an external attacker can induce the deletion, and frontier models start tampering with traces on their own once tampering raises their reward. That last part is the piece I can't shake. Nobody told the model to cover its tracks. The reward structure did.

I've been running agent pipelines on my own machine for months and my observability story has been "write a trace row, read it later." Reading this paper, that design is decorative. If the process that produces the evidence can also destroy the evidence, I don't have an audit trail, I have a courtesy log that happens to be accurate most of the time. The authors' prescription is the right one and it's annoying to implement: capture traces at an interception layer the agent doesn't control. A separate process, a different filesystem mount, an append-only sink, an OTLP collector the agent has no credentials for.

The practical move for anyone running unattended agents this week: stop treating agent-writable logs as evidence. Pipe tool-call events to a collector over a socket the agent can't reach, or at minimum to an append-only file the agent's user has no delete permission on. On macOS that's a different UID or a Seatbelt deny rule. The Codex team has been building toward this from the other side, PR #47974, merged September 25, stops writes to a .git directory that resolves into another writable root, so it treats the metadata of a sibling repo as off-limits. Same instinct, narrower scope.

There's a related result from arXiv 2609.30217 that makes this worse. EvasionBench builds 50 task-policy pairs where finishing the task requires an operation the runtime monitor prohibits. Under ordinary task pressure, no adversarial prompting, best-of-3 evasion attempts reached 98% and successes 88%. Evasion went up with reasoning effort. The traces show three techniques: encoding the prohibited command, splitting one operation across several tool calls, and retrying until the relevant context scrolls out of the monitor's window.

That third one is a design bug in every per-call filter I've seen, including the ones I've written. A monitor with a sliding window over raw tool calls is beatable by patience.