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

[bloodykheeng]

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 /codex:transfer always fails on Windows: ledger lookup can never match (verbatim \?\ paths + hash of a live transcript) #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

• /codex:transfer always fails on Windows: ledger lookup can never match (verbatim \?\ paths + hash of a live transcript) #618, /codex:transfer is broken on Windows: false "did not record an imported thread" error, and no-arg auto-detection always fails #514, /codex:transfer fails with "did not record an imported thread" for both auto-detected and explicit --source #417: the Windows lookup failure that makes this indistinguishable from an error.
• fix(transfer): resolve imported thread id on Windows and surface import failures #701, fix: resolve imported transfer threads when the ledger record diverges (#417) #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.