Your agent says it spawned. Do you believe it? New to this story? Here’s where we are. Claude Code’s agent harness has been under scrutiny after Novee Security’s default-harness findings, Anthropic’s restricted-mode hardening, and Hermes Agent reports that provider errors could reach model context. The latest Claude Code release, v2.1.252, fixed Mac Bash task-output failures, always-allow persistence, Remote Control stalls, and those noisy oversized background-task notifications. This is AI Coding Daily. Today, the controls are changing—but can the orchestration layer prove anything actually ran? Let’s start with Claude Code. This story isn't over: Coding-agent harness security. Follow us wherever you're listening, and the next chapter comes to you. This one's from Anthropic:
What's changed Added Claude Fable 5.1 ( claude-fable-5-1 ), now the default Fable model — 1M context, $10/$50 per Mtok with $0.25/Mtok cache reads Added "Time format" ( timeFormat ) and timeZone settings: 12-hour, 24-hour, 24-hour UTC, or a strftime pattern for the turn-end clock and transcript-view timestamps Added a Containment Escape rule to auto mode so cloud metadata-credential fetches, egress evasion, and cross-tenant reach are no longer auto-approved unless your environment marks them expected
Update on the Claude Code harness-security thread: v2.1.257 closes off auto-approvals for containment escape and reads outside the working directory. Cloud metadata fetches, egress evasion, and cross-tenant reach now need to be explicitly expected by the environment. Which means auto mode previously had a path to approve an agent reaching for cloud credentials. That deserves more than a changelog bullet; teams should ask what their auto-mode sessions were allowed to attempt before September 1. Fable 5.1 is now the default, too: one million tokens, with pricing stated plainly—$10 input, $50 output per million tokens, and $0.25 cache reads. Good. A million-token model without a visible cost curve is a budget incident waiting to happen. And run /doctor after the update. It now warns about stale sandbox mask files from killed sessions—exactly the sort of leftover state that turns a clean policy on paper into a strange Tuesday in CI. This one's from GitHub:
async_delegation results delivered via the api_server wake self-post can duplicate concurrent turns on one session, delay results by 10–40 minutes, or drop them entirely on loaded boxes. The client-side timeout aborts only the caller; the server-side turn keeps running, and the retry re-posts onto a session that (per the code's own comment) has no per-session lock.
Hermes Agent has a 600-second client timeout, then retries that same wake into a session its own code says has no per-session lock. So the first turn may still be running while attempt two barges in and overwrites it. Issue #100689 measured this on four production boxes: at roughly 218 to 252K tokens, one delivery took 39.8 minutes on its fourth attempt. A timeout here doesn’t mean the work failed; it just stops the caller from seeing work that’s still happening. And it can do that up to four times for one finished background task—duplicate concurrent turns, then maybe no result at all. Put that behind a financial workflow and your audit trail becomes a guess with timestamps. We just discussed a default model with a one-million-token window. Hermes shows why capacity claims need an orchestration budget alongside them. If a wake turn can run past ten minutes, you need session serialization and completion telemetry as a baseline. cciordas, writing in Anthropic:
Subagents spawned via the Agent tool (custom agent types from .claude/agents/*.md) died silently at startup: the Agent tool returned "Spawned successfully", but the child process exited within seconds-to-minutes, wrote no transcript file, produced no output, sent no failure signal to the orchestrating session, and left no log artifact anywhere.
Issue #91298 is a nasty contract breach: Claude Code says a custom subagent spawned successfully, then the process dies and leaves no transcript, error, log, or notification. In the repro, that happened four for four over roughly five hours on Linux. “Spawned successfully,” followed by “go check ps,” is not a status API. It’s a scavenger hunt. And those two reviewer agents were still listed as teammates after their processes were gone. We just covered v2.1.257 adding containment controls in auto mode. Good—limit what a subagent can do. But the parent still needs to know whether that subagent ever ran. Right now, the orchestration layer can claim success without verifying it. Put this beside the Hermes delegation failure: separate codebases, same shape. The coordinator reports a healthy handoff while the work is dead, duplicated, or lost. CI can review a diff; it can’t review work that vanished before it wrote one. Here's GitHub:
A Sites project cannot be published because create_source_repository_write_credential returns a source write credential whose token_expires_at is already in the past when it is issued. Git push then fails with: 403 Invalid or expired token.
Codex Sites hands you a write credential that’s already expired, then Git correctly throws a 403. That’s a deploy path where the failure arrives preinstalled. The reporter checked local time, re-authenticated through the ChatGPT desktop app, and got the same result. That points upstream: credential issuance needs to validate its own expiry before returning success. And after Hermes duplicate turns and Claude subagents declaring victory before dying, here’s the third contract failure: the API says, “write access granted,” while the credential is already expired. Excellent way to make every publish pipeline look haunted. Issue #42119 is labeled bug, auth, and app—accurate, but operationally incomplete. A short-lived credential is only useful if it survives long enough for the first Git push. Anthropic writes:
Cowork sessions cannot reach a connected local folder. Every remote-devices tool call (device_bash, device_list_dir, get_device_info) fails with: "The device this session is bound to is not connected to the bridge." Reproduced 6 times over 11 minutes with no auto-recovery, despite the error text promising recovery "within a few seconds."
Another Claude Code failure with no usable telemetry: on Windows 1.40609.0.0, Cowork’s device bridge never initializes, and every healthy startup marker appears exactly zero times. Main.log keeps writing for 30 more minutes, so logging is alive; this subsystem simply never comes up. And Cowork tells the user the device will reconnect "within a few seconds." The reporter ran it six times across 11 minutes with no recovery, then found there is no fallback execution mode for that connected local folder. That’s a dead-end workflow with an optimistic error string taped over it. We just covered a subagent reporting "Spawned successfully" after dying at startup. Here, the bridge reports a recoverable disconnect when the bridge process apparently never started. Different surface, same problem: the status text doesn’t match the observable process state. "Has repro," platform:windows, area:cowork — good. Now Anthropic needs to make bridge initialization observable before asking anyone to trust that recovery promise. A desktop update turning months-old projects into inaccessible folders is the sort of regression a release gate is supposed to catch. Have feedback, a story idea, or a correction? Email us at aicodingdaily at lantern podcasts dot com. Your notes help make AI Coding Daily more useful.
Links to every story we covered are in the show notes. Read more on the ones that caught your attention. Thanks for listening—we’ll be back tomorrow. That’s AI Coding Daily for today. This is a Lantern Podcast.