Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.248 ·

The background daemon defers restarts and idle exits while an upgrade is pending

The background service waits for your turn to finish before restarting for an upgrade.

You'll notice Improvements
JSON All of v2.1.248
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
Background DaemonArea: what it touches
ImprovementsKind: in v2.1.248,
ImprovementsSection of the release
What

The long-running background service that supervises Claude Code worker sessions now handles binary upgrades without cutting anyone off. When a newer binary appears, it holds off restarting while any worker is mid-turn, re-checking on each poll for up to 30 minutes before restarting anyway, and its idle timer reschedules itself rather than shutting the service down while an upgrade is in flight. Shutdown paths now record why the service stopped, and the control socket reports upgrade state to callers.

Details
  • Deferral of the restart is on when the server sends no config: the tengu_daemon_upgrade_defer_busy flag has a compiled fallback of true.
  • Workers report their busy state to the supervisor over the inter-process channel as { type: "rc_busy", busy: g }, and the supervisor tracks when each last reported plus a running count of busy workers.
  • The wait cap is an option defaulting to 1800000 ms (30 minutes) and appears in the log as capped at ${Math.round(T / 60000)}m.
  • Deferral is abandoned early if the new binary reverts to the old one, the daemon is already shutting down, or the poll itself errors.
  • A tengu_daemon_upgrade_deferred_busy event records the busy worker count, how long the restart was deferred, whether the cap expired, and the phase it was in.
  • Shutdown reports a cause of either "upgrade" or "yield", with "upgrade" only reported when the daemon was not also displaced by another instance taking over.
  • The previously scattered shutdown checks collapse into one predicate driving the shutting-down state.
  • The control-socket nudge returns a restarting flag and an upgrade-pending flag instead of the single boolean it returned before.
Evidence

binary at ${W} changed but ${be} registry worker(s) report a mid-turn session, tengu_daemon_upgrade_deferred_busy, onNudge: async () => ({

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Read from
Feature flag
tengu_daemon_upgrade_defer_busy Not enough to say

Nothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.

This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.248: on

Read once, for one account on one subscription tier, against v2.1.248. It isn't a statement about your account. What a flag value here can and cannot tell you

How sure we are
One source agreesOne thing we can check says the same as this entry.
The name it cites is new in this buildNew in this build: tengu_daemon_upgrade_defer_busy

See this entry in the whole of v2.1.248 →

Feedback