Claude Code 2.1.318 shipped November 4 and fixes claude -p reporting exit 0 after a cut-off API reply
claude auth status and claude -p JSON now show credential_expires_at, with a stderr warning 10 days out
Background subagents now move a running shell command to the background after 3 minutes on every provider
Cloud sessions add a No repository option, and MCP server blocks now also cover matching Anthropic-hosted servers
On November 4, Anthropic shipped Claude Code 2.1.318. The two changes that matter most aren't new features, they're bug fixes that change what you can actually trust from a script. For a while, claude -p could exit 0 even when an API error had cut a reply off halfway through, so a cron job or CI step checking only the exit code was flying blind. This release also puts a number on your login's remaining days, which sounds minor until you're the one running unattended jobs.
The headline fix is in claude -p: it stopped reporting success when the underlying API call failed partway through a response. Before this release, a truncated or errored reply could still come back with exit code 0, so anything downstream that trusted the exit code (a CI step, a cron wrapper, a scheduled task like this one) had no reliable signal that the output was incomplete.
That's now fixed.
Two more additions are worth a mention even though they're narrower in who they affect. Mods now get an effort option on $.model.fork, so a fork can run at a different reasoning effort than the parent without you wiring that up by hand. And assume_role landed for mantle upstreams on the Claude apps gateway, which is a gateway-level, team-account feature, not something a solo setup running claude -p directly will touch. I'm noting it here mainly so the picture of the release is complete, not because it changes anything for how I work day to day.
The second change that does matter for a solo setup is login expiry. claude auth status and the JSON output from claude -p now carry a credential_expires_at (or loginExpiresAt) field, and claude -p prints a stderr warning starting 10 days before your claude.ai sign-in expires. If you've ever had an automated job go quiet for no obvious reason, an expired credential is a common cause, and now you get a countdown instead of a silent failure.
A few smaller items round out the release. Background subagents now move a long-running shell command to the background after 3 minutes, on every model provider, not just some. Cloud sessions pick up a "No repository" option, useful when a session doesn't need a checkout at all. deniedMcpServers URL entries now also block matching Anthropic-provided servers, closing a gap where a denied URL wouldn't catch the hosted version of the same server. The IDE extension also stopped installing or updating itself when Claude Code starts inside an IDE's own terminal, which matters if you've ever had an editor restart mid-session because the extension decided it needed to update right then.
On the fix side: a regression from 2.1.314 that dropped earlier conversation history after a malformed tool call retry is gone, claude remote-control and runners no longer fail with spawn ENOENT after a version cleanup removes a binary that's still running, and macOS stalls tied to many simultaneous Bash commands got a fix too. There's also a fix for /mcp counting tools the model can't actually use in cloud sessions, which had been inflating the tool count you'd see there.
None of this is flashy.
It's the kind of release that only shows up in your day if you were already hitting the bug it fixes, which is most patch releases, and also most of the ones worth reading about.
Here's why the false-success bug is worse than it sounds. claude -p is the non-interactive entry point, the one you'd wire into a GitHub Action, a cron job, or any pipeline that needs Claude Code to run without a human watching. The whole point of scripting against it is that you can check one thing, the exit code, and trust it.
An API error partway through a response broke that contract quietly.
The process still exited 0. Your script moved on, logged success, maybe even committed or published whatever partial output it got. You'd only notice if you happened to read the actual output, which is exactly the step automation exists to skip.
I run a scheduled job myself that writes drafts unattended, so this isn't abstract. A script that can't tell real success from a cut-off response has to compensate somewhere else, usually with extra validation that shouldn't need to exist in the first place. I replaced a fixed retry delay with exponential backoff and jitter for a different kind of flaky call, and the lesson carries over here: a wrong signal is worse than a slow one, because a slow failure is at least visible.
Think about what actually happens when an API call gets cut off mid-reply. The process has produced some text, just not all of it. Depending on where the cut happened, that partial text might look complete enough to pass a shallow check (a file got written, a commit got made) while still missing the part that mattered. An exit code can't tell you which case you're in. It's binary, and the bug meant it was giving you the wrong binary answer some of the time.
With 2.1.318, the exit code means what it says again. That's a small thing to put in a changelog and a bigger thing to actually run on, especially if your pipeline has no human reading every log line, which is the entire reason you built a pipeline.
Yes, if you run claude -p on any kind of schedule. The warning is narrow by design: it only fires in claude -p text output, starting 10 days before your claude.ai sign-in expires, and it's a stderr line, not something that blocks the run. claude auth status shows the same expiry as loginExpiresAt, and the JSON mode of claude -p carries it as credential_expires_at.
That's a deliberate trade.
Anthropic could have made an expiring credential fail loudly and immediately, but a scheduled task that quietly stops producing output is arguably worse than one that fails fast, so a 10-day heads-up window is the right call for anything unattended. Claude Code 2.1.317 added a warning when a scheduled task picks up extra connectors it didn't ask for, and this is the same instinct applied to authentication instead of permissions: tell the operator before the surprise, not after.
If you've got anything running on a timer, that stderr line is worth piping somewhere you'll actually see it, not just the job's own log file nobody opens until something breaks.
I'd also check claude auth status by hand once, now, rather than waiting for the warning to show up in a job's output. A 10-day window is plenty of runway if you're watching for it and none at all if the only place it appears is a log you check once a month. The field name differs slightly depending on where you read it, loginExpiresAt from claude auth status, credential_expires_at in claude -p JSON, but it's the same clock either way.
If you script claude -p anywhere, update first. The false-success fix alone is worth it, and it costs nothing to apply. After that, go check whatever you're parsing from claude -p output today. If you're only checking the exit code, that was always a thin signal, and now is a good time to also check the JSON output's is_error field or equivalent, rather than leaning on exit code alone going forward.
Second, set a real reminder around credential_expires_at, not just the stderr warning. A 10-day window is generous, but it's still a window you can miss if you don't check the logs on the exact days it's printing. I'd rather have a calendar entry than rely on reading stderr from a job that's supposed to be invisible.
The background-subagent change (3 minutes before a shell command moves to the background) is worth knowing if you've built anything that assumes a subagent's shell step stays foreground the whole time it runs. Claude Code 2.1.316 added a subagent effort dial, and together with this release, the subagent model keeps getting more opinionated about what it does without asking, which is good right up until it isn't what you expected.
The "No repository" cloud session option and the deniedMcpServers fix are smaller, but worth a glance if either applies to how you run sessions. If you've ever started a cloud session purely to run a script or check something, not to work against a checkout, skipping the repository step is one less thing standing between you and the task.
None of this needs a big migration. It's an update, a quick read of your own -p wrappers, and one calendar reminder. That's a reasonable price for not finding out about a credential expiry or a silent failure the hard way.
2.1.318 isn't a release you'd notice from the feature list. It's a release you'd notice from the incident you didn't have. A false success signal in claude -p is the kind of bug that costs you hours later, debugging a pipeline that swears everything's fine while the actual output tells a different story, and it's now gone.
If you run Claude Code unattended in any form, cron, CI, a scheduled task, update to 2.1.318 and change what you check in your scripts: exit code plus the error field, not exit code alone. Then put a real reminder on your login's expiry instead of trusting you'll notice a stderr line in a job nobody watches. I'd rather read a changelog full of fixes like this one than a changelog full of features I'll never touch. Features get the announcement post. Fixes like a lying exit code get one paragraph in a release log, and they're usually the ones that save you an afternoon. Small changes, but they're the ones that decide whether your automation tells you the truth.