MoonshotAI / MoonshotAI/kimi-code

Stop hook should include recent messages to enable external memory systems

Open
#1,306 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

Problem

Currently the Stop hook payload only carries a minimal set of metadata (e.g. aborted). For external memory systems that want to observe and learn from a completed turn, this is insufficient: they can see that the agent stopped, but not what was said during the turn.

Without the assistant reply, a memory hook cannot store the full user/assistant exchange. It must rely on:

  • Earlier hooks such as UserPromptSubmit (which only sees the user message), or
  • Asking the model to explicitly call memory tools, which is unreliable and adds latency.

How other agent CLIs solve this

We surveyed the hook/event designs of several popular agent CLIs in the ecosystem:

Claude Code
  • Stop hook receives transcript_path pointing to a JSONL transcript file.
  • Hooks can read the transcript to extract recent user/assistant messages.
  • Source: plugins/plugin-dev/skills/hook-development/SKILL.md
OpenAI Codex
  • Stop hook receives last_assistant_message inline, plus transcript_path to the rollout JSONL.
  • There is also a legacy AfterAgent hook that passes recent user messages inline.
  • Source: codex-rs/hooks/src/schema.rs, codex-rs/hooks/schema/generated/stop.command.input.schema.json
OpenCode
  • No direct Stop hook, but plugins can listen to:
    • chat.message for each new user turn,
    • event for durable assistant/tool/text events,
    • experimental.chat.messages.transform to read the full message list before the LLM call.
  • Source: packages/plugin/src/index.ts, packages/opencode/src/plugin/index.ts
kimi-cli (previous generation)
  • Stop hook only receives stop_hook_active, similar to the current kimi-code behavior.
  • Conversation is available only by reading session files from disk.
  • Source: src/kimi_cli/hooks/events.py, src/kimi_cli/wire/types.py

Why PR #1299 is the right fix

PR #1299 (https://github.com/MoonshotAI/kimi-code/pull/1299) extends the Stop hook inputData with a messages array containing the recent user/assistant messages, with non-text content parts filtered out for JSON safety.

This brings kimi-code in line with the ecosystem:

  • Codex provides last_assistant_message + transcript path.
  • Claude Code provides transcript path.
  • kimi-code would provide the recent messages inline, which is the most hook-friendly approach and avoids requiring filesystem access or parsing JSONL transcripts.

Benefits

  1. External memory systems can learn from full turns. A memory hook can store user preferences, decisions, and facts from both the user prompt and the assistant reply.
  2. Backward compatible. Existing Stop hooks that ignore messages continue to work unchanged.
  3. No extra model/tool calls needed. The hook receives the context deterministically at the end of each turn.
  4. Aligns with user expectations. Developers coming from Claude Code or Codex expect lifecycle hooks to expose enough context to build memory, logging, and observability integrations.

Request

Please review and consider merging PR #1299. The implementation is minimal, tested, and includes documentation and a changeset.

cc @wbxl2000 @liruifengv @RealKai42 — would love your feedback on this.

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 reviewing PR #1299, which the issue identifies as the implementation of the Stop hook message change. Check its tests, documentation, and changeset, then verify that the proposed messages data supports the stated external-memory use case and remains backward compatible before deciding whether it is ready to merge.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.