`/codex:transfer` always reports "did not record an imported thread" on Windows (thread is actually created)

[SUN-bef-dev]

Summary

On Windows, every /codex:transfer fails with:

Codex reported that the Claude import completed, but did not record an imported thread.
Check the Codex app-server logs for the underlying import error.

…even though the import actually succeeds: a real thread is created and a matching record (with a valid imported_thread_id) is appended to ~/.codex/external_agent_session_imports.json. The error is a false negative in the post-import lookup, so users never get their codex resume <id> command and silently accumulate one orphaned thread per attempt.

Environment

• Plugin: codex@openai-codex v1.0.6
• Codex CLI: codex-cli 0.144.2
• Node: v24.15.0
• OS: Windows 11 (x64)

Root cause

Both are in scripts/lib/codex.mjs → importedThreadIdForSource(sourcePath), which looks up the just-written ledger record using two equality checks that both fail on Windows:

const canonicalSource = fs.realpathSync(sourcePath);
const contentSha256 = sourceContentSha256(canonicalSource);
const match = records
  .filter(
    (record) =>
      record?.source_path === canonicalSource &&      // (1)
      record?.content_sha256 === contentSha256 &&      // (2)
      typeof record?.imported_thread_id === "string"
  )
  .at(-1);

(1) Extended-length path prefix mismatch. The ledger (written by the Codex binary) stores source_path with the Windows \\?\ extended-length prefix, but fs.realpathSync() in Node returns the path without it, so record.source_path === canonicalSource is never true.

ledger source_path : \\?\C:\Users\<user>\.claude\projects\<proj>\<id>.jsonl
realpathSync()     :     C:\Users\<user>\.claude\projects\<proj>\<id>.jsonl

(2) Live-file content-hash race. The Claude transcript .jsonl is a live, append-only file. content_sha256 is recorded at import time, but importedThreadIdForSource re-hashes the file after the import — and by then the transcript has grown (the transfer command's own turn is written to it), so the hash differs.

Either problem alone is enough to make the lookup return null. Verified against a real ledger: after normalizing the path, the record matches even though the current hash no longer equals the stored one.

Reproduction

1. On Windows, run /codex:transfer from an active Claude Code session.
2. Observe the "did not record an imported thread" error.
3. Inspect ~/.codex/external_agent_session_imports.json — a new record with a valid imported_thread_id is present; source_path starts with \\?\.
4. codex resume <that id> works fine.

Suggested fix

Normalize paths before comparison (strip \\?\, and on Windows unify separators + case), and treat the content hash as a preference rather than a hard requirement — fall back to the most recent import for that source:

const records = Array.isArray(ledger?.records) ? ledger.records : [];

// Strip the Windows "\\?\" extended-length prefix (present in the ledger but
// not in realpathSync output) and, on Windows, unify separators + case.
const normalizePath = (p) => {
  if (typeof p !== "string") return "";
  let s = p.replace(/^\\\\\?\\/, "").replace(/^\/\/\?\//, "");
  if (process.platform === "win32") s = s.replace(/\//g, "\\").toLowerCase();
  return s;
};

const target = normalizePath(canonicalSource);
const bySource = records.filter(
  (record) =>
    normalizePath(record?.source_path) === target &&
    typeof record?.imported_thread_id === "string"
);

// The transcript is live/append-only, so its hash can change between import and
// this lookup. Prefer an exact content-hash match, else the newest import.
const exact = bySource.filter((record) => record.content_sha256 === contentSha256).at(-1);
const match = exact ?? bySource.at(-1);
return match?.imported_thread_id ?? null;

With this change, /codex:transfer on Windows returns the correct thread and prints the expected codex resume <id> line.

[AndrewAvery7]

This is a false negative...the import actually succeeds, and the thread is created. The failure is in how the plugin looks up the thread afterward.

importedThreadIdForSource() in plugins/codex/scripts/lib/codex.mjs compares the ledger's source_path against fs.realpathSync(sourcePath) with strict equality. On Windows, Codex writes ledger entries with the extended-length path prefix, so the stored value is the JSON-escaped form of \\?\C:\Users\<you>\.claude\projects\...\session.jsonl:

{ "source_path": "\\\\?\\C:\\Users\\<you>\\.claude\\projects\\...\\session.jsonl" }

...while realpathSync returns the plain C:\Users\<you>\... form. The two never compare equal, the lookup returns null, and the command reports a failure for an import that actually worked.

You can confirm it in ten seconds: after a "failed" transfer, run codex resume and the thread is right there in the picker. Or open ~/.codex/external_agent_session_imports.json and you will see the record sitting there with the prefix.

I have opened #551 with a fix that normalizes the prefix (and the \\?\UNC\ variant) before comparing, case-insensitively on win32.

Two related gotchas that produce the same error message for different reasons, in case they are what someone else is hitting:

1. Re-importing an unchanged transcript legitimately creates no new thread (Codex dedupes on content hash), so detection that only looks for a new thread reports failure there too.
2. If codex was installed with npm -g from inside a packaged desktop app, a process spawned outside that app cannot resolve it, which surfaces separately as codex is not recognized.

If you need transfers working before the fix lands, I put the workaround in a wrapper that verifies the thread in Codex's own state DB instead of trusting the return value: https://github.com/AndrewAvery7/claude-codex-bridge