English Articles Developer Productivity

Turn Codex /end into Knowledge Capture, Not Just Session Closeout

Read the original article in Japanese

English adaptation of the author's April 10, 2026 Japanese article. This is a description of a custom workflow, not a claim about the default behavior of current Codex releases.

Coding agents are good at helping make decisions in the moment. But valuable reasoning can disappear into an old chat after the task ends. I wanted a small process that would capture reusable decisions and lessons before closing a Codex session, without filling long-term memory with every sentence.

I turned the /end stage in my own workflow into a lightweight knowledge triage step.

Knowledge capture pipeline from a session to candidate notes and reviewed memories
Figure 1. A candidate note is not yet a durable lesson. Review is the boundary between capturing and promoting knowledge.

Open full-size diagram

Why a closeout step was not enough

An ordinary closeout might update the task list and handoff, then terminate the session. That is useful for the current project, but it can leave transferable decisions buried in the conversation.

The starting inspiration was OpenClaw's /dreaming concept: extracting potentially reusable information from conversations and notes. OpenClaw and Codex are different systems. I did not transplant a native feature from one tool into the other. Instead, I built a minimal process for my current Codex environment.

The goal was to turn the end of a session into a point where useful knowledge is considered, not automatically accepted.

The four-step closeout flow

My intended closeout sequence became:

  1. Extract dream candidates from the session.
  2. Review those candidates.
  3. Promote only worthwhile items to project lessons or broader memory.
  4. Update TASKS.md and the handoff before finishing.

The important rule is that extraction alone does not establish usefulness or correctness.

A small, rule-based extractor

The first version took conversation logs or notes as input, selected sentences that looked reusable, and stored the results under:

~/.codex/memories/dreams/

I implemented the flow with three components:

  • dreaming_capture.py
  • capture_codex_dream.sh
  • codex-dream

For example, my original setup supported this command to preview candidate notes from the clipboard:

pbpaste | codex-dream --title closeout --stdout-only

This is not a built-in Codex command. It belongs to the custom local implementation. In the original article, extraction was rule-based, not deep semantic judgment by an LLM. Users should not expect it to classify every useful idea correctly.

The --stdout-only example was meant for inspecting output before deciding whether to keep it.

Three levels of retained knowledge

I deliberately separated candidate capture from durable knowledge:

Destination Purpose Review standard
Dream candidate A temporary possible insight Broad capture is acceptable
Learned lessons A useful project-local finding Promote after review
Global memory Knowledge reusable across projects Apply an even stricter standard

Saving everything globally would make future retrieval noisier and harder to trust.

For example, a failed command that exposes an environment-specific path might be useful for one project's troubleshooting, but not as universal guidance. A general, validated rollback rule might deserve promotion beyond one repository.

The category is a review decision, not something the script can infer infallibly.

Making /end a reliable handoff

I paired the knowledge-capture step with a session-closeout skill, checklist, and template. The final status report had four fixed fields:

TASKS.md: updated | unchanged
Dreams: captured | skipped
Handoff: updated | unchanged
Lessons: saved | skipped

This kept the ritual short enough to repeat. A long, fragile closeout workflow would create a new reason for the agent to stop or fail.

The goal was not to make /end perform unlimited repository changes. It was to make closeout observable: a later session can see what was captured and what was intentionally left alone.

A discovery problem I encountered

One practical issue was that I created a skill but Codex did not discover it. In that setup, repo-local discovery expected .agents/skills/ rather than a generic skills/ directory.

Putting a file only at:

openclaw/skills/session-closeout/SKILL.md

did not make it appear in Codex's repository-local skill discovery. I therefore added mirrored entrypoints at:

.agents/skills/session-closeout/SKILL.md
.agents/skills/learned-lessons/SKILL.md

Those paths describe the behavior I observed in my environment. Skill discovery conventions can change, so verify the rules for the installed tool version.

Who benefits from this approach?

The extra step is useful if you use Codex continuously, regularly repeat previous decisions, maintain handoff files, and want useful lessons to survive chat boundaries.

It is not necessary for every quick request. Nor should it become a reason to archive full private conversations indiscriminately. Retained notes need appropriate privacy, secret handling, accuracy review, and a clear scope.

For a minimal trial, first make the extractor produce reviewable candidates without writing permanent global memory. Introduce promotion rules only after you can distinguish useful lessons from noise.

The central design decision

My biggest change was conceptual: /end became the entry to knowledge selection, not just an instruction to stop. The pipeline stayed deliberately simple: collect possible lessons, review them, promote selectively, and finish the handoff.

The result is a local workflow, not evidence that Codex itself implements this automatically or that more memory will always make an agent more effective.

-English Articles, Developer Productivity