This document records the follow-up lane that closed the initial Codex gap.
For the current receiver-side surface and UX contract, see
docs/codex_surface_contract_spec.md.
Lock in the currently working Codex-to-agentmemory integration with explicit compatibility coverage, clearer documentation, and an optional path for query-aware context ranking.
This work is not about proving that Codex can talk to agentmemory in principle. That is already true in the current environment. This work is about reducing future drift and making the integration legible and testable.
Three follow-up tracks:
- Codex payload compatibility test coverage
- Codex-native integration documentation
- Optional query-aware ranking in
mem::context
Observed reality:
- the current forked Codex session is configured to use
agentmemory - Codex session identity and lifecycle payloads are reaching the live
agentmemoryservice - current-session turns are retrievable immediately through the freshness path
- the fork's adapter emits Codex-shaped lifecycle events that are translated to
agentmemoryobservation payloads
Current gap:
- this compatibility is proven by runtime evidence, but it is not pinned by an explicit repo-side contract test
- repo docs do not clearly distinguish generic Codex MCP/REST usage from a
fork that posts native lifecycle events directly into
agentmemory mem::contextis freshness-oriented, but does not currently use an optional retrieval query even when an upstream adapter can provide one
Add one focused test that proves agentmemory correctly handles the payload
shape emitted by the current Codex fork.
The test should simulate a realistic Codex lifecycle using the existing
agentmemory API or registered functions.
Minimum sequence:
- start a session
- submit a user prompt with
turn_id - capture at least one tool event with
turn_id - capture an
assistant_resultevent withassistant_text - capture a
stopevent withlast_assistant_message - request
mem::context
- the turn capsule is created for the supplied
turn_id - the capsule contains the user prompt
- the capsule contains the final assistant conclusion
- the session working set is updated to the latest completed turn
mem::contextreturns the completed turn immediatelyassistant_resultandstopare both accepted without breaking capsule completion semantics
Representative Codex-style fields to preserve:
session_idturn_idcwdmodeltool_nametool_use_idcommandor structured tool inputtool_responseassistant_textlast_assistant_messageis_final
- do not build a full integration harness against the external Codex repo
- do not duplicate all freshness tests under a Codex-specific name
- do not introduce Codex-specific business logic into
agentmemory
Document the difference between:
- Claude Code native hook/plugin integration
- Codex forks that post lifecycle events directly to
agentmemory - generic MCP/REST-only agent integrations
Docs should make it obvious that these are different integration levels.
Recommended framing:
Claude Code- native hook/plugin path shipped in this repo
Codex forks- native adapter path if the fork emits compatible lifecycle events into
/agentmemory/observeand uses/agentmemory/context
- native adapter path if the fork emits compatible lifecycle events into
Generic Codex / MCP clients- MCP or REST path only
agentmemoryaccepts native lifecycle payloads from a compatible Codex adapter- this is distinct from the standalone MCP server path
- the standalone MCP server should not be described as equivalent to native session capture
- Codex-native lifecycle capture depends on the host fork, not on a plugin shipped by this repo
- README.md
- optionally a small dedicated section under
docs/if README becomes noisy
Allow mem::context to use an optional query signal when an upstream adapter
provides one, without regressing the default freshness-oriented behavior.
The Codex adapter already has a natural place to supply retrieval intent during
mid-session recall. Today mem::context mostly ranks by session continuity,
recency, and freshness signals. That works, but it ignores useful retrieval
intent when it is available.
Extend mem::context input to accept:
query?: string
The HTTP surface may continue to accept the same optional field.
When query is present:
- hot, warm, and cold lane candidates may receive lightweight ranking boosts from overlap with the query
- file overlap, concept overlap, prompt similarity, and graph entity overlap may contribute to ranking
- freshness still dominates over old durable memory for immediate follow-ups
When query is absent:
- behavior should remain materially unchanged from current retrieval freshness
- do not make the query mandatory
- do not let cold durable memory swamp current-turn freshness
- do not turn
mem::contextinto a second copy ofmem::search - keep graph as a supporting signal, not the primary source of freshness
- a query mentioning a file or concept should reorder otherwise similar recent candidates in a predictable way
- same-session latest-turn context should still appear even when the query is weak or noisy
- behavior without a query should match current tests closely
- Add the Codex payload compatibility test
- Update Codex-native integration docs
- Add optional query-aware ranking to
mem::context
This follow-up lane is done when:
- a dedicated test proves compatibility with the current Codex payload shape
- docs clearly distinguish native Codex adapter usage from generic MCP/REST
mem::contextoptionally accepts a query without regressing freshness- default retrieval behavior remains stable when no query is supplied
- implemented
- implemented
- implemented
mem::contextaccepts optionalqueryparameterprompt_submithook fires context refresh with user prompt as queryPOST /agentmemory/context/refreshendpoint added- query scoring normalizes term overlap, skips noise words, hard-partitions matched vs unmatched blocks
- lane budgets shift from 40/30/30 to 20/40/40 when query is present
- consolidated memories (KV.memories) now included in cold lane
- memory usefulness feedback loop adjusts strength on session end