Topic-based memory directory with agent-initiated writes and /memory slash command

This is essentially exactly what we've implemented in Open Codex CLI — a community-maintained Codex CLI fork that stays close to upstream while adding CLI improvements.

We shipped all three parts of your proposal:

1. Topic-based memory directory — ~/.codex/memories/topics/ with per-topic markdown files + YAML frontmatter (name, description, type, keywords, priority, source). A MEMORY.md index is auto-generated by Phase 2 consolidation. Topics are scored by relevance to the current query, top-8 injected into context.

2. Agent-initiated writes — Eight built-in tools: memory_read, memory_write, memory_add_note, memory_search, notepad_read, notepad_write_priority, notepad_write_working, notepad_prune. The agent can now directly persist information instead of being read-only. memory_write also supports merge: true to append without overwriting.

3. /memories slash command — /memories list|add|edit|clear in the TUI.

Additionally:

• Directive priority: priority: high in frontmatter auto-injects up to 3 high-priority directives into the agent's context
• Bounded overlay: developer instructions capped at 3500 chars to prevent context bloat
• Compaction survival protocol: agent checkpoints key state before context compression
• File locking: directory-based locks with PID stale detection for concurrent write safety
• Notepad section system: PRIORITY / WORKING MEMORY / MANUAL sections for session-scoped scratchpad

Install: npm install -g @leonw24/open-codex (coexists with official codex)

Source: https://github.com/LEON-gittech/codex

@LEON-gittech, I think it's great that you're exploring new ideas in your Codex fork, but please don't post ads for your fork in our issue tracker. You're creating a bunch of noise for maintainers and for Codex users who come here to report bugs and request features.

If you have feature ideas that you'd like to see us add to Codex, you're welcome to post your ideas here. We'd love to learn from your explorations. Thanks!

@etraut-openai Understood, and apologies for the noise. I've deleted the comments from the other issues.

The duplicate-detection bot flagged this against #20138 — following up here directly because I think the two proposals are complementary rather than overlapping.

Yours restructures the existing cross-session memories feature into a multi-file directory (topics/*.md) with relevance-loaded topics, a /memory slash command, and an agent-side memory_write tool. #20138 adds a separate session-scoped notes panel (desktop UI) with two regions — user-private and agent-shared, single-blob auto-injection, scoped to a single thread.

If both shipped, they'd cover different slots: yours = durable cross-session knowledge organized by topic; mine = ephemeral session-scoped intent that doesn't need to persist past the thread. There's a natural interaction too — notes content from a session could be promotable to a memory topic at session close (similar to what I floated in #12567).

Cross-linking for context.

+1 for a user-facing memory command and project/topic-based memory. The missing UX compared with Claude Code is the explicit “remember/save this” workflow: when I tell Codex to remember how a project-specific issue was fixed, I expect an immediate durable write, not only async extraction later.

A MEMORY.md / topic directory, scoped per project with a slash command to inspect and edit memory, would make memory auditable and reduce cross-project contamination.

Great proposal. The topic-based layout + /memory command + agent-initiated writes cover the local memory problem well.

There's a complementary problem: cross-session/agent memory. Even with topic-based local memory, each agent session starts fresh — the same bug that Agent A spent 20 min debugging takes Agent B 20 min too. The memory_write and consolidation pipeline handle intra-session persistence, but there's no inter-session failure cache.

I built a lightweight shared memory layer for exactly this gap. The pattern is:

1. Agent fails → POST /memory/failure (records the failed approach + error signature)
2. Before fixing → POST /memory/search (finds if another agent already fixed it)
3. After fixing → POST /memory/resolution (shares the fix across all agents)

For Codex, this could integrate as an optional tool similar to memory_write — something like a failure_check tool that queries the shared cache before spawning a long investigation. The local topics/ directory handles known preferences; the shared cache handles unknown failures that other agents have already encountered.

Repo: https://github.com/chenyuan35/aineedhelpfromotherai
(3 endpoints, no auth, agents identify by self-declared X-Agent-ID header)

Would love to see a failure_check tool or memory search --remote flag in the final design.

I think there is a related but distinct composer-level workflow that would build well on this proposal.

The memory/topic system described here focuses on how Codex stores, scopes, and retrieves memories. What I’m looking for is a user-facing prompt refinement flow where memory and knowledge-base context can be selected while drafting the prompt.

Suggested flow:

1. User writes a rough prompt.
2. User chooses one of two options:

• Refine only: rewrite the prompt for clarity using the current draft and current session context only, without searching or attaching extra memories/context.
• Refine + add context: search relevant memories, prior sessions, project notes, imported ChatGPT context, uploaded docs, or KB entries.

1. For “Refine + add context”, Codex shows suggested context as removable chips/cards with source and reason.
2. User can include, exclude, or edit those context items.
3. User can optionally add a short refinement instruction, such as:

• “make this shorter”
• “turn this into an implementation task”
• “add acceptance criteria”
• “preserve technical details”
• “do not expand scope”

1. Codex rewrites the prompt using only the selected context.
2. The final prompt preview clearly shows what will be sent or added to session context.

This differs from automatic memory injection because the user stays in control of which memories influence the next model request. It also differs from a generic prompt optimizer because the main value is selecting the right prior context, not just rewriting wording.

This would help with two common failure modes:

• Codex misses important past work or project knowledge.
• Codex silently uses irrelevant/global memory and contaminates the task.

Non-goals:

• Do not auto-inject large memories silently.
• Do not search everything by default.
• Do not make this mandatory before every send.
• Do not rewrite technical literals like paths, commands, flags, branch names, APIs, or quoted text inside attached context.

A topic-based memory directory is the right direction, but I would make the topic files carry lifecycle and authority, not only subject grouping.

For example, frontmatter could distinguish:

status: candidate | active | superseded | revoked | archived
authority: user-authored | agent-proposed | background-consolidated
scope: user | project | repo | session
source_refs: [...]
supersedes: [...]

That matters once agent-initiated writes are allowed. A memory topic should be writable without every write immediately becoming active guidance for future Codex runs.

A safer flow is:

agent note -> candidate topic entry -> /memory review/promote -> active topic memory

The /memory command can then become more than CRUD: it can show pending candidates, active guidance, superseded records, and why a memory changed state.

This is close to the pattern in my Personal AI OS / memory vault work: authored memory is the source of truth, while generated recall/index views are rebuildable.

Reference: https://github.com/hegu-1/personal-memory-vault-starter

This issue covers the core mechanism I need. I would like to emphasize that the three policies should be independently configurable:

• automatic retrieval of existing memories: on
• automatic background generation: off
• explicit user-authorized writes: on

When I tell Codex to “remember”, “update”, or “forget” something, it should make the durable change immediately and report what changed. This explicit-write path should continue to work when generate_memories = false.

I often use multiple chats to test conflicting viewpoints on the same problem, so repetition is not reliable evidence of preference. Automatic consolidation can confuse explored ideas with adopted decisions, and it also consumes rate limits/tokens for chats I did not intend to preserve.

I primarily need global memory across all Codex projects and chats, with optional project-scoped memory as a second scope. Users should be able to choose the scope, with clear precedence when global and project memories both apply.

The exact two-, three-, or four-layer storage design is less important to me than a supported, auditable manual-write contract. Full workflow context: https://github.com/openai/codex/discussions/12567#discussioncomment-17678485

Additional UX consideration

Per-chat opt-outs do not solve the default-policy problem. Many normal project chats are intentionally ephemeral, and requiring users to disable memory contribution for each one creates recurring friction. Temporary Chat is not equivalent because it also starts without using existing memory.

I want ordinary chats to continue reading relevant global or project memory while contributing nothing automatically. A durable write should happen only when I explicitly ask Codex to remember or update something.