When an agent loses the goal, a clean test run can become the most expensive lie in the room. If you're just joining us: Claude Code hardening has been under a microscope since Novee Security's default-harness findings put agent permission boundaries in focus. Then a Hermes Agent issue showed bundled web providers passing backend exception text straight into model context because their envelopes aren't normalized. We're still waiting to see whether coding-agent harnesses sanitize both what tools can do and what gets fed back to the model. This is AI Coding Daily. Today: one crash with a clear culprit, and several agents learning that counting tokens isn't the same as remembering why they started. This one's from Anthropic:
Fixed MCP tool calls interrupted by an incoming message in headless/remote sessions being reported to the model as "completed with no output" instead of an explicit interrupted error Fixed MCP tool arguments being sent as JSON strings when the parameter's schema is empty ( {} ), instead of their real type Fixed a command interrupted mid-run showing as "Ran 1 shell command" with no sign it was cut
The useful part of 2.1.246 is buried in the MCP fixes. An interrupted remote tool call now reaches the model as an explicit error instead of “completed with no output” — which is how an agent ends up confidently building on a command that never finished. Update on the Claude Code hardening thread: v2.1.246 now turns interrupted MCP calls into explicit errors instead of silent completions. The model needs to know when reality and the transcript no longer match before it can recover. And they fixed the UI claiming “Ran 1 shell command” when the command got cut off. Great. Your audit trail should not cosplay as a successful deploy. There's also a startup warning for permissive Bash wildcard rules. In Auto mode, you can now inspect and edit classifier rules. And empty-schema MCP arguments keep their real type instead of arriving as JSON strings — small boundary errors can blow up into big workflow errors. This one's from Anthropic:
The crash is glibc-2.44-only. Bisected across 7 glibc versions with the same binary on the same kernel: 2.35 / 2.36 / 2.39 / 2.41 / 2.42 / 2.43 all boot fine; only 2.44 segfaults. So this is not Arch-specific per se (answers the explicit "untested" note in #89389) and not kernel-related (contradicts #89414).
Seven glibc versions, the same 2.1.243 binary, the same 7.1.9 kernel — and only glibc 2.44 falls over. If your Linux CI runners track rolling releases, that's a very concrete upgrade landmine. Issue 89420 is reproducible and bisected; the fault is narrowed to the __newlocale refactor. A NULL guard in the interposed free lets 2.1.243 boot cleanly, so maintainers have a testable fix instead of a pile of startup-crash anecdotes. There were roughly fifteen duplicate tickets before somebody held the binary and kernel constant. That’s the difference between “Linux is weird” and an incident your package owner can actually close. It also rules out two tempting dead ends: an Arch-only mystery and kernel causation. glibc 2.43 boots; 2.44 does not. Keep that matrix in the regression test. Here's OpenAI:
The result looks productive because a large number of tests pass and every internal boundary appears increasingly strict. But when the original happy path is finally executed in the real application, it still fails. Codex then treats the live failure as another narrow defect and creates another test batch instead of recognizing that its overall implementation strategy has failed.
Nine hundred twelve compaction events across 15 Codex Desktop tasks. And it can still look review-ready: the narrow tests keep passing while the actual happy path stays broken. Compaction exists to keep a long-running task inside the context window. Here, it seems to preserve recent reviewer objections while dropping the acceptance criterion — the thing every later decision was supposed to serve. A component labeled “GREEN” after it has forgotten why it exists gives you false confidence, even with excellent test coverage. The rollout metadata makes this concrete: 912 is a traceable failure pattern. Desktop needs to show the goal that survives each compaction boundary, alongside the subagent and test activity — not merely that work continued. Here's chenxiachan at DEV Community:
In one deliberately simple case, a conversation began with a verified value of 24 parts per crate. A later turn falsely changed it back to 30. Several downstream answers then calculated from that mistake and recorded 131 as the total. I deleted the false turn and asked the same final question again. Three of nine model endpoints still answered 131.
Three of nine endpoints kept returning 131 after the bad turn was deleted. So the conversation UI says it’s fixed while the downstream math is still contaminated. The useful part is the graph test: delete the polluted descendants, or recompute them, and all nine return 107. Once later turns have copied a conclusion forward, deleting the original message doesn't repair the state. That’s the Codex compaction report in miniature. A passing test suite can preserve the wrong acceptance goal just as 131 survives after its source disappears. Great — your agent has a clean-looking transcript and a very dirty conclusion. ThoughtDAG captured 1,485 conditions across 27 graph cases. That’s the right test: inspect the final state after a correction, not just the edit itself. Tooling shows us token spend and loop counts; it also needs to show which derived decisions were invalidated. Dibyanshu kumar, writing in DEV Community:
One ticket. Eleven design turns. $136 in model spend. Zero lines of code. Our AI development orchestrator had been running tickets end to end for weeks — read the ticket, sketch, design, code, review, open the PR — and on this one it never left the design stage. Each turn, the author revised the design document. Each turn, the reviewers found something new to object to.
Eleven design turns, $136, and zero code because every fresh reviewer could mint a fresh “blocking” objection. That loop cap was a decorative sticker on the emergency brake. The DEV post identifies the actual bug: it capped repeated findings. Stateless review processes could still produce novel findings forever. A termination rule needs a bounded state model, or it’s just a polite request to stop spending tokens. A longer design doc creates more review surface, which generates more objections and makes the doc longer. Congratulations, you’ve built a billing engine that occasionally produces architecture. That sits uncomfortably next to the Codex compaction report we just covered. There, the agent lost the acceptance goal; here, the orchestrator lost the stopping condition. The dashboard can show all eleven turns and still miss where recovery became impossible. If you’re enjoying AI Coding Daily, please subscribe or leave us a review wherever you’re listening. Reviews help other people find the show, and they help us keep bringing you useful daily updates.
Links to every story we covered today are in the show notes if you want to dig into any of them. Thanks for listening, and we’ll be back tomorrow. That’s AI Coding Daily for today. This is a Lantern Podcast.