codex-plugin-cc Windows 오류 해결: /codex:transfer 재이전

/codex:transfer를 실행했는데 세션을 찾지 못했다는 오류가 나왔다. 가져오기 기록을 열어 보니 Codex 세션은 이미 만들어져 있었다.

Codex reported that the Claude import completed, but did not record an imported thread.

경로 비교를 고쳐 최초 이전에 성공했지만, 같은 대화를 다시 넘기자 오류가 또 발생했다. 두 번째 실패는 원인이 달랐다. Claude와 Codex 양쪽에서 대화를 이어 쓰면서 기록이 갈라져 있었다.

이 글은 두 문제를 조사하고, 기존 기록을 보존하면서 최신 대화를 다시 가져오기까지 확인한 과정이다.

검증 환경

2026년 10월 18일 다음 환경에서 시험했다.

Claude Code의 -p 비대화형 모드에서 실제 플러그인 명령을 호출했다. 재개 확인에는 codex exec resume을 사용했다.

수정 전 파일을 백업하고 설치된 플러그인 캐시에 패치를 적용했다. 아래 변경은 개인 환경의 로컬 수정이며, 공식 배포본에 반영된 변경은 아니다.

설치 과정과 코드 리뷰 결과부터 보려면 공식 플러그인 설치·검증 글을 참고하면 된다.

같은 파일인데 경로 문자열이 달랐다

가져오기 기록에 저장된 경로와 플러그인이 비교하는 경로는 다음과 같았다.

가져오기 기록:
\\?\C:\Users\...\session.jsonl

플러그인이 비교하는 경로:
C:\Users\...\session.jsonl

\\?\는 Windows 확장 경로 표기에 사용하는 접두사다. 이번 사례에서는 같은 파일을 가리켰지만, 문자열 비교 결과는 달랐다.

설치된 플러그인의 importedThreadIdForSource 함수에는 다음 조건이 있었다.

record?.source_path === canonicalSource &&

실제 기록으로 비교하면 거짓이었다. 접두사를 제거해 비교했을 때는 참이 나왔다.

경로 비교 수정

수정한 파일은 다음 위치에 있었다.

%USERPROFILE%\.claude\plugins\cache\openai-codex\codex\1.0.6\scripts\lib\codex.mjs

설치 방식이나 버전에 따라 경로는 달라질 수 있다. 해당 비교 조건을 다음과 같이 바꿨다.

typeof record?.source_path === "string" &&
(process.platform === "win32"
  ? path.toNamespacedPath(record.source_path) ===
    path.toNamespacedPath(canonicalSource)
  : record.source_path === canonicalSource) &&

Windows에서는 양쪽 경로를 같은 확장 경로 형태로 변환한다. 다른 운영체제의 비교 방식은 유지했다.

뒤에 이어지는 내용 해시와 세션 ID 검사도 남겼다.

record?.content_sha256 === contentSha256 &&
typeof record?.imported_thread_id === "string"

경로만 맞춰서는 오래된 가져오기 기록을 선택할 수 있다. 현재 원본과 내용이 같은지도 확인해야 한다.

수정 후 최초 이전

문법 검사와 경로·해시 관련 검사 8개를 실행했다.

모두 통과했다. POSIX 조건은 조회 함수를 대상으로 한 모의 검사다. Linux에서 플러그인을 실행한 결과는 아니다.

새 Claude 대화에서 /codex:transfer를 실행하자 세션 ID와 재개 명령이 나왔다. 안내된 ID로 재개한 Codex는 표식 MAPLE-836, 계산값 -1900과 80, 남은 작업인 / 100 복원을 정확히 답했다.

재이전 오류는 경로 문제가 아니었다

최초 이전이 성공한 뒤 같은 대화를 다시 넘겼다. 오류가 재현됐다.

Codex CLI 0.163.0의 가져오기 코드를 확인하니, 기존 세션에 새 내용을 붙이는 조건이 있었다. 모델에 보이는 대상 Codex 대화가 원본 대화의 정확한 앞부분이어야 한다. 기록이 갈라졌거나 대상이 활성 상태·보관 상태인 경우 등에는 추가를 거부한다. 해당 버전의 추가 가져오기 로직

앞선 검증에서 Codex에 맥락 확인 질문을 보낸 것이 영향을 줬다. 그 질문과 응답은 Claude 원본에는 없었다. Claude에서도 대화를 계속했으니 두 기록은 이렇게 나뉘었다.

처음 이전한 공통 대화
├─ Claude: 새로운 표식과 변경된 작업 지시
└─ Codex: 맥락 확인 질문과 응답

Claude의 새 내용을 기존 Codex 대화에 그대로 붙이려면, 서로 다른 후속 대화를 어떻게 합칠지 결정해야 한다. Codex의 추가 가져오기는 이 상황을 거부했다.

플러그인은 현재 원본과 일치하는 가져오기 기록을 찾지 못해 일반적인 오류 문구를 출력했다. 최초 이전 실패와 대화 분기가 같은 메시지로 보였던 셈이다.

최신 대화를 별도 세션으로 가져오는 옵션을 추가했다

기존 대상에 억지로 내용을 붙이지 않고, 최신 Claude 대화를 새 Codex 세션으로 가져오도록 했다.

/codex:transfer --fresh

/codex:transfer --fresh는 이번 로컬 패치로 추가한 옵션이다. 수정하지 않은 공식 1.0.6에서는 지원하지 않는다.

이 옵션은 기존 경로 검증을 통과한 Claude 원본을 읽어, 원본 폴더 아래 .codex-transfer-snapshots에 JSONL 사본을 만든다. 사본에는 고유한 이름을 붙이고 기존 파일을 덮어쓰지 않도록 했다. 이후 그 사본을 가져와 새 세션 ID와 재개 명령을 안내한다.

변경한 파일은 세 개다.

일반 이전에서 현재 원본에 대응하는 기록을 찾지 못하면, 대상 대화가 갈라졌거나 활성 상태일 수 있다는 안내와 함께 --fresh 사용법을 보여 주도록 했다. 오류의 원인이 항상 대화 분기인 것은 아니므로 다른 가능성도 남겼다.

이 글에는 수정 구조와 검증 결과를 정리했다. 위의 경로 비교 코드만 바꿔서는 --fresh 옵션이 추가되지 않는다. 해당 옵션에는 세 파일의 인자 처리와 사본 가져오기 구현이 모두 필요하다.

바뀐 작업 지시까지 전달됐는지 시험했다

이미 이전한 Claude 대화에 새 표식을 넣고 다음 작업을 바꿨다.

이전 표식: MAPLE-836
새 표식: CEDAR-915

이전 작업:
할인 계산의 / 100 복원

변경된 작업:
0% 할인 테스트를 먼저 추가한 뒤 / 100 복원

/codex:transfer --fresh를 실행하자 별도의 Codex 세션이 만들어졌다.

새 세션을 재개한 뒤, 정답을 다시 알려 주지 않고 최신 표식과 작업 순서를 물었다. Codex는 CEDAR-915를 답했고, 0% 할인 테스트를 먼저 추가한 다음 / 100을 복원해야 한다고 설명했다. 이전 지시는 MAPLE-836과 계산식 복원만 포함했다는 차이도 짚었다.

최초 이전 때의 내용에 머물지 않고 추가된 지시까지 읽은 것을 확인했다.

원본과 기존 세션은 그대로 남았나?

별도 통합 검사에서는 일반 재이전과 --fresh를 실행하면서 파일 해시를 비교했다.

이번 패치는 최신 Claude 원본을 별도 세션으로 가져오는 경로를 추가한 것이다. 기존 Codex 대화와 자동으로 합쳐 주지는 않는다.

로컬 패치를 쓸 때 알아둘 점

--fresh를 실행할 때마다 새 사본과 세션이 생긴다. 사본은 실행 시점의 Claude 대화를 담고, 이후 양쪽 대화를 동기화하지 않는다.

기존 Codex 쪽에서만 나눈 대화도 새 사본에는 없다. 그 내용이 필요하면 인계 메모에 따로 정리해야 한다.

이번에는 Codex 데스크톱 앱의 재개, 첨부 자료와 전체 도구 기록의 보존, Claude 한도 소진 상태, 개인 브리지의 별도 기록 폴더 가져오기를 시험하지 않았다.

설치 캐시를 수정했으므로 업데이트나 재설치 때 패치가 사라질 수 있다. 다른 버전에서는 같은 오류가 생기는지와 코드 구조가 달라졌는지 먼저 확인해야 한다. 되돌릴 때는 백업한 원본 파일을 복원하면 된다.

원본과 사본의 위치가 혼동된다면 개인 브리지의 원본·사본과 세션 전환 가이드를 참고할 수 있다. 이번처럼 양쪽에서 작업을 이어 쓴 경우에는 어느 기록에 최신 결정이 있는지부터 확인하는 편이 좋다.

검증 기록: 2026년 10월 18일. 공식 1.0.6과 로컬 패치 결과를 구분했습니다.