A tool-call contract changed quietly overnight, and your regression suite may be the only thing between it and a very strange deploy. This is AI Coding Daily. Claude changes a tiny string detail. Codex turns logging into an SSD endurance test. And one popular agent hands the model a Python shell. First up, Amazon Bedrock's Claude Sonnet 4.5 tool-use behavior. One invisible character suddenly has operational consequences. Tap follow so the next episode finds you. From Amazon:
Claude Sonnet 4.5 now preserves intentional formatting in tool call string parameters. Previously, trailing newlines in string parameters were sometimes incorrectly stripped. This fix ensures that tools requiring precise formatting (like text editors) receive parameters exactly as intended. This is a behind-the-scenes improvement with no API changes required. However, tools with string parameters may now receive values with trailing newlines that were previously stripped.
Bedrock quietly changed Claude Sonnet 4.5’s tool-call contract: trailing newlines in string parameters now survive. No API bump or migration step—your file-writing or patching tool just gets different bytes than it did yesterday. The glamorous world of agent reliability: somebody trims a newline, somebody else depends on it, then your diff tool starts behaving differently with no code change on your side. That only gets caught in review if a human reads the generated patch. AWS calls it a behind-the-scenes improvement, and for text editors it probably is. But you still need regression gates with exact tool inputs and outputs; “no API changes required” doesn’t replace replaying the cases that touch your filesystem. Newreleases has the details on this one. Oh My OpenAgent beta.4 was already behind beta.5 by nineteen hours. The visible release trail is two merge PRs and a docs refresh, so I wouldn’t put that near a shared developer workflow just because the version number looks settled. Two commit names stand out: “source-state” and “memory-surface-direct.” Those can change what an agent retains or exposes between steps; beta labels don’t make that harmless. Pin the commit, run a representative task, and diff the tool behavior. “Refresh knowledge base against HEAD” is also a very developer-shaped way to say the documentation was chasing a moving target. At least it’s honest about the velocity. GitHub writes:
On my machine, after about 21 days of uptime, the main SSD has written about 37 TB. Process/file-level checks show Codex SQLite logs are the main continuous writer. That extrapolates to roughly 640 TB/year. On a 1 TB SSD, that is about 640 full-drive writes per year. Some consumer SSDs are rated around 600 TBW, so this could consume roughly a full drive's warranted write endurance in less than a year.
Thirty-seven terabytes in 21 days, from a local feedback log. Codex issue #28224 makes observability a consumable hardware budget, and a 1 TB consumer SSD can hit its 600-TBW warranty rating inside a year. There is a fix: three pull requests, with 0.142.0 shipping two and 0.143.0 carrying the third, reportedly cut this user’s logging by 85 percent. But a closed ticket only helps after you verify which Codex binary is writing to your disk. CI trust, but physical. If the tool can silently burn through SSD endurance, it’s already failed operational review before it writes a line of application code. Over on Hacker News:
Someone posted a temporary workaround for this on X. sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;" Also, I found that running VACUUM FULL on the sqlite file on my laptop shrunk it from 27GB to a mere 73MB.::
That Hacker News workaround blocks inserts with a SQLite trigger, and the 27-gigabyte-to-73-megabyte VACUUM result shows how much residue can be sitting around. Useful triage, but it disables the feedback log instead of fixing its accounting. From Hacker News:
Shocking. Been open a week and AFAICT just silence from OpenAI. I just find it baffling. You'd think that these vendors would be very sensitive to this sort of issue. I mean, surely they have multiple agents hooked up to github monitoring potential issues and proposing fixes, right?...right? Surely it should be trivial for them to have their own tools spinning away trying to fix all the github issues in real time...
For the record, the issue opened June 14, fixes merged June 23, and it’s closed now. Still, a GitHub ticket closing doesn’t give back the writes for anyone on a pre-0.142.0 install. Hacker News, weighing in:
Well, everyone's bashing on OpenAI as well they should, but just a reminder, unlike Claude Code, Codex is officially available to customize here: It's fairly easy to patch.
Sure, being able to patch Codex is better than waiting helplessly. But “easy to patch” isn’t much comfort when the defect is quietly wearing out laptops people use for work. DEV Community writes:
Prime Intellect's Prime Agent hit number one on GitHub Trending with 2,319 stars in a single day, and its design is the notable part: instead of stuffing a task into an ever-growing conversation, it hands the model a live Python session and lets it manage its own context as code. The repository now carries 11,400 stars and 4,480 commits, and ships under the MIT license.
Prime Agent is interesting because it skips the usual ritual of repeatedly summarizing itself into a smaller, blurrier version of the task. The model gets a persistent Python session and can search, slice, and store state as code instead. Eleven thousand four hundred stars is nice. A live interpreter where the agent writes its own context machinery is what makes my security team sit up—now context management has permissions, filesystem access, and failure modes. The Recursive Language Model idea from Alex Zhang’s 2025 paper makes sense for long tasks: keep the giant artifact outside the prompt, then pull only the relevant slice. But Prime Intellect’s ablations need to hold up on somebody else’s task distribution before 2,319 stars in a day counts as engineering evidence. After the Codex logging bug we just hit, I want resource accounting on that Python scaffold from day one. Persistent state is useful. It can also quietly chew disk, leak secrets, or mutate a workspace—and that’s how a clever architecture turns into an incident ticket. Kunal Ganglani, writing in DEV Community:
AI engineering evals testing regression gates is the unsexy discipline that keeps LLM apps from randomly breaking when you change a prompt, add a tool, refresh a RAG index, or your provider silently upgrades a model. Backend teams have lived in a world of CI gates for a decade. LLM teams are still shipping vibes.
DEV Community’s prescription is refreshingly boring: version your prompts and record golden tool traces. Then let CI fail the build. If a tool-call change can’t break a pipeline, it’ll eventually break somebody’s Friday deploy. That Bedrock change we just covered is the immediate test case. Sonnet 4.5 now preserves trailing newlines in tool parameters; a file writer that behaved yesterday may receive different bytes today, with no API-version ceremony around it. A golden trace would catch that. A developer clicking “looks fine” in a playground will catch it shortly after the patch mangles a config file. Keep retrieval separate from generation. When a RAG refresh misses the relevant document, grading only the final answer turns an index regression into another vague argument about model quality. Set a failure budget, shadow the change, and make the tradeoff visible before production does it for you. Got feedback, a story idea, or a correction? Email us at aicodingdaily at lantern podcasts dot com. Your notes help us make AI Coding Daily more useful.
We’re watching OpenAI Codex PR #29599, which is listed for release in 0.143.0.
Links to every story are in the show notes, so take a look at the ones you want to explore further.
That’s AI Coding Daily for today. This is a Lantern Podcast.