[FEATURE] Apply plugin auto-updates automatically when the session has no user turns yet

Status Open
Reported on v2.1.268
Maintainer reply None cached
Activity 0 comments · opened Sep 11, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Plugin auto-update runs in the background after session start (with a random delay of up to ten minutes). If anything was updated, the session shows a notification asking me to run /reload-plugins, because the running session is still using the versions it loaded at launch.

The reload is deferred rather than applied because it can invalidate the prompt cache. That reasoning holds mid-conversation. It does not hold when the update lands before I have sent a single message: there is no conversation history to re-read, so the cache cost of reloading is zero. In that window the notification is pure friction — the only correct response to it is to type a command, and typing that command costs nothing.

In practice a large share of these notifications arrive in exactly that window, since the updater fires shortly after launch and people often start a session a little before they start working.

Proposed Solution

When the auto-updater finishes and finds updated plugins, apply the reload automatically instead of notifying, if all of the following hold:

  • the session has processed zero user turns (no prompt_id has existed yet)
  • the session is interactive with a TTY
  • no turn is in flight

Otherwise, keep the current notification behaviour unchanged.

Surface it afterwards as an informational line rather than a call to action, e.g. Plugins updated and reloaded: 3 plugins · 12 skills.

A setting such as autoReloadPluginsBeforeFirstTurn (default on) would let people who want the current behaviour keep it.

Alternative Solutions

  • Wrapping claude in a shell function that runs claude plugin marketplace update / claude plugin update before exec'ing the binary. Works, but requires iterating claude plugin list --json since claude plugin update takes one plugin at a time, and every user has to build it themselves.
  • A SessionStart hook doing the update. Doesn't help the current session — plugins are already loaded by the time SessionStart fires — so it always leaves you one session behind.
  • Disabling auto-update per marketplace, which trades the notification for stale plugins.
  • #10265 (closed) proposed auto-update plus an automatic session restart. This request is narrower: no restart, no process lifecycle change, just applying a reload that is already free at that moment.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Our team distributes internal tooling through an org marketplace with autoUpdate enabled in managed settings. Plugin authors publish frequently, so most sessions open, get an update, and show the banner before anyone has typed anything. Every developer pays the same pointless keystroke several times a day, and the ones who ignore the banner silently run stale skills.

Additional Context

Possibly related:

  • #79776 — versionless official plugins are force-reinstalled on every refresh and trigger this notification even when nothing actually changed. Fixing that reduces the frequency; it doesn't remove the friction for real updates.
  • #24057 — a broader request for MCP servers, hooks and plugins to auto-reload on config change. This request is scoped to the one window where a reload is provably free.

Environment:

  • Claude Code version: 2.1.268
  • OS: macOS 26.6.2 (arm64)
  • Install method: Homebrew cask (claude-code@latest)

---

🤖 Drafted with Claude Code.

View original on GitHub ↗