[BUG] Persistent bottom-right notifications ("Update installed · Restart to update") replace the context meter instead of coexisting with it

Status Open
Reported on v2.1.236
Maintainer reply None cached
Activity 0 comments · opened Aug 20, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

The bottom-right slot of the TUI is where the context meter lives (615148 tokens-style remaining-context readout). Notifications are rendered in the same slot, replacing the meter rather than coexisting with it:

  1. Update notificationcurrent: 2.1.236 · latest: 2.1.237 ✓ Update installed · Restart to update. This one is persistent: it stays until the session is restarted. In a long-running session that means the context meter is invisible for hours, exactly in the kind of session where you most need to watch it. The notification carries no context information at all, yet it evicts the one readout that does.
  2. Context-low notificationContext low (0% remaining) · Run /compact to compact & continue also takes over the slot. This one is less harmful (it at least carries the remaining-context information itself), but it shows the same design pattern: notifications and the meter compete for one slot.

Real incident where this amplified another bug: during a session running with the update notification covering the meter, the model confidently misreported its own context headroom (the default totalTokensReminder issue, #88211 — "14.99M of 15M left" moments before the session died at the 1M limit). The user, who normally cross-checks against the meter, could not — the meter had been replaced by the update notification for hours. The notification design turned a model-side misreport into an operator-side misjudgment. The meter is the only ground truth the human has; covering it with a restart reminder removes the safety net exactly when it matters.

What Should Happen?

Any of these would fix it (in order of preference):

  1. Never let notifications evict the context meter — render them on a separate line / left side, or attach them next to the meter instead of replacing it.
  2. If the slot must be shared, make non-informational notifications transient (auto-dismiss after a few seconds, or alternate with the meter), instead of persisting until restart.
  3. At minimum, keep the meter visible while the update notification is shown (the update hint could move to /status or the input-area hints line).

Steps to Reproduce

  1. Run a session on a version where an update is available; let the auto-update install (✓ Update installed · Restart to update appears bottom-right).
  2. Keep working without restarting (normal during a long task — restarting kills the session's running background agents).
  3. The context meter is gone for the rest of the session; the only remaining-context signal is the model's own (unreliable, see #88211) self-report, until the Context low notification takes the slot over at the very end.

Environment

  • Claude Code version: 2.1.236 (update banner observed for 2.1.237)
  • Platform: Anthropic API
  • Operating System: Ubuntu/Debian Linux (container)
  • Terminal: iTerm2

Related

  • #88211 — the model-side context misreport this UI behavior amplified (same incident)
  • #83998 — adjacent: the update notification's restart action lacking a confirm; this report is about the notification's placement, not its action

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

View original on GitHub ↗