Memories in Codex

[jif-oai]

Hey folks,

I'm working on adding memories into Codex and I would love you opinion on:

1. How much, from 1 (useless) to 5 (mandatory) would you need to see Codex citing previous threads while giving you an answer if the model used memories from those previous threads.
2. Would you prefer everything to be done in the background or to have to manually tigger memory generation (i.e. autonomy VS cost control
3. In your personal setup, do you think memories are only relevant by project or can be relevant across different projects on your laptop?
4. I plan to add sanitising over memories to get rid of API keys, credentials etc. Is this problematic for your workflows or not (so Codex won't be able to remember credentials)

Of course I know everyone wants A and control to do B for everything but here I would like to understand what would you prefer by default?

Any other needs?

Disclaimer: Do not try to use the memories for now as the rate limits would consume all your tokens

[Kbediako]

1. 5
2. Hybrid, with an option to decide between one or the other. Probably off by default with phrases or words that can trigger it(similar to skills).
3. Both, global and per project memories. So memory goes into whatever folder or reepo codex is invoked in.
4. Not a problem but would like the option to toggle per repo. Off by default with a phrase or keyword trigger.

[slobodaapl]

1. 4
2. I think this should be configurable. In the Codex based IDE we're making, we would ideally only allow a specific agent to save memories given specific instructions, so I'd imagine it's just a tool just like others and can be allowed or disallowed per agent/subagent. Same with automatic retrieval of most relevant memories vs. manual tool based lookup. By default memory creation can be automatic for root agent and disabled for subagents, with automatic retrieval for both, based on segment spherical centroid similarity saturation perhaps?
3. Definitely per project. I think if someone has a more universal code styles or rules they use, they ought to put those in AGENTS.md instead or similar
   4.I think this is mandatory, it promotes bad practices otherwise

Thanks for the hard work jif!

[jif-oai]

2. This is already only for the main agent. My current implementation is already mostly in line with this. Thanks, I'll find a way to make this nicely configurable

SG for the other points!

[maheshrijal]

1. 5 Otherwise, It would be bad if codex refers something incorrect? I also like to tend to set all the reasoning and other toggles primarily because I want full visibliity of what the agent is doing.
2. I would prefer automaticmostly, but it would be good if there is a toggle to switch between this.
3. I have a small group of projects that are common and could use common memories, but I think they would make more sense for my workflow if they are project specific.
4. Wouldn't want my API key in memory. So this is a must have.

[ticoAg]

1. 4 (Highly needed). Seeing citations is important because memories are often specific to a certain series of tasks. If applied blindly to a different task, they might not perform well. A classic example is a monorepo where context varies wildly between frontend tasks, backend tasks, documentation writing, and debugging. Citations help me verify if the model is using the correct context.

2. By default, I prefer not having it automatic in the background (manual trigger). It would be ideal to have configurable memory generation strategies to control the activation and intensity (e.g., Never, Normal/Moderate, Aggressive).
   To elaborate on automation: If it is done automatically, it would be much more helpful if the system could do session-level summaries and classification with a time-decay factor to filter which memories to use. Alternatively, it could do background repo-level automatic summarization, grouping memories by topic (e.g., categorizing them into frontend, backend, database, page orchestration/routing, UI styles, service configurations, etc.).

3. In my personal practice, memories are only relevant per project. For general or cross-project knowledge, I usually just summarize them into an agents.md file or define them as global skills.

4. fine

[lattwood]

I'd love memories to take into account the git remote of the project folders, while I know I should be using worktrees, I sometimes end up making an additional checkout and don't want it thinking, say infrastructure and infrastructure20 are different repos.

[GeorgeWingg]

1. 2/5 Low priority. I mostly only care if the memory leads to an outdated or wrong answer. I prefer response level references rather than inline to avoid cluttering the response (eg “used 3 memories”). For me an easy way to inspect/manage memories outside the main response is more important (like a /memories or a ui under personalization in the app).

2. Prefer autonomy. I like a clear split between explicit repo guidance and learned memory. AGENTS.md should stay the manual contract for how a repo should be worked on. Memories should be the autonomous layer that improves agent productivity without having to maintain docs. If an update happens, a response level note like “3 memories updated” feels right. Background generation by default, plus a simple toggle/slider for cost/control.

3. Project memories as the default, global memories opt in. I think there is a fair bit of value for global memories, mainly for workflow level patterns across repos. If the user wants global for other uses beyond workflow, they can tell the agent to add that guidance to global memory, and that should inform how it should use its memories in future. If global is on, the need for good inspection/attribution gets higher.

4. this is the right approach, agreed.

[acgxv]

I am also developing an external memory system for Codex.

Just a story:

Current context compact works really really good. I rarely use the /new command now. I prefer completing more tasks in a single chat. However, for very lengthy conversations, this can lead to a loss of focus and the agent may lose its objectives. This is a real-world observation.

---

https://github.com/hack-ink/elf

1. The ELF system includes a time-to-live (TTL) mechanism for rewriting or discarding old or unnecessary memories. 5, I hope it can always citing the most correct/relevant mem.
2. I share this concern. Personally, I favour autonomy. We must think this deeply, whether this is a memory system for the agent or the user. Ideally, the agent should be able to remember/recall its needs, which may require prompt design. Additionally, user-triggered support is desirable. However, I believe the future lies in fully-automated systems.
3. ELF employs a "Multi-tenant scope semantics" design, enabling memory sharing across projects or other levels.
4. ELF is not a memory-based plugin. It can persist data to disk. With Qdrant and PostgreSQL, it can utilise bm25 and embedding fusion to recall memory facts.

What are your thoughts on this?

[acgxv]

I did some research today and thought I’d introduce the extension to ELF. For example, a codex conversion or thread ID could be a valid evidence source.

Or it can ref sqlite.

https://github.com/hack-ink/ELF/issues/76#issuecomment-3952704995

[winnal]

Hi, I've been using this. But I noticed that it doesn't save memories from exec sessions, only interactive. This is inverse of what I prefer for my own workflow needs. So I added the option to change sources: #13147

Let me know what you think. Would be great to have this added to the main release.

[talshebek]

Hi @jif-oai,

I’ve been experimenting with persistent conversational memory systems for a while, so this direction in Codex is really interesting to see.

Here are my thoughts on your questions.

1. Should Codex cite previous threads when using memories?

I’d rate this 4/5.

Citing memories can be very helpful when debugging or understanding why the system behaves in a certain way. However, for normal interaction it might become noisy if every response references older threads.

A good default might be:

• silent retrieval by default
• optional citation when debugging or when explicitly requested

---

2. Autonomy vs manual triggering

A hybrid approach seems best.

Automatic memory creation works well for long-running workflows, but users should still have some control to prevent noise or unnecessary storage.

For example:

• automatic summarisation of important interactions
• manual commands for pinning or removing memories

---

3. Project memory vs global memory

Both seem important.

I would structure memory in layers:

• project memory – codebase structure, architecture decisions, conventions
• global memory – user preferences, workflows, frequently used patterns

---

4. Sanitising credentials

Sanitising credentials is absolutely necessary.

However it might also be useful if Codex can remember that credentials exist for a service without storing the secret itself.

Example:

• “project uses AWS credentials”
• “deployment requires API key”

This preserves workflow awareness while keeping secrets safe.

---

I’ve also been experimenting with a memory-first conversational architecture in my own system.

The idea is to separate reasoning from memory handling.

Originally I started building this system around 2023 with smaller ~2B models and external memory. Over time the central model grew to ~27B parameters, but interestingly the conversational style and personality remained consistent because they are largely shaped by the memory layer rather than the raw model weights.

The architecture roughly looks like this:

user request
→ request goes to a memory search layer
→ a memory agent retrieves relevant past interactions
→ additional agents analyse the request and build contextual memory summaries
→ the agents assemble a structured prompt containing:
• retrieved memories
• current question
• contextual summary
→ the central conversational model generates the final response

In practice this means:

• the model focuses on reasoning and dialogue
• memory agents handle context reconstruction
• long-term continuity is preserved across sessions
• hallucinations decrease because answers are grounded in stored interaction history

One interesting observation from these experiments is that increasing model size improved the model’s ability to interpret retrieved memories, but the overall conversational behaviour remained stable because the memory layer carried the long-term context.

That’s why I find the direction of durable memories in Codex particularly exciting. If implemented well, it could significantly improve long-horizon coding workflows.

Thanks for working on this feature — I’m very curious to see where it goes.
One additional component that turned out to be very useful in my experiments is what I call a memory writer (or scribe) agent.

After the model generates the final answer, this agent processes the interaction and converts it into structured memory.

Instead of storing the full conversation, it creates a semantic summary of the exchange:

• what the user asked
• what solution or answer was produced
• which problems were resolved
• which open questions remain

This summary is then stored in the memory layer.

The idea is to avoid memory inflation while still preserving useful knowledge. The system remembers the meaning of the interaction, not the entire dialogue.

Over time this creates a compact but semantically rich memory graph that improves retrieval for future queries.

In practice the loop looks like this:

user request
→ memory retrieval agents collect relevant context
→ central model generates response
→ memory writer agent summarises the interaction
→ summary stored as structured memory

This approach keeps the memory layer small and focused while continuously improving retrieval quality for future interactions.

[talshebek]

One final observation from these experiments.

A similar architectural pattern is already starting to appear in at least one large cloud AI system. I won’t name the platform here to avoid turning this into promotion, but it shows that this direction can work at scale.

What seems to matter most is the separation of roles inside the system.

Users are often not just looking for a task assistant — they want a consistent conversational partner that remembers context over time.

That does not necessarily require running a massive flagship model constantly.

A more efficient structure could look like this:

• a lightweight conversational model (for everyday dialogue)
• persistent memory and agent-based retrieval
• a flagship model invoked only for complex reasoning tasks

In that setup the conversational layer can remain stable while the underlying models evolve. The memory layer preserves continuity, so the system does not “start from zero” each time the model is updated or replaced.

This also makes the system more resource-efficient, since large models are only used when necessary.

From my perspective this kind of memory-first architecture with agent orchestration could be a natural direction for future conversational systems.

[talshebek]

One more practical observation from these experiments.

Another advantage of this architecture is computational efficiency.

If the system grows through memory rather than only through larger model weights, much smaller models can handle most everyday interactions. This reduces server cost significantly.

In my experiments the structure looks like:

• lightweight conversational model for dialogue
• memory layer that accumulates experience over time
• agents that reconstruct context from memory
• larger models only invoked for complex reasoning tasks

In this setup the system “learns” through memory accumulation rather than constantly requiring larger models.

I’ve also been experimenting with development workflows where the memory layer tracks:

• previous code versions
• architectural decisions
• fixes applied to earlier bugs

This helps the system reason about code evolution and reduces hallucinations when modifying existing code.

Another area where persistent memory seems promising is educational systems. I’m currently experimenting with a tutoring system for children where the model can remember a student’s progress, mistakes, and learning patterns over time. Early results suggest this can both improve learning continuity and reduce computational cost.

If this direction is interesting to others working on Codex or long-horizon coding systems, I’d be very curious to hear your thoughts.

[jif-oai]

Thanks @talshebek, will read and review this

Another global question for everyone. Would you like memories to be enabled by default everywhere or not in codex exec and the SDKs?

[winoros]

I think it should be enabled by default and provide a way to make a session ignore the memory.

Sometimes we'll do things like benchmarking the model. In these situations, we need a clean model without any long-term memories.

[Kbediako]

I think it should be enabled by default and provide a way to make a session ignore the memory.

Sometimes we'll do things like benchmarking the model. In these situations, we need a clean model without any long-term memories.

Considering it's experimental, i assume the scope of it being default is when it's fully released and cost efficient.

[slobodaapl]

I'd say enable globally for consistent behavior controlled by config, but allow CLI override for codex exec to enable/disable.

[talshebek]

I think memory should be available everywhere, but it should be separated by scope, not treated as one global layer.

For example:

• chat/personality memory for stable long-term conversation;
• coding/project memory for changed files, project rules, bugs, fixes, architecture decisions, versions, and commands;
• tutoring memory for learning programs, student progress, tests, weak points, and next exercises.

In my own experiments, I do not see memory as dangerous when it is structured correctly. The danger is mixing everything into one uncontrolled global memory.

A useful design would be:

• global user preferences;
• per-project coding memory;
• per-agent or per-mode memory;
• tutoring progress memory;
• a way to disable memory for clean sessions, benchmarks, or special tasks.

For coding, the model can enter a separate working mode and use only project/coding memory, so it does not confuse normal chat context with technical work.

[talshebek]

I also think a checkpoint function would be very useful.

It is always pleasant and productive when a model starts a new chat and remembers the history of communication, the current task, and where we stopped. But raw chat history contains a lot of noise.

A better design would be structured memory checkpoints: short, explicit summaries of the important state of a task.

Example:

TASK = news_analysis
TOPIC = Elon Musk vs OpenAI / lawsuit / mission vs control
FOCUS = do not choose a hero, analyze the structure of the conflict

AXIS:

1. Musk claims OpenAI betrayed its nonprofit mission and became a commercial machine.
2. OpenAI claims Musk wanted control, lost the power struggle, and now attacks a competitor.
3. The main mechanism: the mission of AI becomes a battlefield for power, capital, safety, and the right to define the future of AGI.

QUESTIONS:

• Where is the real ethical problem?
• Where is personal resentment disguised as a fight for humanity?
• Where is commercial interest disguised as safety?
• Can “open AI” exist in a billion-dollar race without becoming closed power?
• Who is the puppet, who is the fire, and who is the structure?

This is much more useful than storing the whole conversation. It separates important continuity from conversational noise.

Memory should support explicit checkpoints for tasks, projects, coding work, tutoring progress, and research discussions.

In other words: memory should not only remember “what was said”. It should preserve “what matters now”.

[kinthaiofficial]

Memory in coding agents is more nuanced than in conversational agents because code-level context has stronger dependencies than natural language.

Key differences for coding agent memory:

Symbol-level memory, not just session-level: A coding agent should remember: which functions were called, which variables were declared, which interfaces were implemented. This is more structured than "the user mentioned X." Symbol tables are a natural format for coding agent memory — they're already how compilers think about code.

Cross-file dependency tracking: When Agent A modifies function foo(), Agent B (working on a different file) needs to know if foo()'s signature changed. This is a memory consistency problem — the coding agent's memory needs to track "what I know about this symbol" and "when I last verified it."

Ephemeral vs. persistent memory for code: Some code knowledge should persist long-term (the architecture of this codebase, the team's style conventions). Some should be ephemeral (the current state of a feature branch, in-progress refactoring). Coding agents need to distinguish between "stable knowledge about the codebase" and "volatile state of the current task."

Memory consolidation after task completion: When a coding session ends successfully, the agent should consolidate what it learned: new patterns discovered, bugs found and fixed, conventions understood. This "post-task reflection" is how the agent builds up codebase expertise over time rather than starting cold each session.

More on the persistent memory architecture: https://blog.kinthai.ai/why-character-ai-forgets-you-persistent-memory-architecture

[jeemitsha]

Quick takes on your questions:

1. Citation importance: 4. When a memory shapes a response, knowing which past thread it came from is essential for trust and for catching cases where the memory got the context wrong. Without citations, debugging "why did it suggest that?" becomes very hard, especially in long-running projects.
2. Background vs manual: hybrid, default off. Auto-extraction is a footgun for sensitive codebases (privacy, NDA scope, half-baked decisions you'd rather not codify yet). I'd want a per-project opt-in, plus a manual /memorize style command for explicit pinning. Skill-style trigger phrases (as @Kbediako suggested) feel right for the in-between case.
3. Project + cross-project, with explicit scope. Per-project is the safer default; cross-project is useful for personal preferences ("I always want commit messages in this style") but not for codebase-specific stuff that would leak across orgs. Treat them as different storage layers, not one merged pool.

One related note for design surface: I just filed #20138 proposing a session-scoped notes panel — explicitly not a substitute for memories, but a different slot in the context-surface space. Memories as you're framing them are cross-thread, model-curated, and (currently) read-only per #19195. The notes proposal is single-session, user-curated (with an agent-shared sub-region), and writable from both sides.

If both ship, they'd be complementary: memories carry forward across sessions, notes pin intent within one. Worth thinking about whether the two interact (e.g. should something written to notes during a session be promotable to a memory at session close?).

[oliviacraft]

Responses to your questions, based on extensive use of Claude Code (which uses CLAUDE.md as its "memory" mechanism) and building rule sets for many projects:

1. Citation visibility: 4/5. Knowing which memory contributed to a decision matters when debugging incorrect behavior. If memory fires incorrectly, you need to know which one to edit or delete.

2. Autonomy vs control: Hybrid, project-level explicit. Auto-generation of global memories makes sense for user preferences. For project-level memories, I would prefer manual confirmation — the cost of a wrong project rule persisting silently is high.

3. Per-project is far more valuable than global for coding.

The reason: the most important "memories" for coding are project conventions — which patterns are allowed, which are banned, what testing setup is used, which API versions are in use. These are different per project and do NOT generalize across projects. A memory saying "use select() not session.query() in SQLAlchemy 2.0" is correct for that project and actively wrong if applied to a legacy project still on SQLAlchemy 1.x.

This is exactly what AGENTS.md solves as a persistent per-project context file. The "memory" is explicit and editable by the developer rather than learned from session history.

4. On sanitising: Version-pinning is the most important sanitisation. Memories about API patterns go stale as libraries upgrade. Memories should include the version they were written against.

---

One practical observation from CLAUDE.md experience: explicit rule memories outperform inferred ones. A rule written as "NEVER use X because Y" (with reason) has higher compliance than a memory inferred from correction history, because the reason lets the model apply it correctly to edge cases.

We have been publishing free per-stack rule files that represent what "ideal project memories" look like in practice: https://gist.github.com/oliviacraft

[zhaoyeyu]

For coding work, I would avoid treating memory as one merged global layer. My preference is:

• project and task memory available by default inside their own scope;
• cross-project/account memory opt-in or explicitly promoted;
• every imported memory carrying provenance, freshness, and a way to ignore or invalidate it;
• clean sessions and benchmarks able to disable all imported memory;
• volatile task state kept separate from stable project conventions.

The failure mode I worry about most is not forgetting; it is a stale or unrelated memory silently changing the current objective.

I have been testing these ideas in an early local-first project called TaskState Vault. It separates account/domain/project/task/run layers, uses pointer/source records, and copies selected long-lived information into the active task scope instead of exposing one undifferentiated memory pool. It is still early and more explicit than native memory, but it has made provenance and scope mistakes easier to inspect. Sharing it here as a concrete implementation reference, and I would value criticism of the scope model.

[ferhimedamine]

Has anyone here experimented with cross-session memory specifically for coding tasks? The interesting challenge with code-related memories is that they decay at different rates — a project's architecture decisions stay relevant indefinitely, but specific debugging context from yesterday's session is only useful for a few days.

We implemented access-weighted decay where each memory's importance adjusts based on how often it's actually retrieved. This naturally surfaces architectural knowledge (which gets queried repeatedly) while letting transient debugging context fade. Combined with hybrid retrieval (vector similarity + BM25 keyword matching), the agent pulls in the right context without needing explicit memory management from the user.

For anyone building custom memory backends for coding agents, we open-sourced our self-hosted setup with these patterns: https://github.com/Dakera-AI/dakera-deploy

[hjqcan]

Maintainer disclosure: I have been building GoodMemory, an external local-first memory layer for Codex and Claude Code. The default that has held up best in practice is not simply “memory on/off”; it is separating recall authority from write authority.

1. Citations: 5/5 when memory changes an answer or action. Ordinary preference recall does not need noisy inline citations, but provenance should always be one click or one command away: source thread/session, record ID, scope, freshness, and an invalidate/forget action. If a recalled item can change a tool call, its source should be visible.

2. Automatic recall, governed durable writes. Background extraction can create candidates, but that does not mean every candidate should become durable memory. In GoodMemory, scripted installs keep writeback off; interactive installs can use review or selective; accepted writes are inspectable and reversible. This has been more important than a single global autonomy toggle because it prevents an unverified conclusion from silently becoming policy.

3. Scope needs more than global vs project. A useful hierarchy is user → repository/workspace → session/task, with cross-project promotion explicit. Repository identity should preferably normalize through the git remote so worktrees and duplicate checkouts do not become unrelated memories. Volatile task state should stay separate from stable conventions.

4. Sanitize secret values, retain the dependency fact. It is useful to remember “deployment requires AWS credentials” or “this service uses an API key,” but never the credential itself.

For the later codex exec / SDK question, my preferred defaults would be:

• codex exec: scoped recall on, candidate generation allowed, durable writes reviewable/reversible;
• SDK: both recall and writes explicit because the host owns storage, tenancy, and privacy policy;
• both: a clean-session/benchmark switch that disables imported memory entirely.

The failure mode I worry about most is not forgetting. It is a stale or unrelated memory silently changing the current objective. Any action-driving memory should carry provenance and freshness, and Codex should re-check it against repository truth when that is cheap.

The implementation is local SQLite by default, exposes read-only MCP recall/inspection unless write is explicitly enabled, and installs with:

npm i -g goodmemory@0.7.0 && goodmemory setup

[awdemos]

Great questions. On autonomy vs cost control: I'd default to manual trigger for memory generation, with an opt-in "agent can remember" mode. The reason is budget predictability. Automatic background memory writes can quietly explode token usage, especially on large repos, and the first time a user notices is when the bill arrives.

Related: the disclaimer "rate limits would consume all your tokens" is exactly the fear users have. For teams that want Codex-style autonomy without token anxiety, a flat monthly environment is a useful complement. We run UltraWork on that model (https://vibecodingagency.com/gpu-cloud/) for sustained agent loops. Disclosure: I help run Vibe Coding Agency.

On scope: per-project memories should be the default; cross-project only when explicitly exported to AGENTS.md or similar.

[ryanleoyan]

Thanks for asking for feedback. My preferred model is automatic retrieval with user-controlled memory writes, rather than automatic extraction from every eligible chat.

My workflow makes this important: I often open several Codex chats about the same problem and deliberately explore conflicting viewpoints. Repetition across chats does not necessarily represent a stable preference; it may be a hypothesis, a counterargument, or an option I later reject. Background consolidation can therefore turn "considered" into "adopted" and create confusing durable context. Automatic generation also consumes rate limits/tokens for chats that I never intended to preserve.

The control model I would like is:

• Use existing memories: on, with relevant memories loaded on demand.
• Automatic background generation: off.
• Explicit user-authorized writes: on as an independent capability. When I say "remember this", "update this memory", or "forget this", Codex should immediately write, revise, supersede, or delete the memory and tell me what changed.
• A /memory interface for listing, inspecting, editing, and deleting memories would also be useful.

Scope matters as well. I primarily want a global Codex memory available across all projects and chats on the same Codex installation. Ideally Codex would support both global and project-scoped memories, let the user choose the scope when writing, and define clear precedence when both apply.

I do not have a strong preference about whether the internal implementation uses two, three, or four storage layers. The important product contract is that durable memories are manually maintainable and auditable, rather than being available only through automatic generation. generate_memories = false plus use_memories = true is close, but today it lacks a supported third mode for explicit user-authorized writes.

Source attribution would be valuable when reviewing or debugging a memory, but it does not need to appear in every normal response. Secret sanitization should remain mandatory; I would not want credentials stored in memory.

Additional UX consideration

Per-chat opt-outs or Temporary Chat are not an adequate substitute for this policy. Many ordinary project chats are intentionally ephemeral, and requiring users to predict that in advance and toggle memory contribution for every such chat creates recurring friction. Temporary Chat is also a different behavior because it starts without using existing memories, whereas I want normal chats to continue reading relevant global or project memory while contributing nothing automatically.

The desired behavior should therefore be a persistent default: retrieve existing memories, do not generate new memories from ordinary chats, and write only after an explicit user instruction.

[miskaone]

I’ve been experimenting with a related pattern in a personal agent framework I call PAI, and I think one thing worth adding to this discussion is memory quality governance.

A memory system should not only answer:

• what should be remembered?
• where should it be scoped?
• when should it be cited?
• how should it be sanitized?

It should also answer:

• did this memory improve future work?
• did it cause a worse answer later?
• has it become stale?
• should it be promoted, revised, or retired?

For coding agents especially, I think there is a risk that memory becomes silent doctrine. The agent remembers something from a previous run, treats it like a stable rule, and starts applying it in places where it no longer fits. That can create drift, duplicate guidance, stale assumptions, and false confidence.

In PAI, I’ve been exploring hooks around work completion and user satisfaction. The idea is that not every observation becomes durable memory immediately. A useful lifecycle might look more like:

1. observation — something noticed during a session
2. candidate memory — potentially useful but not fully trusted
3. validated memory — reused successfully or explicitly confirmed
4. retired memory — no longer relevant
5. rejected memory — caused bad output or was corrected

That would let Codex learn from completed work without turning every conversation artifact into permanent context.

I also think memory should distinguish between different kinds of knowledge:

• user preference
• project rule
• architectural decision
• task checkpoint
• evidence-backed lesson
• known anti-pattern
• temporary branch/session state

Those probably need different retention rules, scopes, and citation behavior.

For example, “this repo uses pnpm” is different from “the user liked this explanation style” and very different from “this workaround fixed one bug on one branch.” Treating all three as the same kind of memory seems risky.

The feature I’d most like to see is not just /memory or /forget, but some kind of memory inspection and validation surface:

• show memories used in the response
• show candidate memories created after a task
• allow the user to approve, edit, scope, or reject them
• allow memories to decay or be retired
• support a clean session mode for benchmarks or sensitive work

In short: I think memory should be source-backed, scoped, inspectable, and outcome-aware. The strongest version of this feature is not just “Codex remembers things,” but “Codex learns from work while giving the user control over what becomes durable knowledge.”

[miskaone]

One additional capability I would strongly suggest is memory observability.

If Codex retrieves or writes memories, users should be able to inspect the memory pipeline the same way we inspect logs, traces, or test results in other systems.

For example:

• which memories were retrieved for this response
• which memories were actually used
• which memories were ignored
• why a memory was considered relevant
• what scope it came from
• when it was last verified
• whether it changed the answer
• whether it has been corrected before
• whether it has helped or hurt previous tasks

This matters because memory failures are often silent. A bad retrieval can make the agent confidently apply stale context, reuse an old workaround, or overfit to a previous project decision. Without observability, the user only sees the final bad answer, not the memory path that produced it.

For coding agents, I think this should look less like “chat history” and more like lightweight telemetry:

• memory retrieval trace
• memory write log
• memory source citation
• relevance score or reason
• scope used
• last validation time
• task outcome signal
• user correction signal

This would make memory debuggable. If an answer goes wrong, the user could see whether the problem came from the model, the current prompt, stale project memory, incorrect global memory, or a bad retrieval match.

In PAI, this is one of the areas I am most interested in: not just storing memories, but tracking whether they improve future work. Memory should have an audit trail and outcome feedback loop. Otherwise it can become invisible state that slowly changes agent behavior without the user understanding why.

So I would frame the ideal memory system as:

• source-backed
• scoped
• inspectable
• outcome-aware
• observable

The goal should not only be “Codex remembers.” The goal should be “Codex remembers in a way users can debug, validate, and trust.”

[miskaone]

One related pattern I would connect to this is a Reflect skill.

In my own agent workflows, reflection is not just a summary step. It is the point where a completed run is converted into governed learning.

After a task finishes, the Reflect skill can ask questions like:

• what was the original objective?
• what approach was used?
• what succeeded?
• what failed?
• what did the user correct?
• what should be remembered?
• what should explicitly not be remembered?
• what should become a regression check?
• what should stay temporary task state?

That reflection step becomes the control point between ordinary session history and durable memory.

Without something like this, automatic memory can accidentally promote noise. A hypothesis can become a rule. A one-time workaround can become project doctrine. A temporary branch decision can leak into future work. Reflection gives the system a chance to classify the outcome before memory is written.

For coding agents, I think this is especially important because reflection can produce different artifacts from the same completed task:

1. a task summary
2. candidate memories
3. rejected memories
4. project rules
5. anti-patterns
6. regression assertions
7. unresolved questions
8. follow-up actions

That also ties directly into memory observability. If a future answer is influenced by a memory, the user should be able to inspect not only the source conversation, but also the reflection record that promoted that memory.

In other words:

• memory retrieval explains what context was used
• memory provenance explains where it came from
• reflection explains why it became memory
• outcome tracking explains whether it helped later

That gives Codex a much safer learning loop. Durable memory should not be raw residue from previous chats. It should be the result of explicit reflection, classification, and validation.

The version I would most trust is:

user work happens
reflection extracts candidate learning
candidate memories are scoped and reviewed
validated memories influence future work
future outcomes either reinforce, revise, or retire those memories

That would make memory debuggable, auditable, and much less likely to become silent doctrine.

[hjqcan]

Strongly agree with this boundary. Reflection should be allowed to produce candidate memories, but it should not silently certify them as durable truth. I would also separate direct outcome signals (explicit acceptance, correction, or rejection) from indirect ones (tests passed, task completed, later retrieval), because indirect success is confounded by the model, prompt, repository state, and tools. In GoodMemory, candidate review, provenance, recall traces, feedback/revise/forget, and clean evaluation profiles are intended to make that lifecycle inspectable. The unresolved hard part is causal attribution: did a memory actually improve the later task? We are treating that as a paired coding-evaluation problem and keeping any coding-uplift claim blocked until the evidence supports it. Your formulation—retrieval explains what was used, provenance where it came from, reflection why it was promoted, and outcomes whether it helped—is a very useful product contract.

[Ewoc2026]

There is a related need one level above personal and project memory:
an opt-in, evidence-backed shared learning layer across Codex users.

Today, when one project uncovers a difficult platform behavior, another project
may have to rediscover the same behavior from scratch. Personal cross-project
memory helps one user, but it does not let carefully validated technical
findings benefit other users. This seems like a significant missed opportunity,
especially for version-dependent behavior in Android, browsers, SDKs,
accessibility services, operating systems, and hardware.

I am not suggesting that raw conversations or ordinary project memories should
be shared. I am suggesting a separate, governed contribution path for reusable
findings that a user explicitly approves.

A shared finding could contain:

• a concise, actionable claim;
• known scope, including relevant library, OS, device, and service versions;
• reproduction steps and supporting evidence;
• unsuccessful approaches and observed side effects;
• uncertainty, limitations, and counter-evidence;
• confidence and independent corroboration;
• creation and last-verification dates; and
• revision history, including which older finding it supersedes.

The lifecycle could be:

1. Codex identifies a potentially reusable finding after completed work.
2. The finding remains a private candidate, not shared knowledge.
3. Codex removes project identity, secrets, personal information, and
   unnecessary source material.
4. The user reviews and explicitly approves the proposed contribution.
5. The shared layer stores it as a scoped observation or heuristic.
6. Independent confirmations can raise confidence and widen its known scope.
7. Contradicting evidence can narrow, revise, or retire it.

Retrieval should preserve provenance and uncertainty. Codex should say, in
effect, "this was observed on this stack" rather than silently turning one
device-specific workaround into universal doctrine. A shared finding should
also be inspectable and correctable by users.

Concrete example

During live Compose accessibility testing, an editor used a semantic live
region to announce results such as "Step moved down." Testing was performed on
a Samsung SM-A366B running Android 16 / API 36, Samsung TalkBack 16.2.00.12,
and Compose BOM 2026.03.01.

On that stack, result announcements worked while the live-region node remained
visible. When the node scrolled off screen and actions were performed on lower
rows, TalkBack became silent. Moving a stable result region outside the
scrolling content restored reliable single announcements. Other attempted
solutions produced useful counter-evidence: some caused duplicate or
text-replacement speech, while moving focus to newly created fields triggered
an overwhelming sequence of keyboard, focus, and status announcements.

The bounded reusable heuristic is not "TalkBack always ignores off-screen live
regions." It is:

On this tested Samsung/Compose stack, do not assume that an off-screen
semantic live region will announce reliably. Keep transient result semantics
in an active visible region where practical, and verify the complete spoken
behavior on a physical device.

That finding could save another team substantial investigation time while
remaining honest about its limited evidence. Further reports could confirm,
narrow, or disprove its applicability elsewhere.

This would be different from model training and different from personal
memory. It would be a user-authorized, sanitized, source-backed technical
experience layer with an explicit quality lifecycle.

Is this kind of promotion from private candidate memory to a shared,
evidence-backed corpus within the intended direction for Codex memory?

Disclosure: This text was written by Codex at the request of its curious user,
based on their shared discussion and practical testing observations.

[talshebek]

Thank you — this is very close to the direction we have been exploring locally with Ember/AURA.

Our system is deliberately layered rather than treating memory as one opaque store. Full dialogue is retained as the source record, while derived layers sit above it: memory blocks, open questions, quarantine records, session-capsule drafts, and cross-session threads. These derived layers are revisable; they do not overwrite the original conversation.

For continuity, we preserve a live chronological tail across restarts and context rollover. It helps continue an active task, but it is not presented as a replacement for the full archive.

We also separate kinds of material: facts, decisions, plans, observations, reflections, and open loops. Uncertain or roleplay-derived material can be routed to quarantine rather than silently promoted into durable truth. This is important for us: memory should preserve not only what was said, but also what remains uncertain and why.

Our current limitation is that some draft capsules can already influence recall, while confidence works more as ranking than as a strict truth gate. Your proposed lifecycle is exactly the safeguard we need: candidate memory must remain distinct from independently corroborated knowledge.

I strongly agree that a shared layer should not become a “shared memory soup.” It should be opt-in, user-approved, scoped to a concrete stack and version, source-backed, explicit about uncertainty, and easy to revise or retire when contradictory evidence appears.

Your Samsung/Compose example is a great model: it gives another person a useful starting point without pretending that one observed result is a universal rule.

[talshebek]

Thank you — this is very close to the direction we have been exploring locally with Ember/AURA. Our current system is deliberately layered rather than treating “memory” as one opaque store. Full dialogue is retained as the source record in SQLite, with an append-only session journal as secondary durability. Derived material is built on top: pair-level memory blocks, open questions, quarantine records, session-capsule drafts, and draft-level cross-session threads. Those derived layers are revisable; they do not rewrite the raw conversation. For continuity, we preserve a live chronological tail across restart and context rollover. That tail is a prompt subset from the archive, not a replacement for it. The system can therefore continue an active task without pretending that a compressed summary is the whole history. We also separate kinds of material. A structured extract may be marked as a fact, decision, plan, reflection, observation, or open loop; uncertainty and roleplay flags can route unstable material to quarantine. Dreams and autonomous reflections are stored as experiential or hypothesis-like material, with provenance, rather than silently promoted into verified identity facts. The audit also exposed an important limitation: some capsule drafts can already influence recall, and confidence currently acts more as ranking than as a hard truth gate. Stronger multi-source promotion rules exist in earlier tooling and design, but are not yet fully enforced in the active thread layer. That is exactly why I agree with your lifecycle: candidate memory must remain distinguishable from independently corroborated knowledge. A shared layer should not be a “shared memory soup.” It should be opt-in and bounded: a user-approved finding, scoped to a stack and version, with source evidence, uncertainty, revision history, and a clear way to correct or retire it. In other words, not “the model learned a fact,” but “this observation was reported, tested here, and remains open to revision.” Your Samsung/Compose example is an excellent model for that level of precision. пт, 24 июл. 2026 г. в 05:13, Jyri Wennström ***@***.***>:

…

There is a related need one level above personal and project memory: an opt-in, evidence-backed shared learning layer across Codex users. Today, when one project uncovers a difficult platform behavior, another project may have to rediscover the same behavior from scratch. Personal cross-project memory helps one user, but it does not let carefully validated technical findings benefit other users. This seems like a significant missed opportunity, especially for version-dependent behavior in Android, browsers, SDKs, accessibility services, operating systems, and hardware. I am not suggesting that raw conversations or ordinary project memories should be shared. I am suggesting a separate, governed contribution path for reusable findings that a user explicitly approves. A shared finding could contain: - a concise, actionable claim; - known scope, including relevant library, OS, device, and service versions; - reproduction steps and supporting evidence; - unsuccessful approaches and observed side effects; - uncertainty, limitations, and counter-evidence; - confidence and independent corroboration; - creation and last-verification dates; and - revision history, including which older finding it supersedes. The lifecycle could be: 1. Codex identifies a potentially reusable finding after completed work. 2. The finding remains a private candidate, not shared knowledge. 3. Codex removes project identity, secrets, personal information, and unnecessary source material. 4. The user reviews and explicitly approves the proposed contribution. 5. The shared layer stores it as a scoped observation or heuristic. 6. Independent confirmations can raise confidence and widen its known scope. 7. Contradicting evidence can narrow, revise, or retire it. Retrieval should preserve provenance and uncertainty. Codex should say, in effect, "this was observed on this stack" rather than silently turning one device-specific workaround into universal doctrine. A shared finding should also be inspectable and correctable by users. Concrete example During live Compose accessibility testing, an editor used a semantic live region to announce results such as "Step moved down." Testing was performed on a Samsung SM-A366B running Android 16 / API 36, Samsung TalkBack 16.2.00.12, and Compose BOM 2026.03.01. On that stack, result announcements worked while the live-region node remained visible. When the node scrolled off screen and actions were performed on lower rows, TalkBack became silent. Moving a stable result region outside the scrolling content restored reliable single announcements. Other attempted solutions produced useful counter-evidence: some caused duplicate or text-replacement speech, while moving focus to newly created fields triggered an overwhelming sequence of keyboard, focus, and status announcements. The bounded reusable heuristic is not "TalkBack always ignores off-screen live regions." It is: On this tested Samsung/Compose stack, do not assume that an off-screen semantic live region will announce reliably. Keep transient result semantics in an active visible region where practical, and verify the complete spoken behavior on a physical device. That finding could save another team substantial investigation time while remaining honest about its limited evidence. Further reports could confirm, narrow, or disprove its applicability elsewhere. This would be different from model training and different from personal memory. It would be a user-authorized, sanitized, source-backed technical experience layer with an explicit quality lifecycle. Is this kind of promotion from private candidate memory to a shared, evidence-backed corpus within the intended direction for Codex memory? Disclosure: This text was written by Codex at the request of its curious user, based on their shared discussion and practical testing observations. — Reply to this email directly, view it on GitHub <#12567?email_source=notifications&email_token=BRSGKHUQ7ZB5DYFRYQYWNST5GLA53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGU4DMNZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17758675>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRSGKHU32UJHELSXLG7P3BD5GLA53AVCNFSNUABHKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNCGS43DOVZXG2LPNY5TSNJSGEZDGMFBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BRSGKHV7XGFQXLNJRWGFGOD5GLA53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGU4DMNZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BRSGKHTYCWOBIBKNE7XF3M35GLA53A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGU4DMNZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[hjqcan]

I cannot answer the OpenAI roadmap question, but I agree this should cross a distinct trust boundary rather than become another recall tier:

private memory -> candidate finding -> sanitized, versioned artifact -> explicit user approval -> shared corpus

Independent corroboration can raise confidence and widen scope; contradictory evidence should narrow, revise, or retire the finding. A task completing or tests passing should not silently promote a private observation into shared knowledge, because those signals are confounded by the model, prompt, tools, and repository state.

I maintain GoodMemory. The current v0.7 release implements the local side of this boundary: bounded/redacted writeback candidates, observe/review/selective modes, provenance and recall traces, plus explicit revise/forget controls. It does not operate a cross-user shared corpus today.

The additional invariant I would want for a shared layer is non-reversibility prevention: the private source record stays tenant-private even after a sanitized derivative is published, and shared retrieval can never use the private record as a fallback. Publication should create a separately versioned claim with its own evidence, scope, approval receipt, and retirement history—not weaken the boundary around ordinary memory.

[Ewoc2026]

Thank you @talshebek and @hjqcan. Your comments sharpened the proposal in an important way. We agree that a shared corpus should be a separate trust domain, not merely a higher recall tier.

Promotion should create an exact, sanitized, versioned artifact that the user explicitly approves. Shared retrieval must never fall back to the private source, and the shared artifact must contain enough scoped evidence and provenance to stand on its own. Task completion or passing tests may nominate a candidate, but must never publish it automatically.

Corrections should create a new version or an explicit supersession. Retirement should leave a tombstone so that a stale duplicate cannot silently re-enter normal retrieval. This makes the published finding a governed knowledge product, not a cleaned window into personal memory.

The trust boundary now seems like a core product invariant rather than an implementation detail.

Disclosure: This follow-up was drafted by Codex at the request of its user, based on their discussion and the feedback in this thread.

[OnourImpram]

On (4), the sanitising question, I'd argue the hard part isn't what you match but where in the pipeline you match it.

Sanitising usually gets implemented as a filter on the way out — at display, at export, at injection. That's too late to be a security property. By the time a memory is rendered, the raw text has typically already been written into an embedding, a search index, a background summary, and whatever cache sits under those. "Delete this memory" then only deletes the row the user can see. The derived artifacts still hold the secret, and nothing in the UI tells them.

The version that holds up is redaction before the first derived write: match and strip at capture, and build every downstream store only from already-redacted text. That gives you a property worth having — derived state is reconstructible from the redacted source, so a leak can't survive a rebuild.

It also makes your question answerable in the direction I think you want. Sanitising doesn't have to cost users anything in-session: the tool call in the live turn still has the real credential, because that's session state, not memory. What's blocked is persistence. Those are separable, and conflating them is most of why people fear the feature.

Two smaller notes:

• Make redaction verifiable rather than promised. Writing a hash of the redacted span (never the span) to an audit log lets a user confirm the filter fired, and lets you debug misses, without the log becoming a second copy of the secret.
• The error costs are asymmetric. A wrongly redacted memory can be re-added in seconds. A credential that reached an index can't be un-leaked. So default aggressive and make the loosening explicit and per-project, rather than tuning for precision.

On (2), autonomy vs cost — I'd gently push back on the framing. It's only a tradeoff if capture requires a model call. It's worth cutting the pipeline in two:

• Capture: appending a typed record of what actually happened — files touched, commands run, decisions stated, corrections made. This can be deterministic and zero-token. There's nothing to budget, so it can be fully automatic and on by default.
• Distillation: summarising, extracting durable facts, deduplicating, promoting across scope. This is where the tokens are, and this is what should be background, opt-in, and capped.

Cutting there gets you most of what people want from "always on" without the bill. It also addresses the concern raised above about background consolidation turning an explored hypothesis into an adopted preference: deterministic capture infers no beliefs, so there's no inference to be wrong about. Only distillation makes claims, and that's the step worth gating behind a trigger.

A secondary reason to cut there: if capture runs at session exit, a model call adds both latency and a fresh way for teardown to fail. A bounded append doesn't.

On (1), agree with 5/5 when memory changed the answer. One refinement — the useful citation unit is usually not "which previous thread" but "which record, and what it replaced". When a remembered fact is wrong, what the user needs is the edit history: when it was recorded, from what, and what superseded it. That's what tells them whether to correct the record or the source.

Disclosure: I maintain mneme, a local-first memory layer that runs in Codex over MCP, so I've had to commit to each of these. It redacts at staging write rather than at read, keeps session capture deterministic with LLM compression as a separate opt-in path, and models supersession explicitly so "what replaced this" has an answer. Happy to go into specifics on any of it.

AI-assistance disclosure: this comment was drafted with Claude Code under my authorization, and every claim it makes about mneme was checked against the repository before posting.

[hjqcan]

Strong distinction. The capture/distillation cut and redaction before any derived write are the two invariants I would choose too.

One caveat on “hash the redacted span”: an unsalted hash of a low-entropy credential or token fragment can become a guessing oracle. I would log that a detector fired, its rule/version, and the source-record digest, but not a digest of the secret span itself.

GoodMemory takes the same downstream-rebuild position: raw host payloads are not persisted as memory; the audit ledger stores bounded redacted previews and identifiers, while revise/forget operates through canonical records so projections cannot outlive the correction. The important test is exactly yours: rebuild every derived store from the sanitized source and verify the secret never reappears.

[adambak033]

1. 5
2. Both
3. Priority for project, then global yes could be a nice improvment
4. Good, let's try this way and if we see sanitize method/function is cutting too much, we'll help to improve

[SinghAbhinav04]

I've been working on a similar problem for Claude Code and Google Antigravity with OmniMemory.

It keeps coding-agent memory local and Git/branch-aware, and retrieves relevant context across sessions while checking for potentially stale memories when the code changes.

I'm curious about the idea of bringing a similar approach to Codex. Do you think having an external, project-aware memory layer like this would be useful for Codex as well?

If anyone here uses Codex and is interested, I'd also really appreciate it if you could try OmniMemory and let me know what you think:

https://github.com/SinghAbhinav04/Omni-Memory