Replies: 35 comments 17 replies
|
Thanks for the hard work jif! |
SG for the other points! |
|
|
|
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 |
|
|
I am also developing an external memory system for Codex. Just a story:
https://github.com/hack-ink/elf
What are your thoughts on this? |
|
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. |
|
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. |
|
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 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 3. Project memory vs global memory Both seem important. I would structure memory in layers: • project memory – codebase structure, architecture decisions, conventions 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” 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 In practice this means: • the model focuses on reasoning and dialogue 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. 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 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 This approach keeps the memory layer small and focused while continuously improving retrieval quality for future interactions. |
|
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) 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. |
|
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 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 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. |
|
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 |
|
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. |
|
I'd say enable globally for consistent behavior controlled by config, but allow CLI override for |
|
I think memory should be available everywhere, but it should be separated by scope, not treated as one global layer. For example:
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:
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. |
|
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 AXIS:
QUESTIONS:
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”. |
|
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 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 |
|
Quick takes on your questions:
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?). |
|
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 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 |
|
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:
It should also answer:
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:
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:
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
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.” |
|
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:
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:
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:
The goal should not only be “Codex remembers.” The goal should be “Codex remembers in a way users can debug, validate, and trust.” |
|
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:
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:
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:
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 That would make memory debuggable, auditable, and much less likely to become silent doctrine. |
|
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. |
|
There is a related need one level above personal and project memory: Today, when one project uncovers a difficult platform behavior, another project I am not suggesting that raw conversations or ordinary project memories should A shared finding could contain:
The lifecycle could be:
Retrieval should preserve provenance and uncertainty. Codex should say, in Concrete exampleDuring live Compose accessibility testing, an editor used a semantic live On that stack, result announcements worked while the live-region node remained The bounded reusable heuristic is not "TalkBack always ignores off-screen live
That finding could save another team substantial investigation time while This would be different from model training and different from personal Is this kind of promotion from private candidate memory to a shared, Disclosure: This text was written by Codex at the request of its curious user, |
|
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. |
|
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:
***@***.***>
|
|
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. |
|
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. |
|
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:
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:
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. |
|
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. |
|
|
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: |
|
A question about the architecture of Codex Memory: Do you see the memory layer remaining entirely native to Codex, or could there eventually be a supported interface for an external/self-hosted memory or project-state provider? I’m asking because for coding workflows there seems to be a useful separation between:
I’ve been experimenting with the second part in Tenrec, where the project state lives locally/self-hosted outside the individual worker and only relevant validated state is routed into the next worker. So an architecture I’m curious about would look roughly like: Codex rather than trying to make one memory system own both long-term knowledge and current operational state. Would Codex Memory eventually expose a supported extension point for something like this — for example a custom retrieval/provider interface — or is the intention that external systems should stay separate and integrate only through MCP/tools? Tenrec is the project-state experiment I’m referring to: |
Follow-up after the Computer History launchThe Computer History release on August 13 improves several controls I asked for earlier: it is opt-in, supports app and website inclusion/exclusion, can be paused, exposes a reviewable timeline, and lets users reveal or delete generated local Markdown memory files. Suggested skills and automations also require user review. Those are meaningful improvements. However, it still does not provide the core contract I need: automatic retrieval with user-authorized durable writes. Once Computer History is enabled, it periodically converts interaction events into persistent memory files. The initial opt-in is therefore blanket authorization for future memory creation, rather than approval of each durable write. Inspecting or deleting an entry afterward is useful, but it is not equivalent to deciding before the system turns observed activity into durable memory. Repeated activity can still be exploratory, accidental, or part of comparing alternatives; it should not automatically become an adopted preference or fact. I would like the controls to be separated into independent capabilities:
For Computer History specifically, a review before saving to memories mode would help. Timeline summaries could remain temporary until the user selects an action such as “Save as memory,” reviews the proposed text, chooses global or project scope, and confirms the source evidence. The same interface should support editing, superseding, and deleting individual memories. A one-shot “remember/update/forget this” command should also work when I currently use Windows, where Computer History is not yet available, so this follow-up is based on the documented product behavior rather than hands-on testing. |
|
@jif-oai I use coding agents heavily, so my preferred defaults would be: 1. Citations: 5 out of 5If a memory influenced an important answer or decision, I want to see its source. I already ask agents to cite web research, files, and memories used in important answers. LLMs can be confidently wrong. Without sources, it is difficult to tell whether an answer came from current evidence, an outdated memory, or a hallucination. Long term, citations could become less prominent if the system becomes consistently good at selecting relevant memories and user behavior shows that people rarely correct them. But I would start with visibility and earn the right to make it quieter later. 2. Generation: automatic by default, with conversational controlMost users should not have to manage a memory system manually. The agent should generate memories in the background, but users should be able to tell it to store, update, promote, demote, or forget something. I would also separate small memories from larger durable knowledge. A preference can stay as a short memory. If something grows into a larger body of knowledge, the agent could ask whether the user wants to turn it into a durable file or skill and keep only a pointer in memory. That avoids repeatedly filling the context window with information that should live somewhere more structured. The ideal system learns from user corrections over time, so users need to manage it less and less. 3. Scope: both project and globalMost of my coding memories are project scoped. Architecture decisions, repository conventions, previous bugs, and local workflows should not leak into unrelated projects. Global memory still has a place for preferences that genuinely apply everywhere. Examples include always citing important claims, verifying changes before calling them complete, or using a particular communication style. The agent should usually choose the initial scope, then periodically review its memories and suggest moving them when the scope looks wrong. A background consolidation process could merge duplicates, identify stale memories, and suggest moving knowledge between global memory, project memory, durable files, and skills. 4. Sanitization: yes by defaultDo not store API keys or credential values in memory. The system can remember that a credential exists and where it is stored safely, such as Apple Keychain or a password manager, without remembering the secret itself. One additional needI would like to manage memory by talking to the agent. A dashboard can help, but the primary interface should let me inspect, correct, promote, demote, or remove memories conversationally. I also explored this through small controlled experiments in Cortex, a project I originally built for the Built with Opus 4.6 Claude Code Hackathon, run in partnership with Anthropic. One experiment improved with memory enabled. Another became worse, and lesson activation was very low. I do not treat that as proof that memory generally helps or hurts. The interesting question is whether the system can distinguish:
The positive and negative results, including the exact reports and limitations, are indexed here: Selected Technical Evidence. |
|
Follow-up since my earlier reply: I looked at a concrete reliability failure in Codex memory extraction and built a local reference design around issue #38860. The design processes oversized conversations as complete-turn chunks, checkpoints each successful chunk, splits only the chunk that exceeds the context window, and prevents incomplete coverage from entering Phase 2 consolidation. All 418 targeted tests passed. One synthetic test used a 200,000 byte conversation with a correction in the middle. The correction survived two bounded Stage 1 requests and reached the existing Phase 2 input path. This is independent work with mocked model responses, not a production benchmark. Two design questions came out of it:
Full design, test evidence, and limitations: |
|
My vote: Phase 2 should require complete source coverage for any output that can influence durable recall. Partial Stage 1 output is still valuable, but only as a resumable checkpoint or quarantined candidate, never as ordinary consolidation input with an incomplete flag attached. Soft warnings tend to disappear once later stages start consuming the same shape.\n\nI would bind each checkpoint to covered turn intervals, a source digest, and the extractor/config identity. Resume only when those identities still match; otherwise recompute. Turn-aligned splitting is the right default. If one turn alone exceeds the window, split inside that turn, record segment coverage, and require the union to cover the source before promotion.\n\nIf partial availability is a product requirement, keep it in a separate explicitly incomplete lane that consumers must opt into. The durable lane should fail closed and retain the last complete generation. GoodMemory uses the analogous rule for derived projection rebuilds: validate source/derived coverage, publish atomically, and keep recall on the canonical fallback until a complete generation cuts over: https://github.com/hjqcan/GoodMemory/blob/v0.7.5/docs/GoodMemory-First-Principles-and-Reference-Architecture.md#L707-L712\n\nDisclosure: I maintain GoodMemory. I am applying the same completeness invariant here, not claiming that this independently validates the proposed Codex implementation. |
|
Answering the four directly, from having shipped this across twenty agents and then measured what people actually did with it. Citations: 5. Not for the user's benefit first — for the model's. An uncited memory is an assertion the model has to either trust or ignore, and it does not have a good way to choose. A cited one is evidence it can weigh, and it can go read the original when the summary is not enough. The cheap version is session id, date and which agent it came from on every recalled item; that alone changes how the model treats it. Background, but silent. The autonomy-versus-cost framing has a third option that removes most of the cost: recall automatically, and inject nothing when the history has no answer. In ours the common case at any injection point is that nothing is added at all. The expensive design is not "automatic", it is "automatic and always says something" — that is what trains people to ignore the block. Manual triggering solves cost by making the feature depend on the user remembering it exists, which is the same failure as no feature. Worth adding: the moment matters more than the volume. Session start is the obvious one, but the two that earn their tokens are before a command runs (what invocation does this project actually use) and after one fails (what was run after this same error last time, in the sessions where it did not come back). Those are narrow, answerable questions with an obvious wrong answer if you get them wrong. Both, and project identity is subtler than it looks. Environment facts are per project; "how does this machine run X" and "what fixed this error" are per machine and travel across projects — the error you hit here is one you already solved somewhere else on the same laptop. One trap on the project side: a git worktree has a different path from its checkout, so path-keyed project identity splits one repository into several. On sanitising, since you plan it. Patterns catch the named shapes — AWS keys, Context: https://github.com/vshulcz/deja-vu, |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hey folks,
I'm working on adding memories into Codex and I would love you opinion on:
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
All reactions