Plugin and MCP syncing now overlaps with startup or idle time under a timeout budget instead of blocking
What
- A new idle-time plugin refresh path races the plugin sync against the turn's remaining time budget; if the sync runs long, it still finishes afterward rather than being abandoned. This is controlled by the
tengu_ccr_plugin_refresh_in_idle_enabledsetting. - Startup can now kick off plugin sync in parallel with the message loop starting, tracked against a
remainingSyncBudgetMsderived from theCLAUDE_CODE_SYNC_PLUGIN_INSTALL_TIMEOUT_MSsetting, and flags when the sync outlives that budget. - The surrounding loop now also records timing telemetry (
first_message_handle_ms,first_message_handle_cpu_ms,first_message_handle_loop_lag_ms) to help track how these overlapping operations affect responsiveness.
Why
By letting plugin and MCP syncing happen alongside startup or idle time instead of blocking it, Claude Code can respond faster while still completing the sync in the background, with a budget so it doesn't take over indefinitely.
tengu_ccr_plugin_refresh_in_idle_enabled Not enough to sayNothing 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.277: off
These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
Read once, for one account on one subscription tier, against v2.1.277. It isn't a statement about your account. What a flag value here can and cannot tell you
No reading of the `tengu_ccr_plugin_refresh_in_idle_enabled` gate has been taken, so whether it is active is unknown.
New in this build: tengu_ccr_plugin_refresh_in_idle_enabled