[FEATURE] Built-in update notification for Claude Code

Resolved 💬 3 comments Opened Apr 17, 2026 by Steve-Naumann Closed May 27, 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

When Claude Code's CLI or the underlying model is updated, behavior can shift noticeably (different reasoning, different
interpretation of context, sometimes regressions in complex projects). Users often don't realize anything changed — they just
notice "Claude feels different today" and waste time debugging what turns out to be either a CLI update or a model version
change.

Two distinct events cause this, both invisible to the user:

  • Claude Code CLI auto-updates (e.g., 2.1.100 → 2.1.113)
  • Underlying model rollouts (e.g., Opus 4.6 → 4.7)

This is especially painful for:

  • Long-running projects where reproducibility matters
  • Teams where multiple people use Claude Code
  • Training/seminar contexts (I run trainings for web agencies and need to prepare participants for this)
  • Anyone building workflows on top of specific model or tooling behavior

Proposed Solution

A built-in, one-time notice at session start when either the CLI version or the active model version has changed since the
last session:

  • Old version → new version (separate lines for CLI and model if both changed)
  • Brief note that behavior may have shifted
  • Link to release notes / changelog
  • Pointer to /fast (faster previous version) and /model (version picker) as fallback options
  • Dismissable, opt-out via settings

A native implementation has a key advantage over user-land workarounds: it can detect the model change at the moment of the
session that uses the new model — not one session late (see workaround limitation below).

Alternative Solutions

Built a SessionStart hook as a workaround (~/.claude/hooks/check-version.sh) that detects both CLI and model changes:

#!/usr/bin/env bash                                                                                                           
# CLI version                                                                                                                 
CLI_CURRENT=$(claude --version 2>/dev/null || echo "")    
CLI_LAST_FILE="$HOME/.claude/.last-version"                                                                                   
CLI_LAST=$(cat "$CLI_LAST_FILE" 2>/dev/null || echo "")
                                                                                                                              
LATEST_JSONL=$(find "$HOME/.claude/projects" -type f -name "*.jsonl" -exec stat -f "%m %N" {} \; 2>/dev/null | sort -rn | head
 -1 | cut -d' ' -f2-)                                                                                                         
MODEL_CURRENT=""                                                                                                              
if [ -n "$LATEST_JSONL" ] && [ -f "$LATEST_JSONL" ]; then 
  MODEL_CURRENT=$(tail -r "$LATEST_JSONL" 2>/dev/null | grep -o '"model":"[^"]*"' | head -1 | sed 's/"model":"\(.*\)"/\1/')   
fi                                                                                                                         
MODEL_LAST_FILE="$HOME/.claude/.last-model"                                                                                   
MODEL_LAST=$(cat "$MODEL_LAST_FILE" 2>/dev/null || echo "")
                                                                                                                              
CLI_CHANGED=false; MODEL_CHANGED=false                    
[ -n "$CLI_CURRENT" ] && [ -n "$CLI_LAST" ] && [ "$CLI_CURRENT" != "$CLI_LAST" ] && CLI_CHANGED=true                          
[ -n "$MODEL_CURRENT" ] && [ -n "$MODEL_LAST" ] && [ "$MODEL_CURRENT" != "$MODEL_LAST" ] && MODEL_CHANGED=true
                                                                                                                              
[ -n "$CLI_CURRENT" ] && echo "$CLI_CURRENT" > "$CLI_LAST_FILE"                                                               
[ -n "$MODEL_CURRENT" ] && echo "$MODEL_CURRENT" > "$MODEL_LAST_FILE"                                                         
                                                                                                                              
if [ "$CLI_CHANGED" = true ] || [ "$MODEL_CHANGED" = true ]; then                                                             
  MSG="Change detected:"                                         
  [ "$CLI_CHANGED" = true ] && MSG="$MSG CLI: $CLI_LAST → $CLI_CURRENT."                                                      
  [ "$MODEL_CHANGED" = true ] && MSG="$MSG Model: $MODEL_LAST → $MODEL_CURRENT."                                              
  MSG="$MSG Behavior may have shifted. /fast falls back to faster previous version, /model switches model."                                                         
  jq -n --arg msg "$MSG" '{systemMessage: $msg}'                                                                              
fi                                                                                                                            

Known limitation of this workaround: Model detection reads the newest JSONL transcript and compares against a stored
last-known model. This means a new model ID is only detected on the second session after the rollout — the first session
with the new model has no transcript yet at hook time. A native implementation inside Claude Code could check the live model
ID at session start and warn immediately.

Wired into ~/.claude/settings.json as a SessionStart hook. Every user has to DIY this — it should be standard.``

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Scenario: I run Claude Code trainings for web agencies in Germany. Recently the Opus model rolled from 4.6 to 4.7. A
participant's complex WordPress project suddenly "felt worse" — Claude was misinterpreting context in ways it hadn't before.
They spent 30 minutes assuming they'd broken something in their setup, until we realized the model had changed server-side.

With a built-in notice on CLI or model version change, they would have immediately known: "Oh, new model version — let me
double-check and maybe try /fast if something feels off." Saved 30 minutes of confusion and built trust in the tool.

Same applies to teams: one developer updates, others don't, and suddenly they get inconsistent results without understanding
why. A silent server-side model rollout makes this even worse because there's no local event to point to.

Ideal flow:

  1. User starts Claude Code
  2. Claude Code detects: CLI version bumped since last session, OR active model ID differs from last known
  3. One-time notice: "Claude Code CLI: 2.1.100 → 2.1.113" or "Model: Opus 4.6 → 4.7. Behavior may have shifted. /fast falls

back to previous version, /model switches model."

  1. Dismissable, doesn't reappear until next change

Additional Context

Two technical notes:

  1. CLI version detection is trivial (already shown in my workaround). Model version detection is easy for Claude Code since it

knows which model ID is active — just compare against a locally cached last-known-model.

  1. The two events are independent and both matter. A CLI update changes tooling/prompts; a model update changes reasoning.

Users benefit from awareness of both.

  1. Happy to help refine the UX or contribute to implementation. The real design work is picking the display pattern (banner?

system message? inline notice?) and making it non-intrusive.

Thanks for building such a great tool!

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗