`/codex:transfer` is one-shot per session: a second run silently imports nothing, and is indistinguishable from failure

Title

/codex:transfer is one-shot per session: a second run silently imports nothing, and is indistinguishable from failure

Summary

externalAgentConfig/import records a session by source_path and will not import the same path again. A Claude session is a live, growing file, so the transfer only ever captures the state at the moment it first ran. Continuing to work in Claude and running /codex:transfer again adds nothing to the Codex thread and writes no new ledger record.

On Windows this compounds with #618: the second run prints the same did not record an imported thread error, so there is no way for a user to tell "already imported, nothing to do" from "the transfer failed".

Environment

• Plugin codex@openai-codex 1.0.6
• Codex CLI 0.153.4
• Node 22.19.0
• Windows 11 x64

Evidence

~/.codex/external_agent_session_imports.json after many transfers across several projects:

ledger records            : 46
distinct source paths     : 46
sources imported more once: 0

Not one source path has ever produced a second record. On a re-run of an already-imported session the completion notification still fires, so nothing surfaces as an error, but the record count does not move and the thread is unchanged.

Steps to reproduce

1. In a Claude Code session, run /codex:transfer. A thread is created.
2. Keep working in Claude for several more turns.
3. Run /codex:transfer again.
4. Compare records.length in external_agent_session_imports.json before and after: unchanged. The Codex thread still ends at step 1.

Why it matters

The obvious use for transfer is hitting a usage limit and continuing in the other tool. That is rarely a single moment: you switch, work, and switch back. Today the thread is frozen at the first transfer, so the second switch carries none of the work done in between, and the user is not told.

Possible resolutions

Any one of these would help, roughly in order of effort:

1. Report the state honestly. If the path is already in the ledger, say "already imported as <id>, nothing new was carried" rather than failing. Cheap, and removes the confusion with #618 entirely.
2. Allow re-import to a new thread, keyed on path plus content hash rather than path alone, so an updated transcript is treated as new material.
3. Append to the existing thread, carrying only the turns added since the recorded content_sha256. This is what the feature actually wants to do.

Related

• #618, #514, #417: the Windows lookup failure that makes this indistinguishable from an error.
• #701, #469: fixes for that lookup, still open.

Note on a workaround

While waiting on the above I wrote a small tool that does the incremental case: https://github.com/bloodykheeng/ai-context-relay

It keeps a Claude session and a Codex thread in step in both directions, and carries tool calls, their output and pasted screenshots, which the import does not. Codex still creates the thread through the same externalAgentConfig/import call; the tool only appends to the session file afterwards.

Stating the obvious caveat: appending to Codex's session files is not a supported interface and will break if the rollout format changes. It is a stopgap, not a fix.

Start by tracing the externalAgentConfig/import entry point and how ~/.codex/external_agent_session_imports.json records source_path and content_sha256. Compare the second-transfer path with the Windows error discussed in #618, then establish which proposed behavior is intended; done means repeated transfers report their state or carry new content without silently appearing successful.