MoonshotAI / MoonshotAI/kimi-cli

Cron fire mid-reply swallows the previous assistant reply; unrecoverable via Ctrl+O

Open
#2,620 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
11.4k
Forks
1.3k
Avg merge
9h 47m
Merged PRs (30d)
2

Description

Summary

When a scheduled cron reminder fires while the assistant's previous reply is still on screen (user hasn't responded yet), that reply disappears from the visible transcript. It cannot be recovered — scrolling back shows the turn was replaced by the cron turn, and Ctrl+O expand does not bring the lost reply back.

Environment

  • Kimi Code CLI 0.38.0
  • macOS (Apple Silicon), running inside cmux
  • A recurring cron created via CronCreate (23/25 * * * *)

Repro

  1. Create a recurring cron reminder (CronCreate).
  2. Have the assistant produce a long, substantive reply (in our case: five drafted GitHub issue replies + product-policy discussion).
  3. Before the user responds, the cron fires.
  4. The cron prompt is injected and a new turn starts immediately.
  5. The previous assistant reply is gone from the transcript — Ctrl+O shows only tool-call fragments, not the lost reply text.

Expected

  • A cron fire should never destroy transcript content. If the user hasn't consumed the previous reply, the fire should be queued/coalesced AFTER the reply is durably committed to the transcript.
  • Lost replies should at minimum remain recoverable via scrollback / Ctrl+O.

Impact

Real user-facing data loss: the user had read only part of the swallowed reply ("I only finished reading the five drafts; the #86/#79 sections were gone"). The content existed nowhere else and had to be re-generated.

Notes

  • Possibly related family: #2617 (session-state corruption after Compact/resume — different symptoms: Edit/Write fake success + ghost cron delivery). This one needs no corruption: just a long reply + a mid-display cron fire.
  • Screenshots of the swallowed state available on request (shows the reply cut off mid-render and the "Scheduled reminder fired" block taking over).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue with a recurring CronCreate reminder while a long assistant reply is still displayed, then inspect the cron prompt injection and transcript handling around the new turn. Use scrollback and Ctrl+O to verify whether the earlier reply remains recoverable. Done means a cron fire no longer removes or hides the previous assistant reply, with coverage for this mid-reply scenario.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.