Kimi-Claw Bug: Some Sessions Reset Immediately After a User Sends a Question

A newly reported OpenClaw bug suggests that some kimi-claw conversations can reset immediately after a user asks a normal question.

The visible symptom is unusually specific: instead of continuing the current conversation, the session responds as if /new or /reset had just been triggered, and the agent starts over from scratch.

Source:

• Issue report: openclaw/openclaw#57834

What the failure looks like

According to the issue report:

• a user starts a session in the kimi-claw channel
• the user sends a normal question
• the session immediately resets
• the UI/message stream shows: “A new session was started via /new or /reset”
• recent context is lost, so the agent has to rebuild state from the beginning

That makes this more than a cosmetic UX bug. It breaks the core promise of a chat session: continuity across turns.

Why this matters operationally

If this issue is real in your environment, the blast radius is bigger than “the answer was bad”:

1. Recent task context disappears

   • ongoing debugging, planning, or drafting work can collapse after each turn.

2. Users may misdiagnose it as model instability

   • the visible failure looks like memory loss, but the actual bug may sit in session lifecycle handling, channel routing, or slash-command interpretation.

3. Rework cost grows fast

   • if users must restate context every turn, throughput drops sharply even when the gateway itself stays online.

How to confirm you are hitting the same bug

You are likely seeing the same regression if all of these line up:

• the problem happens specifically in the kimi-claw channel
• the trigger is a normal user question, not an intentional /new or /reset
• the session message explicitly says a new session was started
• the same conversation cannot preserve state across turns

A simple verification loop:

1. Start a fresh kimi-claw session.
2. Send a short factual prompt such as: Remember the word ORBIT.
3. Send a second prompt: What word did I just ask you to remember?
4. If the second turn causes a reset banner or the session restarts instead of answering normally, you are likely hitting the same class of bug.

What to record before changing anything

Before you start “fixing” aggressively, collect evidence that helps separate a real session-reset bug from operator error.

Capture:

• OpenClaw version
• host OS and install method
• model and routing chain
• whether the problem is isolated to kimi-claw or also appears in other channels
• the exact user message that triggered the reset
• the exact reset banner text shown in chat
• relevant gateway logs around the reset time

That evidence matters because the current public report confirms the symptom pattern, but does not yet prove the exact root cause.

What not to assume too early

At this stage, avoid jumping straight to any one explanation.

Do not assume, without logs, that it is definitely caused by:

• the Kimi model itself
• context compaction
• a browser cache glitch
• user accidentally typing /new or /reset

Those are all plausible failure domains, but the issue report alone does not prove which one is responsible.

Fast triage: forced reset after a user question vs other continuity failures

This page becomes much more useful if you separate it from nearby failure patterns before you escalate.

• A reset banner appears immediately after a normal user turn
  • that is the strongest sign you are dealing with this specific forced-reset class of bug.
• The agent keeps replying in the same session, but forgets earlier details
  • that looks closer to context-loss, compaction, or state-reconstruction problems than a true reset.
• The run never stops or the thread continues after /stop
  • that is a better match for interrupt / cancellation failures than for accidental session recreation.
• Only one channel reproduces it while others keep continuity
  • that is a strong clue to keep the blame surface narrow and inspect channel-specific session handling first.

This split matters because operators often group all “the assistant forgot” incidents together, even when the underlying control-path failures are different.

Practical damage-control steps

Until upstream confirms a fix, the most practical response is to reduce workflow damage.

1) Check whether the bug is channel-specific

Try the same two-turn test in another channel or routing chain.

If the reset only happens in kimi-claw, that strongly suggests the fault domain is narrower than “all OpenClaw sessions are broken”.

2) Avoid long multi-step work in the affected channel

If each normal follow-up risks a forced reset, do not use that channel for:

• long debugging sessions
• iterative writing
• multi-turn planning
• tasks that depend on preserved local context

3) Keep a temporary external scratchpad

If you must continue working while the bug is open, keep critical context outside the live conversation:

• current task goal
• recent decisions
• file paths
• commands already tried
• expected next step

That will not fix the bug, but it reduces rework when the session drops its state again.

4) Test with a minimal reproduction instead of a large real task

A tiny two-turn repro is more useful to maintainers than a vague report like “it keeps forgetting stuff”.

What maintainers will likely need to inspect

Based on the current symptom pattern, likely inspection areas include:

• session lifecycle handling for the kimi-claw channel
• command parsing or accidental reset-path invocation
• channel-specific middleware or provider integration behavior
• how session keys are reused or replaced after inbound user messages

That is still an operational hypothesis, not a confirmed code-level diagnosis.

When this should be treated as high severity

Treat it as high severity if any of these are true:

• it reproduces on nearly every user question
• it affects more than one user or workspace
• it causes irreversible loss of working context
• it blocks business-critical support or operations flows

If you arrived from a release note, migration guide, or safety/cost page

Readers coming from those pages are usually not just browsing a Kimi-channel bug. They are trying to explain why an OpenClaw workflow suddenly stopped preserving continuity. Triage the intent in this order:

• A fresh install or migration loses context during the first multi-turn task: go back to the complete installation guide or the Moltbot to OpenClaw migration guide and check whether channel, model, or session settings carried over stale state.
• The instability started after a version change: compare it with the OpenClaw 2026.3.13 release evaluation before mixing release-readiness, CLI latency, and true session-reset symptoms.
• Only ordinary user messages in kimi-claw immediately show a /new or /reset lifecycle banner: then use this page's two-turn ORBIT reproduction and collect evidence for a forced-reset class of bug.

The point is to stop merging install residue, migration cleanup, release risk, and Kimi session lifecycle failures into one vague “lost context” report. The faster you classify the entry path, the more likely the visit becomes an actionable troubleshooting path.

What to capture before the next forced reset

When the Kimi claw channel resets right after a user question, capture the handoff boundary instead of only retrying the prompt:

1. Save the exact user message that triggered the reset, including attachments or quoted context.
2. Record whether the reset happens before model selection, after routing, or after the first tool call is planned.
3. Compare the same question in a fresh non-Kimi channel to separate channel-state failure from model/runtime failure.
4. Keep the session id and reset timestamp together so gateway logs can be matched to the visible chat break.

This turns a frustrating instant reset into actionable evidence for routing, session persistence, and channel recovery fixes.

Turn session-reset traffic into a context-retention acceptance checklist

If you arrived because the Kimi Claw channel force-resets a session immediately after a user question, do not only recreate the conversation. Split the reset path across four breakpoints: whether the user message is written into the current session, whether the force-reset trigger comes from the channel adapter, whether the runtime treats an exception as a recovery strategy, and whether the next reply loses prior context.

The minimal checklist includes the message id for one user question, the session ids before and after reset, channel-adapter logs, and context retention after retrying the same question. That routes session-reset traffic toward context persistence, recovery strategy, and channel-boundary intent instead of leaving it at sudden amnesia.

Related reading

• OpenClaw Feishu /stop Not Working: How to Confirm It Is a Real Interrupt Failure and Limit Blast Radius
• ACP Session Transcript Exists but Session APIs Return Empty History: How to Separate Missing History from Missing State
• Large Warning Triangle in Main Session: What to Check Before Reading It as a Fatal Session Error

Search-intent comparison: forced session reset vs ordinary context loss after a reply

Operators often search these incidents as one category because both feel like “the assistant forgot everything.” But the support path is different depending on whether the session was recreated or merely lost state.

Treat it as a forced session reset if:

• the chat explicitly says a new session started
• the reset happens immediately after a normal user turn
• state loss lines up with session recreation banners or lifecycle events

Treat it as ordinary context loss if:

• the same thread continues without any reset banner
• the agent still answers in place but forgets earlier details
• compaction, truncation, or state rebuild failures are more plausible than a new session being opened

This distinction matters for search intent too. People searching for kimi-claw resets after user question are usually not trying to tune prompts. They are trying to determine whether the session control path itself is broken.

What should the next operator receive in the handoff note

If you mitigated or reproduced this issue, leave these four items in the handoff:

1. whether the reset reproduced only in kimi-claw or also in other channels
2. one exact user message that triggered the reset
3. the exact reset banner or lifecycle message shown to the user
4. whether moving the same repro to another channel preserved continuity

That handoff prevents the next operator from reopening the broader “model forgot context” branch when the real problem is session recreation.

FAQ for search-intent triage

When a user says “it clears context right after I ask something,” what should you check first?

First check whether the chat explicitly shows “A new session was started via /new or /reset” or a similar lifecycle banner.

• If yes, treat it first as session recreation.
• If no, and the assistant merely answers like it forgot, it is more likely to be ordinary context loss, compaction, or failed state restoration.

That one split saves time because the logging and escalation paths are different.

Why is this more urgent than an ordinary “bad answer” complaint?

Because it breaks multi-turn continuity itself.

If every normal follow-up can recreate the session, then:

• debugging chains collapse
• support staff cannot continue inside the same thread
• user trust drops much faster than with a single low-quality answer

From a traffic perspective, this also matters for high-intent search pages because arriving users are usually already blocked by a real failure and have much lower tolerance for ambiguity.

If the bug reproduces only in kimi-claw, what should you suspect first?

Start with channel-specific session lifecycle handling, channel middleware, or accidental reset-path invocation, not with broad claims that every model or the entire OpenClaw session layer is broken.

A practical order of checks is:

1. whether the same two-turn repro preserves context in other channels
2. whether kimi-claw has its own session key, message wrapping, or slash-command handling path
3. whether the reset banner consistently appears after one class of inbound message

During temporary mitigation, what evidence is most useful for first-line operators to preserve?

At minimum, keep these four items:

• one exact user message that triggered the reset
• the exact reset banner or lifecycle text shown in chat
• whether the same two-turn repro also resets in another channel
• gateway log lines around the inbound user message and reset event

Those four details are usually enough for the next operator to decide whether they are looking at channel-specific session recreation, a wider session-lifecycle bug, or a false alarm caused by a different continuity failure.

Related reading

• OpenClaw Feishu /stop Not Working: How to Confirm It Is a Real Interrupt Failure and Limit Blast Radius
• ACP Session Transcript Exists but Session APIs Return Empty History: How to Separate Missing History from Missing State
• Large Warning Triangle in Main Session: What to Check Before Reading It as a Fatal Session Error
• Google Vertex Gemini 3.1 Pro Preview Returns an Empty Assistant Reply: How to Tell "Provider Never Replied" from UI or Mapping Bugs

Narrow Kimi resets by trigger point while on call

If this page is a search entry, the most useful question is not whether Kimi is good or bad. It is which step turned an ordinary message into a session-control event. Start by narrowing the trigger point:

1. Reset before the user sends anything: this looks more like old-session restore, channel initialization, or startup flags than user-message content.
2. Reset immediately after ordinary text: suspect kimi-claw slash-command parsing, session-key reuse, or the inbound message wrapper first.
3. Reset only when the message contains /new, /reset, command snippets, or pasted logs: treat it as possible command misfire or escaping failure and preserve the raw inbound payload.
4. No reset after moving the same repro to Feishu, Telegram, or Web: narrow the scope to the Kimi channel adapter instead of the entire OpenClaw session system.

That turns “it forgot again” into higher-intent troubleshooting evidence: startup restore, ordinary message handling, command parsing, or the Kimi adapter layer.

Related searches this page should answer

If this is the page you are expanding for search coverage, it should help users who search for questions like:

• kimi-claw resets right after I send a message
• openclaw new session started via /new or /reset after normal question
• kimi-claw loses context after every user reply
• session restarts immediately after prompt in kimi-claw

Those searches all sound slightly different, but operationally they often point to the same decision: did the session actually get recreated, or did the same session merely fail to preserve state?

Quick operator checklist

Use this when you need a fast yes/no triage path instead of a long investigation:

1. Confirm whether the chat shows a reset banner such as A new session was started via /new or /reset.
2. Confirm whether the same two-turn reproduction fails only in kimi-claw or also in another channel.
3. Save one exact triggering user message and the surrounding log window.
4. Move the affected workflow out of the channel if continuity is required for production work.

If you cannot answer all four, you do not yet have a clean handoff.

One more search-intent split: when should users search for “session recreated” vs “context lost”

This distinction is useful for first-line support and for search coverage.

Queries that usually map better to session recreation include:

• kimi-claw resets right after I send a message
• openclaw says new session was started via /new or /reset
• why does the session restart after a normal prompt

Queries that usually map better to context loss while the session survives include:

• agent forgot previous turn
• same thread replies but loses earlier context
• no reset banner, but the answer acts like amnesia

Separating those two entry paths makes both support triage and search routing much cleaner.

Search-entry triage: what to check when a session resets after every user question

If you landed here from searches like “Kimi Claw session reset”, “OpenClaw resets after user question”, or “agent disconnects when I ask”, split the issue into four layers:

1. Check whether the reset is real or just UI state refresh: compare the session id, message sequence, and log timeline before assuming the session restarted.
2. Check whether the channel adapter rewrote the input: for Kimi Claw-like channels, inspect message wrapping, reply ids, thread ids, and whether the user question was merged into the wrong context.
3. Check whether the agent runtime received an abnormal control signal: some “resets” are not model failures, but upstream logic treating a new question as a fresh start.
4. Preserve the smallest reproducible input: one user question, trigger time, channel, and session id are more useful than a long screenshot.

Do not debug this class of issue only from model output. The fastest path is to verify whether UI state, channel adaptation, session lifecycle, and runtime control signals tell the same story.

Related reading

• Troubleshooting OpenClaw Agents: What to Check When Tasks Stall or Tools Misbehave
• What to Check First When sessions_send Times Out
• What to Check When Gateway Does Not Resume Orphaned Sessions After a Crash Restart
• How to Build Self-Healing Infrastructure with OpenClaw

Source

• openclaw/openclaw#57834

Quick decision tree while on call

If a user question immediately triggers a forced reset in the Kimi / Claw channel, do not treat it as ordinary context cleanup first. Use this sequence instead:

1. The session resets as soon as the user asks, and the behavior reproduces reliably
   • Suspect channel event handling, session lifecycle code, or a reset guard firing at the wrong time before blaming the user input.
   • Preserve the event order and session-state changes around the trigger.
2. Only the Kimi channel is affected while other channels work
   • Treat this as an integration-path problem, not a full session-system outage.
3. Manual new sessions work, but incoming user messages interrupt them
   • Focus on the inbound-message-to-session-binding path and the reset guard around it.

What to verify before calling the incident closed

Even if the session no longer resets immediately, do not stop after one successful question. Verify these four things first:

1. Multiple real user questions in the same channel stay attached to the same session.
2. Session history, UI state, and persisted storage agree, so there is no hidden session swap.
3. The fix did not regress other channels, agents, or session-isolation rules.
4. The incident note records the trigger, affected version, event-log anchors, and temporary workaround.

Related reading

• Troubleshooting OpenClaw Agents: what to check first when tasks stall, tools do not return, or results look wrong
• OpenClaw ACP One-Shot Run Looks Empty in sessions_history, Even When .jsonl Transcript Exists
• OpenClaw core schema becomes incompatible with the official Feishu plugin
• OpenClaw complete installation guide: self-hosting, checkpoints, and common mistakes

Handoff checklist before returning Kimi to long-running tasks

If you plan to put the kimi-claw channel back into long-running work, run a small continuity check instead of only confirming that the service is online:

1. Send the two-turn ORBIT memory test with the same user identity and confirm no /new or /reset banner appears.
2. Add one new constraint in the second turn, then verify both the remembered word and the new constraint in a third turn.
3. Run the same three-turn check in one non-Kimi channel to confirm the channel-state failure is gone.
4. Record pass time, session id, and the matching gateway log fragment in the handoff so the next responder does not start from “maybe it just forgot.”

This raises the recovery standard from “the page opens and the model replies once” to “the multi-turn session no longer recreates itself unexpectedly.”