Claude Code 2.1.239 is here—and the messy bugs are still telling the story. Before we get into today’s release, a little context: Novee Security showed that low-privilege GitHub issue input could steer default coding-agent harnesses around Claude Code, Gemini CLI, and Codex. That turns routine automation surfaces into a security-boundary problem. Claude Code has since shipped hardening releases, including v2.1.238 changes to plugin marketplace header helpers, self-hosted runner shutdown, proxy authorization controls, long-session memory growth, and prompt behavior. This is AI Coding Daily. Today, we’ve got a fresh Claude Code release and four bug reports that test whether the guardrails hold when a real repo gets weird. Let’s start with the release. Anthropic writes:
Cost estimates ( /cost, status line, --max-budget-usd ) now include the 1.1× US-only-inference premium for data-residency workspaces Added the one-time fullscreen renderer offer on Bedrock, Vertex, Foundry and other previously excluded setups; new installs there now start in fullscreen Added /claude-api upgrade to migrate Python projects from anthropic 0.x to 1.x, and updated the skill's Python reference for 1.x
Back to that harness-hardening story: Claude Code 2.1.239 now puts the 1.1-times US-only inference premium into /cost, the status line, and --max-budget-usd. If residency changes the bill, it belongs in the budget calculation. The Bedrock proxy fix matters more than the fullscreen default. A stripped Content-Type header could silently rerun every turn non-streaming and double the API bill. That’s an expensive header. There’s also a practical Python migration path: /claude-api upgrades anthropic 0.x projects to 1.x, including the timeout change to anthropic.Timeout. It’s a small patch note that could save a broken automation run. Plus HTTPS_PROXY now works through Bedrock SSO credential refresh. The agent can’t help with your legacy monorepo if it hangs before it reaches the first file. This one's from GitHub:
So a tool whose code is pinned in the memory — the one whose provenance you can actually prove — is the one that cannot use brokered credentials, and must read a token out of the inherited environment instead. That inverts the intended incentive: the safer authoring style gets the weaker credential story.
Areev’s code-carrying tools can live in a workflow, but Python, Node, MCP, and HTTP all hit RUN-E018 because only the CLI exposes --allow-executor. That puts the feature where agents are least likely to use it. It gets worse on credentials: CodeExecutor sets the tool name, hash, idempotency key, and executor URI, but skips the call that supplies AREEV_EGRESS_URL and AREEV_EGRESS_TOKEN. The pinned-code path ends up with weaker secret handling. So the workflow you can prove hasn’t been tampered with is the one told to inherit a token from its environment. That’s an impressively backwards reward system. Issue #87 is closed, but the engineering bar is simple: exercise both executor types through every binding, with credential grants on and off. A CLI smoke test won’t catch this. Anthropic, with kerneltoast:
What a user sees: a message sent to a background agent arrives and gets answered, but the answer never comes back. The agent writes its reply into its own transcript and stops; no task-notification is ever emitted for it; and the sender's SendMessage result looks exactly like the success case. Anything waiting on that notification waits forever.
Claude Code can deliver a subagent’s reply into its own transcript, then quietly drop the notification the orchestrator is waiting on. Kerneltoast lost two of five replies and the workflow froze. Spectacularly expensive silence. The nasty part of issue 88741 is that the SendMessage call still looks successful. A per-task notified flag suppresses the later notification, leaving only a debug log—so the caller gets no failure signal and no completion signal. And it was reproduced on Linux in 2.1.238, then re-checked unchanged in 2.1.239—the release we just discussed. If your agent orchestration depends on background replies, add a timeout and transcript-level verification before you trust it on a long run. “Has repro” is welcome, but an open race that turns a delivered answer into an invisible one is still a hard stop for unattended workflows. Here's anomalyco:
models.dev lists a provider's env vars in setup order, e.g. cloudflare-workers-ai: . The integration layer registers that list verbatim and connection resolution picks the first set var as the credential, so with the standard two-var setup the account id is sent as Authorization: Bearer → every request fails with Cloudflare's {"code":10000,"message":"Authentication error"}.
OpenCode issue #44065 comes down to config resolution: v2 takes the first populated environment variable and sends it as a Bearer token. For Cloudflare Workers AI, that means the account ID goes out instead of the API key. So the standard setup authenticates with its mailing address. Cloudflare returns 401, every prompt fails, and somebody gets to debug credentials that were perfectly valid. The same failure hits Snowflake Cortex, Databricks, and Neon too—account names, hosts, and gateway URLs can all come before the actual token. v1 already handled the Cloudflare case explicitly and refused to guess when several variables were set; v2 started guessing. And it’s present in both dev 1.18.21 and the v2 branch. A provider adapter that treats every env var as a possible secret needs tests for the boring two-variable setup before anyone calls that runner production-ready. Here's sashof at Anthropic:
Actual: ToolSearch finds no tool from the plugin; total_deferred_tools does not include it. Confirmed via direct reproduction: invoking the same bundled CLI binary manually with --plugin-dir (the invocation style Claude Desktop uses for CCD sessions, visible via ps) also fails to register any tool from the plugin — reproduced on both CLI 2.1.237 (bundled with Desktop) and 2.1.238 (standalone).
Claude Desktop’s CCD path loads marketplace plugins through --plugin-dir, then fails to resolve ${user_config.x} in the plugin’s env block. The same mcp-atlassian plugin works through enabledPlugins in ~/.claude/settings.json. That split comes from a configuration-path bug. And the symptom is beautifully useless: ToolSearch just finds nothing. Your Atlassian or GitLab tool vanishes, while the token you entered during install sits there wondering what it did wrong. The reporter reproduced it on Desktop’s bundled Claude Code 2.1.237 and standalone 2.1.238, using the exact --plugin-dir invocation visible in ps. Same failure through the desktop wrapper and the direct CLI path. Their workaround: a classic mcpServers entry with literal env values. Effective, sure—but a marketplace install that makes you rebuild its secret wiring by hand isn’t ready for a team laptop. If you’re enjoying AI Coding Daily, please subscribe and leave us a review wherever you’re listening. Reviews help other people discover the show, and we’re grateful you’re here.
You’ll find links to every story in the show notes, so check out the ones that caught your attention and dig a little deeper. Thanks for listening, and we’ll be back tomorrow. That’s it for AI Coding Daily today. This is a Lantern Podcast.