[FEATURE] Require full typing or confirmation for /clear to prevent accidental context loss

Resolved 💬 4 comments Opened Mar 30, 2026 by gitpushoriginmaster Closed May 3, 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

/clear is the most destructive built-in command in Claude Code — it permanently and irreversibly destroys all conversation context with zero confirmation. Yet it is among the easiest commands to trigger accidentally, because the slash command autocomplete allows prefix matching.

Typing /c + Enter (or Tab + Enter) can resolve to /clear through the autocomplete menu, even when the user intended /commit, /compact, /config, /cost, or /context. A single misplaced keystroke in the command picker wipes out an entire session.

This is a sharp asymmetry: the command with the highest blast radius has the lowest invocation friction.

As noted by a commenter on #39975:

"A huge problem is that when users are typing /context the selector highlights /compact [...] and then /clear is right between /context and /compact so if you are one keystroke off when navigating up to the intended slash command you wipe out your whole session"

While #39975 proposes a recovery mechanism (/unclear), prevention is better than recovery. A user who accidentally clears a 45-minute deep-context session shouldn't have to rely on a restore feature — the accident shouldn't happen in the first place.

Proposed Solution

Implement one or more of the following (in order of preference):

  1. Exclude /clear from autocomplete entirely. Require the user to type /clear in full and press Enter. It would not appear in the fuzzy-match dropdown when typing /c, /cl, etc. This is the simplest and safest option — destructive commands should not be one Tab away.
  1. Add a confirmation prompt before /clear executes. Something like: Clear all conversation context? This cannot be undone. [y/N]. This protects against both autocomplete accidents and intentional-but-regretted invocations.
  1. At minimum, deprioritize /clear in the autocomplete ranking. If autocomplete exclusion is considered too restrictive, at least ensure /clear is never the first match for any prefix. For example, /c should default to /compact or /commit, not /clear.

These approaches are not mutually exclusive — option 1 + option 2 together would be the most robust.

Alternative Solutions

  • /unclear (undo): Proposed in #39975. Complementary but not a substitute — prevention and recovery serve different purposes. Users shouldn't have to "undo" an action that should have been harder to trigger.
  • Keybinding instead of slash command: Make /clear only accessible via a deliberate keyboard shortcut (e.g., Ctrl+Shift+K) rather than the slash command menu.

Priority

Medium - Important quality of life improvement

Feature Category

Interactive mode (TUI)

Use Case Example

  1. User is deep into a complex multi-file refactor, 30+ minutes of accumulated context
  2. User types /c intending to run /compact to free up context space
  3. Autocomplete resolves to /clear (either as the default selection or one arrow-key off)
  4. User presses Enter
  5. Entire session context is permanently destroyed
  6. No confirmation was shown, no undo is available

With this fix: /clear either doesn't appear in autocomplete (user must type it in full) or a confirmation prompt catches the mistake before it executes.

Additional Context

This is a defense-in-depth request. The general principle — destructive operations should require proportional confirmation — is a well-established UX pattern. rm has -i, git has reflog, databases have transactions. /clear currently has nothing.

Related: #39975 (proposes /unclear as a recovery mechanism)

View original on GitHub ↗

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