Unclear What post-turn memory actually does when triggered (what it writes or where) is not described in the finding.
What
- Three new environment variables control a new "post-turn memory" feature:
CLAUDE_CODE_POST_TURN_MEMORYturns it on,CLAUDE_CODE_POST_TURN_MEMORY_CONFIGcarries a JSON config (instruction,every_n_turnsfrom 1-100 default 5,max_turnsfrom 1-8 default 4,idle_flush_sfrom 0-86400 default 120), andCLAUDE_CODE_POST_TURN_MEMORY_SYNCforces synchronous flushing (everyNTurns=1,idleFlushSeconds=0). - The background memory-extraction task now supports a second mode,
mcp, driven by these same env vars: instead of writing memory files, it calls a query using the configured instruction and supports idle-flush timers. - Extraction activity is now logged to a new
ccr_memory_extractevent set that records the mode (mcpvsfile), instead of only the previousmemory_extractevent.
Why This lets memory extraction run through an MCP-based memory server rather than always writing local memory files, with configurable frequency, turn limits, and idle-flush timing, and gives clearer telemetry on which mode was used.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
What post-turn memory actually does when triggered (what it writes or where) is not described in the finding.