Hi Kimi Code CLI team,
I'd like to share a gap I’ve noticed while using Kimi Code CLI with long-running projects.
Problem
Each session is currently stateless: the agent cannot remember decisions, lessons, or project-specific notes from previous sessions. When I return to a project, I have to re-explain context, re-state conventions, and re-learn from past mistakes.
My setup
I run a local persistent-memory layer (claude-mem + graphify + markdown decision/lesson records + Ollama bge-m3 embeddings) that works great with Claude Code and Codex. It exposes read-only tools like search_memory, get_record, and prompt-recall over a local daemon.
Requested capabilities
- Lifecycle hooks(
SessionStart, UserPromptSubmit, etc.) so a local script can inject a recall block or trigger memory extraction, or
- Custom MCP server / skill registration so users can wire their own local memory daemon into the agent context, or
- A built-in persistent memory layer that can query an external/local memory store before each prompt.
Benefits
- Cross-session decision continuity
- Fewer repeated mistakes
- More context-aware architectural decisions
- Parity with Claude Code / Codex ecosystems
Thanks for considering this.
Hi Kimi Code CLI team,
I'd like to share a gap I’ve noticed while using Kimi Code CLI with long-running projects.
Problem
Each session is currently stateless: the agent cannot remember decisions, lessons, or project-specific notes from previous sessions. When I return to a project, I have to re-explain context, re-state conventions, and re-learn from past mistakes.
My setup
I run a local persistent-memory layer (claude-mem + graphify + markdown decision/lesson records + Ollama
bge-m3embeddings) that works great with Claude Code and Codex. It exposes read-only tools likesearch_memory,get_record, andprompt-recallover a local daemon.Requested capabilities
SessionStart,UserPromptSubmit, etc.) so a local script can inject a recall block or trigger memory extraction, orBenefits
Thanks for considering this.