Support full Codex response_item transcripts and per-project tag overrides

[Damin-Lee]

Context

We maintain a multi-agent configuration repo that currently vendors a Codex Supermemory integration. Now that supermemoryai/codex-supermemory is official, we want to retire our local fork/overlay and use the official package directly.

Two integration gaps are blocking a clean migration.

1. Codex response_item transcript coverage

src/services/transcript.ts currently parses:

• event_msg.payload.type === "user_message"
• event_msg.payload.type === "assistant_output_text"
• response_item assistant messages with payload.role === "assistant"

Recent Codex JSONL transcripts also contain important data as response_item entries:

• payload.type === "message" with role: "user" and content[].type === "input_text"
• payload.type === "message" with role: "assistant" and content[].type === "output_text" or text
• payload.type === "function_call"
• payload.type === "function_call_output"

If the transcript is mostly response_item records, automatic capture can miss user intent and tool context. Our local overlay normalized these records into a Claude-like user/assistant/tool_use/tool_result shape before formatting.

Suggested behavior:

• Treat response_item.payload.type === "message" for both user and assistant.
• Extract input_text, output_text, and text blocks.
• Optionally include tool call names and bounded tool results, with filtering/truncation.
• Add unit fixtures for Codex JSONL containing user message, assistant message, function_call, and function_call_output records.

2. Per-project container tag override

The official default project tag is currently codex_project_<hash(basePath)>, with optional projectContainerTag in ~/.codex/supermemory.json.

For teams running multiple local agents, a stable shared per-repo tag is useful. Our setup uses the same tag across Claude Code, Codex, and Hermes:

proj_<basename(git root) lowercased and non-alnum collapsed to _>

Example:

/Users/me/.hac -> proj_hac

The current global config file can set projectContainerTag, but it is not ergonomic for users who work across many repos because the desired value changes per repository.

Suggested options:

• Support an env override such as SUPERMEMORY_CODEX_PROJECT_CONTAINER_TAG.
• Or support repo-local config discovery, e.g. <repo>/.codex/supermemory.json or <repo>/.codex/.supermemory-codex/config.json.
• Or expose a documented tag strategy option such as projectTagStrategy: "repo-name" | "hashed-path" plus containerTagPrefix.

Why this matters

With those two changes, downstream configs can remove local patches and rely on the official package while preserving:

• accurate capture from current Codex transcripts;
• memory continuity with existing project tags;
• shared memory buckets across multiple coding agents in the same repo.

Happy to test a PR or provide fixtures from our local overlay if helpful.

[Dhravya]

Hey @Damin-Lee, we are working on it!

[Necmttn]

I checked current src/services/transcript.ts and the risky gap is that response_item is still treated as an assistant-text fallback. I would make response_item the primary Codex transcript shape and then de-dupe legacy event_msg entries around it.

Suggested fixture set:

• response_item.payload.type === "message" with role: "user" and input_text blocks.
• assistant messages with both output_text and text blocks.
• function_call preserving call_id, name, and bounded/hashed args.
• function_call_output paired by call_id with truncation metadata, not unbounded output.
• mixed legacy event_msg + current response_item so the same turn is not saved twice.

For project tags, I would make precedence explicit: env override, then repo-local config, then global ~/.codex/supermemory.json, then hashed git root. That keeps the current global behavior but gives teams a stable per-repo tag without editing one global file for every checkout.

---

Generated with ax.