One vendor patched a session-bricking failure. The other is still trying to explain why long runs keep falling over. If you're just joining us, here's where this stands. Claude Code hardening has been moving on two tracks: researchers and users finding ways harness behavior leaks or hides important state, and Anthropic shipping small releases that make those failures louder. Before this release, that included Novee Security's default-harness findings, a Hermes Agent report where backend provider errors reached model context verbatim, and Claude Code v2.1.246 adding permission warnings and explicit interrupted-MCP-call errors. This is AI Coding Daily. Today: one fix for a bricked session, and a much less comfortable question about whether a GPT-5.6 regression that's now seven days old is getting worse. First, Claude Code. We're staying with this story: Coding-agent harness security. Follow the show and you won't miss what comes next. From Anthropic:
Fixed sub-agents dying on a first-call model 404: they now use the session's fallback model chain, and the error returned to the parent includes the error type, status, request id, and model Fixed a hook or background agent that printed megabytes of error output being able to overflow the conversation and wedge the session on "Prompt is too long"
Claude Code v2.1.247 closes one ugly path to wedged sessions and adds fallback fixes. A hook dumping megabytes of errors could overflow context and strand you on “Prompt is too long”; now it can't take the whole session down with it. That is a properly grim bug: your background helper throws a tantrum, prints a novel, and bricks the engineer's workspace. Glad it's fixed—because “restart everything and hope” is not an incident-response plan. The 404 handling is more useful than it sounds. Sub-agents now follow the session fallback chain, then return the error type, status, request ID, and model to the parent. That gives a long task a traceable failure signal instead of a silent model swap. And /claude-api cost-optimize walks through caching, token hygiene, batch, effort, and model choice—one measured change at a time. Good. If the tool says it saved money, I want the lever and the before-and-after—not a cheerful spinner tip. This one's from OpenAI:
I am adding another structured update because the GPT-5.6 Sol problems affecting my workflow have now continued for approximately seven days, and today I encountered another serious failure mode. I want to keep this post factual, respectful, and technically focused.
OpenAI shipped a routing fix for the reported 3% Pro-and-Thinking case, and GPT-5.6 Sol on Extra High is still freezing at “Thinking” in fresh chats. One fix landed while a different subsystem is still broken. The August 26 report is unusually disciplined. It pins this to seven days on ChatGPT Pro, GPT-5.6 Sol, High and Extra High, iPadOS 26.6.1, and Chrome 152—and documents failures across long context, file work, execution, and the Activity sidebar. Those may be separate root causes, but the workflow is still unavailable. An inaccessible Activity sidebar is annoying. Extra High stalling before it produces anything is worse: you can't inspect the work because there isn't any. For a 20,000-word, file-backed project, that's a parked car with the engine light on. And the fresh-conversation detail matters. You can't wave this away as one overloaded legacy thread when the same class of failure shows up before the session has any history. From krasnik at OpenAI Developer Community:
Why did ordinary ChatGPT on this Plus account previously receive the durablewfr_/ SAServer / per-turn worker execution family, while current ordinary Chat is returned as non-Temporal/foreground and current Work on the same account still receives the worker family? Is this expected product behavior, a rollout/experiment, an account-treatment problem, or a regression?
Same Plus account, same GPT-5.6 High: ordinary Chat used to run 102 minutes and 26 seconds; now it repeatedly dies around 25 or 26. Meanwhile, Work still gets the long-run worker handoff. That routing difference comes with a stopwatch attached. The Developer Community report preserves metadata, HAR copies, request IDs, and a same-conversation route-flip chronology. OpenAI needs to say whether foreground execution for ordinary Chat is deliberate product treatment, an experiment, or a regression. And if Work can hand off to a durable worker while Chat gets a 26-minute foreground timer, users are being sorted into execution classes they can't see. Great way to discover your agent's runtime budget: watch it stop halfway through the refactor. The acknowledged Sol routing fix left fresh Extra High failures behind. This report narrows the reliability question further: the model can be identical, while the execution path cuts a usable job from more than 100 minutes to less than half an hour. Here's Riley Li at DEV Community:
The failure had nothing to do with the free server, and everything to do with two assumptions I had baked into my harness. I moved a small LLM batch pipeline to MonkeyCode's free server to cut costs, and within an hour the same prompts that worked on a paid endpoint started returning empty completions and hanging requests.
Forty requests in, the endpoint starts serving HTTP 200 with an empty content field, then hangs for exactly 30 seconds. Congratulations: your monitoring says green while your batch job quietly turns into decorative software. The useful part is the 40-line probe: hold the prompt constant, vary only input length, and record status, latency, and whether the expected token arrived. The author found the break around 10,000 characters and timeout behavior nearer 20,000—numbers a harness can actually enforce. And the free endpoint wasn't the whole diagnosis. A context overflow produced the empty 200s; a dead keep-alive connection produced the 30-second ReadTimeouts. Two separate failures, one extremely misleading success code. That also echoes the Claude Code overflow patch we just covered: agent-side safeguards matter, but callers still need to reject empty success responses and budget context before they hit the cliff. This one's from DEV Community:
A developer asks a free coding model to refactor a service in twelve steps. Steps one through three pass cleanly. By step five, the model renames a function that was already renamed. By step seven, it reintroduces a deleted dependency. The model did not get dumber. It lost context. This is context drift. It is the silent killer of long AI-assisted refactors.
This DEV post earns attention because it makes drift testable: twelve dependent refactor steps, pass/fail constraints, token use, and wall-clock time. I'd want to see its full-history prompting versus reasoning-ledger eval run against any agent claiming it can handle a real migration. Step five: it renames a function that was already renamed. Step seven: a deleted dependency rises from the grave. That's a 50-file refactor failure, just with a nice twelve-step receipt attached. The ledger is a controlled compression strategy, not magic memory. The useful next measurement is whether the agent preserves the same model and fallback chain across all twelve steps—because a silent model swap can look exactly like context drift. The flaky-pipeline post we just hit found trouble around ten thousand characters and timeouts near twenty thousand. So, sure, send the whole history—until the endpoint taps out. A ledger gives you something inspectable when the token budget turns into a trap. Have feedback, story ideas, or a correction for AI Coding Daily? Email us at aicodingdaily at lantern podcasts dot com. We'd love to hear from you.
Links to every story are in the show notes, so take a look at the ones that caught your attention and follow the threads further. Thanks for listening to AI Coding Daily—back with you tomorrow. This is a Lantern Podcast.