```Never update memories. You can only read them.```Is this type of instruction part of your future roadmap, or is this simply an error?

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

• #14742

Powered by Codex Action

If your goal is to kill off the memory system, what is your alternative solution?
What is OAI currently planning to use internally to remember these capabilities so we don’t have to keep reinventing the wheel?
Are we expected to go back to maintaining a skills pool?

The memory feature is still under development. We're not accepting any bug reports on it at this time. Please wait for it to reach the "experimental" phase before playing with it.

Confirming this is still happening for me on a plain direct codex launch, and it does not appear to be caused by OpenClaw or a shell wrapper.

Environment:

• Codex CLI: 0.123.0
• Subscription: ChatGPT Plus
• Platform: Linux ARM64 on Raspberry Pi
• Launch method: typed codex directly in a shell

What I verified locally:

• ~/.codex/config.toml already has [features] memories = true
• codex features list shows memories enabled
• I do not launch Codex through OpenClaw for this workflow
• The local codex launcher is just the stock CLI wrapper around the native Codex binary

Most importantly, I ran:

codex debug prompt-input "test"

and the model-visible prompt still included the injected instruction:

Never update memories. You can only read them.

So from the user side, this looks like a session/prompt policy restriction rather than a missing local config toggle.

Feedback on the behavior itself:

• If this is intentional product policy, it is still a bad experience for users who explicitly rely on durable memory.
• memories = true strongly suggests that memory should be usable, so having the session prompt hard-block all memory writes is confusing and feels contradictory.
• At minimum, this probably needs a clear documented explanation and a visible toggle/state so users know whether memory is writable in their current session.

I’m not assuming intent here, but I wanted to add another confirmed repro and a vote that users do not like this policy in its current form.

I’m deeply frustrated by how this has been handled. The current state of Codex memory is confusing and, frankly, unacceptable for users who built workflows around it.

If memory is still under development, then memories = true should not imply a usable/writable memory system while the effective prompt hard-blocks writes with Never update memories. You can only read them. That contradiction wastes users’ time and makes us debug local config, caches, and launchers when the real behavior is controlled by an injected policy.

The minimum acceptable fix is to expose the effective runtime state clearly: memory: disabled, memory: read-only, or memory: writable. If writable memory is not supported yet, say so directly in the UI/CLI and documentation, and provide a supported migration or workaround for users relying on durable memory.

The current transition feels careless: the feature is advertised/configurable, but the actual behavior is blocked without a clear explanation. Please either make it writable, mark it explicitly read-only, or remove the misleading toggle until it is ready.

@sunrisever, the memories feature is now marked experimental, so if you'd like to report bugs against it, you're welcome to do so. We discourage users from filing bugs against features that are still marked "under development" because it creates unwelcome and unnecessary noise for the Codex team. That's why I closed this bug report when I did.

I’m deeply frustrated by how this has been handled. The current state of Codex memory is confusing and, frankly, unacceptable for users who built workflows around it. If memory is still under development, then memories = true should not imply a usable/writable memory system while the effective prompt hard-blocks writes with Never update memories. You can only read them. That contradiction wastes users’ time and makes us debug local config, caches, and launchers when the real behavior is controlled by an injected policy. The minimum acceptable fix is to expose the effective runtime state clearly: memory: disabled, memory: read-only, or memory: writable. If writable memory is not supported yet, say so directly in the UI/CLI and documentation, and provide a supported migration or workaround for users relying on durable memory. The current transition feels careless: the feature is advertised/configurable, but the actual behavior is blocked without a clear explanation. Please either make it writable, mark it explicitly read-only, or remove the misleading toggle until it is ready.

我该怎么说呢？这确实迷尔八噔的。
我现在在 linux 自己改造并使用 codex app，然而我发现，记忆这个功能始终在 Tibo 的统治下，不可用。虽然 Tibo 很喜欢重置额度，这样我的两个 pro20x 账号就能在 fast+5.5-high 下无限制的跑。
但是你应该自己去动代码了，兄弟。
自己 fork 自己改吧，或者自己写个 actions bot，每次新的 release 来了，自动拉取对应平台的源码，自己改动这句话，自己打包自己安装吧。
这玩意是开源的，本质上 codex app 只要你不分发，它其实上也是“开源的”。
但是我现在更习惯使用 skill 和 fork 功能来取代记忆。记忆这个东西，每次都需要 rg，又不是 RAG，本质上效率很低的。
我自己的经验是：我会把记忆功能的这句话改成 trigger/hooker，只有当我提及“记忆持久化一下”的时候，我的 codex 才敢去动全局记忆。
我更习惯用项目记忆文件夹和笔记本，配合超大的复杂多层级索引 skill，这样的效率貌似对 rg 来说更高一些。
fork 也好用，探索够了就 fork 一下，让这个版本的上下文留下来。但是让 gpt 在 258K（实际 272K）得短的可怜的上下文中工作来说，并不简单，很经常就 compaction 了，但看似是为了解决 5.4 的上下文漂移问题（也是我提的第一个 issue），但是我实际花钱去调用 api，用那个 1M 的 context window，虽然上下文漂移不严重了，甚至说解决了，但 5.5 可怜的召回率依然再攻击我(ಥ_ಥ)，所以我还是用 pro20x 在 codex 中的 400K 上下文实际工作。
没关系，这只是 Tibo 的一个小迷思。codexcli 是开源的，MIT 协议，你爱怎么改怎么改。

@sunrisever, the memories feature is now marked experimental, so if you'd like to report bugs against it, you're welcome to do so. We discourage users from filing bugs against features that are still marked "under development" because it creates unwelcome and unnecessary noise for the Codex team. That's why I closed this bug report when I did.

First of all — really appreciate what you’ve built here.

Codex has basically become my main tool now. For my workflow, it’s already replaced Claude Code / Claude Desktop. GPT-5.5 is seriously impressive. The new compression approach fixes a lot of the context drift issues from GPT-5.4, and honestly, limiting the “1M context” back down to ~272K input tokens feels like a much more practical setup for real use.

Also — I literally just spent another $200 on a Pro20x subscription the other day, and then Tibo reset the quota again 😂
Didn’t expect that, but I appreciate it. Thanks.

---

1. Browser use in Codex App

I get the direction — moving Atlas capabilities into Codex, making it a kind of “super app.” That makes sense.

But right now, the built-in browser use is still not as good as Chrome DevTools MCP or Playwright MCP.

A few things I’ve noticed:

• Some interactions don’t work properly (e.g. buttons that open new windows via JS).
• Stuff that works fine in Atlas behaves inconsistently here.
• The embedded browser just feels… not quite finished.

Since Codex App is an Electron app (I’m mainly on Linux, but friends on macOS see similar issues), it feels like browser capabilities should be relatively straightforward to get right.

So this gives the impression that either:

• the implementation isn’t fully there yet, or
• the plugin / prompting layer still needs work.

My guess is this probably needs more iteration, especially around edge-case handling and prompt engineering.

---

2. Feature flags are kind of confusing

The current feature system is honestly hard to reason about.

Right now it feels like everything is mixed together:

• stable
• experimental
• under_development
• deprecated
• even removed stuff（wtf…）

But none of this is clearly reflected in config.toml, and it’s hard to tell what’s actually active at runtime.

What would help:

• List all features clearly under [features] in config.toml with explicit true/false values.
• Indicate status (stable / experimental / deprecated) in a visible way.
• Maybe add a simple “Features” panel in the Codex App UI to toggle experimental stuff.

Honestly, with GPT-5.5, this kind of panel feels like something that could be built very quickly.

Right now, the lack of clarity makes it feel a bit like feature states aren’t fully audited or consistently managed.

---

Other small things

• Codex is now my main tool — I’ve stopped paying Anthropic entirely.
• Would really like to see an official Linux version soon.

I know the usual answer is “just use CLI,” but if CLI was enough, I wouldn’t still be trying to use GUI. They solve different problems.

---

Overall

Really like where Codex is going. These are mostly polish / clarity issues, not fundamental problems.

Looking forward to what’s next.

And yeah — thanks again to Tibo for the quota reset 😄
You guys are basically carrying the application layer for OpenAI right now.

Even though the issue was closed pretty quickly when I first brought this up 😅, it’s still clear that you’re much more willing than Anthropic to listen to feedback from users and the developer community.