Repository navigation
Local Memories should work with custom / third-party model providers #39272
Description
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:
- 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.
- 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/memoriesstore. - 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:
- Memory writer sends hardcoded gpt-5.6-luna and gpt-5.6-terra requests to non-OpenAI model providers #37009 — bug: the memory writer sends hardcoded
gpt-5.6-luna/gpt-5.6-terrato 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. - Chronicle memory writer should expose model and cost controls #26808 — Chronicle / memory-writer model and cost controls (first-party Chronicle path).
- auto-review fails with "codex-auto-review" model name not supported #31255, Guardian auto-review can select a non-servable default model id for custom providers, causing fail-closed denials #31732, Auto-review uses invalid model name "codex-auto-review" #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.
Activity
Shivang9983 commentedon Aug 18, 2026
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:
memories.extract_modelormemories.consolidation_modelare unset.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 commentedon Aug 22, 2026
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_summarizeprovider-agnostic.I ran a fresh compatibility smoke today outside the GoodMemory repository:
0.149.00.7.5from the published npm tarballHOME/CODEX_HOMEmodel_provider,base_url, andwire_api = "responses"per the Codex config referenceoffThe test explicitly wrote one reviewed fact under workspace A, then captured the actual
/v1/responsesrequest in two freshcodex execsessions:ORCHID-742occurrences in provider requestcwdcwd, same user + SQLite DBIn 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.moderemainedoff,committedTotalwas0, andlastCapturedAtwasnull.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: hjqcan/GoodMemory#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 explicitRemember 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.