Memory is enabled in config, but runtime injects read-only memory instructions that block saving learnings

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

Not relevant / not sure this is subscription-specific.

Which model were you using?

gpt-5.5 with model_reasoning_effort = "xhigh"

What platform is your computer?

Fedora Linux:

Linux fedora 6.19.14-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 23 17:34:07 UTC 2026 x86_64 GNU/Linux

What issue are you seeing?

Codex appears to have memory enabled in ~/.codex/config.toml, and the memory plugin is installed/enabled, but the assistant receives a runtime memory instruction that explicitly forbids writing memories:

Never update memories. You can only read them.

This creates a confusing and arguably broken user experience:

• The user expects Codex to remember reusable learnings across sessions.
• ~/.codex/config.toml has memories enabled.
• claude-memory@Claudest is enabled and exposes an extract-learnings skill whose purpose is to persist learnings.
• But the model must refuse to write memory because a higher-priority runtime instruction says memory is read-only.
• The assistant cannot point to a local config file that generated this behavior; searching ~/.codex and the repo only found the phrase in the session log, not in config.toml or project instructions.

The practical impact is that users believe memory is configured, while Codex is forced to say it can only read memory and cannot save new learnings.

Relevant config

Sanitized excerpt from ~/.codex/config.toml:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"
personality = "pragmatic"
plan_mode_reasoning_effort = "xhigh"

[features]
memories = true

[plugins."claude-memory@Claudest"]
enabled = true

What steps can reproduce the bug?

1. Configure Codex with memory enabled:

``toml
[features]
memories = true
``

1. Enable a memory plugin, in this case:

``toml
[plugins."claude-memory@Claudest"]
enabled = true
``

1. Start a Codex session.
2. Ask Codex to save a reusable learning for future sessions, for example after discovering a workflow gotcha.
3. Codex refuses or hedges because the runtime context contains:

``text
Never update memories. You can only read them.
``

1. Search local config files for the source of that rule:

``sh
rg -n "Never update memories|You can only read them" ~/.codex <repo>
``

In my case, the only match was in the Codex TUI session log, not in user-editable config.

What is the expected behavior?

If features.memories = true and a memory-writing capability/skill is enabled, Codex should be able to persist user-approved learnings, or at least request approval before writing memory.

If memory is intentionally read-only, Codex should expose that state clearly and explain where it comes from, for example:

• a visible config value,
• a CLI flag,
• an approval/sandbox mode,
• an enterprise/admin policy,
• or a UI/status indicator.

Ideally /status or an equivalent diagnostic should show something like:

Memory: enabled, read-only
Reason: <policy/config/source>
Writable memory paths: none
Readable memory paths: ...

What do you see instead?

Codex receives contradictory signals:

• config says memories are enabled;
• memory plugin is enabled;
• memory skill describes persisting learnings;
• runtime instructions tell the assistant never to update memories.

The assistant then has to tell the user it cannot write memory, while the user reasonably expects memory writes to work.

Additional information

This is not about asking Codex to write arbitrary project files. The issue is specifically about Codex memory behavior and the visibility/control of the policy that makes memory read-only.

Related issues I found before opening this:

• #18343 discusses scoped memory management.
• #17496 discusses memory read-path/project-scope behavior.
• #13013 requested optional cross-session/project memory.

I did not find an exact issue for the contradictory state where memory is enabled in config but the runtime injects a non-user-visible read-only memory instruction that blocks memory writes.