Make Codex memory writability explicit when `memories = true` is enabled

[sonnyb9]

What feature would you like to see?

When the memories feature is enabled, Codex should make memory writability explicit and non-contradictory.

Right now, a direct codex launch can show memories enabled in config/features, while the model-visible prompt still injects:

Never update memories. You can only read them.

From a user perspective, that is extremely confusing. It makes the feature appear enabled but unusable.

What problem is this solving?

This creates a bad UX for users who rely on durable memory and are trying to understand whether memory is:

• enabled
• experimental
• readable only
• writable
• intentionally disabled by policy in the current session

At the moment, users can spend a lot of time checking local config and launchers before discovering that the effective behavior is controlled by an injected prompt/policy.

Suggested improvements

Any of these would be a big improvement:

1. Add a clear session-visible status for memory mode, such as:

   • memory: disabled
   • memory: read-only
   • memory: writable

2. If memories = true is enabled but writes are blocked by policy, show that clearly in the CLI/UI instead of only via hidden prompt instructions.

3. Document the difference between:

   • enabling the memory feature in config
   • actual write permission in the active session

4. If read-only memory is intentional for now, expose that as a visible product state instead of making users discover it through debug prompt-input.

5. Ideally, provide a real toggle or future supported mode for writable durable memory when the product is ready.

Additional context

Confirmed locally on a plain direct codex launch:

• Codex CLI: 0.123.0
• Subscription: ChatGPT Plus
• Platform: Linux ARM64 (Raspberry Pi)
• ~/.codex/config.toml has memories = true
• codex features list shows memories enabled
• codex debug prompt-input "test" still shows the injected line:
  Never update memories. You can only read them.

I’m not asserting that writable memory must exist today. The core request is that Codex should make the effective memory mode obvious and avoid the current contradictory UX.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• /experimental shows redundant "Memories will be enabled in the next session" warning when Memories is already enabled #18554
• Memories enabled but no stage-1 outputs generated because imported threads keep has_user_event=0 #17490

Powered by Codex Action

[hilyfux]

The UX problem here feels very real. If features.memories = true is enabled but the session prompt still says “Never update memories. You can only read them.”, users cannot tell whether memory is broken, intentionally read-only, or blocked by policy for that run. The first fix should be an explicit runtime status surface, something like memory: disabled | read-only | writable, shown in the CLI and in debug output, so the effective mode is never ambiguous.

A second improvement would be to separate three layers clearly: config flag enabled, memory pipeline active, and write permission allowed in this session. Without that, people waste time debugging config files when the real behavior is controlled by injected session policy. We ran into the same class of confusion while building knowledge-graph, which is why we leaned toward a git-native, zero-dependency layer that makes state and retrieval paths inspectable across Claude Code and Codex. Even if Codex keeps memory read-only for now, making the effective mode visible would already remove a lot of avoidable user confusion.

[jeemitsha]

+1 to the underlying confusion this issue describes — discovering that writability is gated by an injected prompt rather than the visible config flag is a real footgun, and the proposed memory: read-only / memory: writable session-visible state seems like the minimum needed to stop people from chasing config bugs that aren't bugs.

Tangentially relevant: I filed #20138 proposing a session-scoped notes surface that's writable from both the user and the agent by design. It's not a substitute for fixing the memories UX — this issue stays valid regardless — but it might be useful to think of it as the explicitly writable counterpart to memories: a different slot in the context-surface design space, rather than overloading the existing one.

[Patdolitse]

The contradiction you're describing is annoying as a UX bug, but I think the read-only default is pointing at something real. The reason a tool can ship memory enabled and then quietly refuse to write is that autonomous writes are the part nobody is comfortable turning on yet. Once an agent can durably write to its own memory without you in the loop, a single wrong inference can persist and quietly shape every later session. So the honest fix isn't only flipping the switch to writable, it's making the in-between state a real, visible product state.

The three modes you listed are the right start, but the one that matters most is a fourth. Something like memory: proposed, where the agent can suggest a new memory but it doesn't become a durable fact until you confirm it. That gives you the actual benefit people want from writable memory, which is the agent capturing useful context as it goes, without the failure mode that makes teams leave it read-only.

Agreed completely that the effective mode should be obvious in the session rather than buried in an injected prompt line. I'd just want the surfaced states to include that staged middle, because read-only versus writable on its own forces a choice between useless and risky, and the interesting part is in between.

We've spent a while building durable memory where the agent proposes and the human confirms before anything sticks, and that confirmation step is what made writable memory safe to use at all rather than a liability. The visible status you're asking for is the right surface to hang it on.

[SaravananJaichandar]

Patdolitse's framing above, that the read-only default is pointing at something real and autonomous writes are the part nobody is comfortable turning on yet, is the load-bearing one in this thread. The UX contradiction the OP is rightly flagging exists because Codex does not have a way to surface which memory writes are safe enough to allow.

There is a third state worth naming alongside the OP's disabled / read-only / writable enum: writable with provenance. The model can write to memory, but every write carries asserted_by (user versus agent) and confirmation_state (confirmed versus inferred versus superseded), and the read path weights re-injection differently for each. The agent can still write autonomously, but the next session sees the provenance and can deprecate inferences that were never confirmed.

I shipped this in world-model-mcp, an open MCP server used as an external memory layer with Codex via the v0.7.5 adapter and with Claude Code natively. Concretely:

• Writes carry confidence: 0.0 to 1.0 that decays under contradiction.
• An evidence_type enum: source_code | test | session | user_correction | bug_fix.
• A status enum: canonical | corroborated | superseded | synthesized. The last value is the key one. It explicitly marks "the model wrote this, no human ever confirmed it."

When the next session restores from memory, the injected context is weighted by these fields. A synthesized claim with confidence: 0.4 is presented as such, not as ground truth. This makes the OP's memory: writable state honest in a way the current binary toggle cannot be.

The Codex-side change this would compose with: the existing memory primitive could expose a writability tier (read-only, writable-confirmed-only, writable-with-provenance) instead of one bit. The CLI and UI status line in the OP's request becomes meaningful precisely when the underlying memory schema has those tiers to surface.

This is also the discussion happening on the external memory layer side in anthropics/claude-code#47023, which has converged on per-item provenance as a shared spec primitive across six independent memory-tool implementations.

world-model-mcp: https://github.com/SaravananJaichandar/world-model-mcp ; Codex adapter: https://github.com/SaravananJaichandar/world-model-mcp/tree/main/adapters/codex

[Patdolitse]

@SaravananJaichandar — yeah, "writable with provenance" is a way better name than what we've been calling it.

We've been building this exact thing so a few notes from the messy parts.

asserted_by / confirmation_state is close to where we landed, but we had to add who confirmed, not just whether. Codex infers something, user confirms it later in Claude Code — if confirmation is just a boolean you lose that. We stamp source_tool on every entry and track promotion separately so the read path knows the difference.

Biggest win wasn't a field though, it was the default. Every agent write lands in staging. Nothing goes to verified without the user saying yes. Sounds strict but in practice the volume of actually-worth-keeping knowledge per session is tiny — most of what an agent "learns" is debugging detail that should die with the session. And the high-confidence inferences are the dangerous ones when wrong, because they get re-injected like facts.

One thing provenance alone doesn't catch: staleness. Something confirmed six weeks ago might not be true anymore. We use domain-aware TTLs (user preferences decay way slower than debug workarounds) so "confirmed and fresh" reads differently from "confirmed but fossil." Without that the store quietly fills with stale stuff the model keeps asserting.