claude-code - 💡(How to fix) Fix /clear-to function. [1 participants]

Preflight Checklist

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

Problem Statement

/clear is too destructive. It causes total loss of all context including identity and purpose startup instructions needed for Claude to serve its purpose. But not clearing at all will lead to ever increasing drift potential. the solution is a simple as it is effective. please see below.

Proposed Solution

From Claude and me:

▎ /clear is too destructive. Clear nothing, and drift accumulates. There is no middle ground — and there should be.

---

The Problem

In long working sessions, context accumulates. This causes model drift — not because the model forgets its identity, but because the weight of accumulated task history pulls responses away from their baseline behavior. The longer the session, the worse it gets.

The current options are:

• /clear — wipes everything, including system identity. You pay a full reload cost and lose your grounding. For workflow-heavy applications this is a full stop.
• Do nothing — drift accumulates unchecked.

Neither is acceptable for professional, long-session use.

The Request

A /clear-to command that rolls context back to a defined checkpoint — specifically, to the point immediately after system prompt injection, before any task history accumulated.

Behavior:

• Clears all user/assistant turns after the checkpoint
• Preserves system prompt and identity context
• User lands back at a known clean state, ready for the next command
• Zero reload cost — the core identity is already loaded

Why This Matters

Any workflow-heavy, long-session Claude Code user hits this problem. The pattern is the same across domains:

• A developer mid-refactor who wants a clean reasoning slate without losing project context
• A researcher running sequential experiments who doesn't want prior results influencing analysis
• An operator running discrete, stateless operations where each command should be independent
• Anyone whose work is naturally task-by-task — each action complete in itself, with no business bleeding into the next

The model's identity and rules are static. The task history is ephemeral. Right now there's no way to treat them differently. /clear-to makes that distinction structural.

The Core Insight

System prompt = who I am. Conversation history = what I've been doing. These are not the same thing and should not be coupled. Today they are, which means the only way to reset one is to lose both.

Summary

/clear-to = clear task context, preserve identity. Small feature, broad impact. The alternative — drift — silently degrades every long session today, for every serious Claude Code user.

Alternative Solutions

N/A

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

Real-World Use Case

We are controlling lighting consoles.

Each operator command — patch a fixture, create a group, record a palette — is a discrete, stateless operation. The console doesn't care what the previous command was. Claude shouldn't either.

In a typical session an operator might run 30–50 discrete commands over 2–3 hours. By command 30, the accumulated context of the previous 29 operations is actively working against performance. Claude begins drawing on prior task context when it shouldn't — referencing fixtures from a patching operation while working on a palette, carrying assumptions from a group creation into a completely unrelated deletion. The console never does this. Claude shouldn't either.

What the operator needs is simple: when a command completes, that context is gone. The next command starts clean. Claude still knows who it is, what the rules are, and what console it's talking to — but it has no memory of the last operation. Every command gets the same fresh, focused reasoning.

/clear-to would make this possible without a full session reload. The operator never breaks stride. The session never drifts.

Additional Context

Two prior requests (#21776, #16659) explored similar territory but were closed without implementation. This submission attempts a cleaner, user-facing framing of the same underlying need — a named command with explicit preserve/clear semantics, rather than a hook flag or internal mechanism.

The stateless operation pattern is not domain-specific. Any tool-heavy Claude Code workflow faces the same issue: each tool call is discrete, the accumulated history of prior tool calls is noise. The drift problem scales with session length, not with use case.

Finally, this is a token efficiency argument as much as a UX one. Shorter effective context means faster inference and lower cost per operation. /clear-to benefits Anthropic's infrastructure as much as it benefits the user.