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.

[aurexav]

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?

[aurexav]

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.

hack-ink/ELF#76 (comment)