›_ Codex Issues
Codex Issues / #39272

Local Memories should work with custom / third-party model providers

Open 💬 2 comments Opened Aug 18, 2026 by ropepop

What variant of Codex are you using?

App and CLI

What feature would you like to see?

Local Codex Memories should work when the active model comes from a custom model_provider, not only from first-party ChatGPT / OpenAI models.

Memories can already be turned on ([features] memories = true, plus memories.generate_memories / memories.use_memories). The missing piece is first-class support for that pipeline on custom providers.

Today the write path is built around first-party OpenAI model IDs:

  • Default memory extraction model is hardcoded gpt-5.6-luna
  • Default memory consolidation model is hardcoded gpt-5.6-terra
  • Only Amazon Bedrock overrides those preferred-model methods. Other custom providers inherit the OpenAI IDs.

memories.extract_model and memories.consolidation_model exist as overrides, but there is no provider-aware default that uses the active session model. If those overrides are unset, memory jobs are sent as gpt-5.6-luna / gpt-5.6-terra through whatever provider is active.

The pipeline also assumes first-party surfaces that a custom provider does not have, including a unary /v1/memories/trace_summarize call and an x-openai-memgen-request header on consolidation traffic.

What I would like:

  1. When the active provider is not first-party OpenAI, memory extraction and consolidation should default to the active session model, or to another model on that same provider — not to hardcoded ChatGPT model IDs.
  2. Memory use should work in threads that are running a custom-provider model the same way it does for ChatGPT models: inject and search the local ~/.codex/memories store.
  3. Generating and applying local memories should not require first-party-only APIs or headers.

In short: if Memories is enabled, a custom-provider session should both contribute to local memory and be able to use it.

Additional information

Related, but not the same request:

  • #37009 — bug: the memory writer sends hardcoded gpt-5.6-luna / gpt-5.6-terra to non-OpenAI providers. That is the silent-wrong-ID case. This issue is the product request: make Memories work end-to-end on custom providers.
  • #26808 — Chronicle / memory-writer model and cost controls (first-party Chronicle path).
  • #31255, #31732, #36094 — same hardcoded-preferred-model class on the approval-review path (codex-auto-review).

Official Computer History docs already say that feature is not available with an API key or Amazon Bedrock. This request is about the separate local Memories store under ~/.codex/memories, which is configurable on App and CLI but still assumes first-party models for generation.

I searched existing issues and did not find a feature request for Memories to work end-to-end with custom / third-party model providers. #37009 is the closest, and it is a bug about the default IDs rather than this product request.

Environment: Codex App 26.810.52044, CLI 0.147.0, macOS arm64. Memories feature enabled.

View original on GitHub ↗

2 Comments

Shivang9983 · 9 days ago

Hi @ropepop thanks for opening this detailed feature request.

Making local memory generation provider-agnostic makes total sense. We can tackle this in two steps:

  1. Fallback Resolution: Update the memory worker configuration to resolve default extraction and consolidation models from the active session provider/model whenever memories.extract_model or memories.consolidation_model are unset.
  2. Provider-Agnostic Prompt Flow: Decouple the memory pipeline from proprietary endpoints/headers by introducing a standard chat-completion summarization strategy for third-party providers.

I would love to help implement the fallback resolution and provider-aware model selection. @maintainers let me know if this direction aligns with the roadmap!

hjqcan · 5 days ago

A provider-independent parallel workaround is available for users who need scoped cross-session context while this native Memories request remains open: GoodMemory 0.7.5 (disclosure: I maintain it). It does not repair Codex's native extraction/consolidation pipeline or make /v1/memories/trace_summarize provider-agnostic.

I ran a fresh compatibility smoke today outside the GoodMemory repository:

  • Codex CLI 0.149.0
  • GoodMemory 0.7.5 from the published npm tarball
  • isolated HOME / CODEX_HOME
  • a loopback custom provider configured with model_provider, base_url, and wire_api = "responses" per the Codex config reference
  • GoodMemory writeback set to off

The test explicitly wrote one reviewed fact under workspace A, then captured the actual /v1/responses request in two fresh codex exec sessions:

| Run | Stored facts in scope | ORCHID-742 occurrences in provider request |
| --- | ---: | ---: |
| same absolute cwd | 1 | 1 |
| different absolute cwd, same user + SQLite DB | 0 | 0 |

In the same-workspace request, the marker appeared once in a developer message headed Developer memory notes:. The unrelated workspace received only the empty heading. Both Codex turns completed through the custom Responses provider. After both runs, writeback.mode remained off, committedTotal was 0, and lastCapturedAt was null.

Reproducible fixture, exact commands, sanitized request summaries, and SHA-256 receipts: https://gist.github.com/hjqcan/565d7d1058420fdb36c53d52eac2ff87

Non-maintainer real-provider test cohort and reporting matrix: https://github.com/hjqcan/GoodMemory/discussions/13

Minimal setup boundary:

npm install -g goodmemory@0.7.5
goodmemory setup --host codex --activation-mode global --writeback off
goodmemory status codex --workspace-root "$PWD"

One useful finding from the smoke: a casual declarative sentence was rejected by the rules-only explicit writer (accepted: 0, rejected: 1); the explicit Remember that ... form was accepted (accepted: 1). I would keep that rejection visible rather than presenting every write attempt as successful.

Published Codex setup contract: https://github.com/hjqcan/GoodMemory/blob/v0.7.5/docs/GoodMemory-Codex-Handoff-Setup-Guide.md

Evidence limits: the provider returned a fixed deterministic response and Codex warned that its synthetic model id used fallback metadata. This proves hook/request compatibility and workspace isolation with a custom Responses provider; it does not prove native Memories compatibility, model usefulness, or independent adoption. If someone tries it with a real third-party provider, please record the provider, exact Codex/GoodMemory versions, same-vs-other-cwd result, and whether any startup/turn performed an unintended write.