Codex Cannot serialize value 오류: 새 채팅이 시작되지 않을 때 확인할 사항
Codex의 couldn't stringify value 오류를 진단합니다. 해결이 보고된 버전, Local과 Worktree 비교, 작업 보존 방법, 복구 확인 절차를 알아보세요.
Ofox 
새 Codex 채팅에서 Cannot serialize value: (couldn't stringify value) 오류가 발생하면 먼저 설치된 버전을 기록하고 업데이트를 확인하세요. 계속 발생한다면 같은 프로젝트에서 새 Local 채팅과 새 Worktree 채팅을 비교하세요. 처음부터 채팅 기록을 삭제하거나 API 키를 바꾸거나 저장소를 초기화할 필요는 없습니다.
이 오류 문구는 2026년 10월 데스크톱 앱 관련 제보에 등장했습니다. 해당 이슈는 현재 닫힌 상태이며, 사용자들이 특정 macOS 및 Windows 빌드에서 정상 작동했다고 보고했습니다. 과거 문제가 모든 설치 환경에 여전히 영향을 준다고 가정하기보다 버전부터 확인하는 편이 유용합니다.
이 글은 특히 Worktree를 선택했을 때 새 채팅의 첫 메시지 제출이 실패하는 경우를 다룹니다. 공개 제보를 바탕으로 기존 작업을 보호하며 진단하는 절차입니다. Ofox가 원래 오류를 통제된 설치 환경에서 재현한 것은 아닙니다. 아래 단계는 확인 절차와 조건부 대안이지, 모든 환경에 통하는 해결책이나 Ofox API 키로 Codex를 고칠 수 있다는 주장이 아닙니다.
과거 우회 방법을 적용하기 전에 버전 확인하기
아래는 10월 28일 확인한 OpenAI 저장소의 이슈 #55744를 요약한 것입니다. 사용자 제보이며, 플랫폼 전체의 지원 현황을 정리한 표가 아닙니다.
| 보고된 환경 | 보고된 결과 | 이 정보를 활용하는 방법 |
|---|---|---|
macOS, 데스크톱 26.1016.51333 | 새 채팅의 첫 메시지가 실패하며, 여러 제보가 Worktree 모드를 지목 | 오류 문구뿐 아니라 설치 빌드와 모드를 비교 |
Linux, 데스크톱 26.1016.51333 | Worktree는 실패하지만 Local은 작동한 사례 | Windows 제보로 Linux의 수정 버전을 추정하지 않기 |
macOS, 26.1016.61520 | 한 사용자가 문제 해결을 보고 | 현재 설치 환경에 제공되는 업데이트를 우선 적용. 이 과거 버전으로 고정하라는 뜻은 아님 |
Windows, 26.1016.62342 | 업데이트 후 Worktree를 직접 만들 수 있었다는 제보 | 업데이트 후 자신의 환경에서도 해당 작업을 확인 |
macOS 복구 댓글과 Windows 복구 댓글은 별개의 관찰입니다. 오래된 빌드에서 업데이트 도구가 최신 상태라고 표시해도, 이는 그 설치 환경에서 현재 받을 수 있는 업데이트 상태만 나타냅니다. 다른 플랫폼에서 보고된 수정 사항이 설치됐다는 증거는 아닙니다.
보내지 못한 프롬프트를 비공개 위치에 저장하고 진행 중인 작업을 마치거나 일시 중지한 뒤, 앱이 지원하는 업데이트 방법을 사용하세요. 업데이트 전후 버전을 기록합니다. 업데이트 도구가 요구하면 재시작하고 같은 프로젝트를 다시 열어 짧은 메시지를 한 번 보내세요. 비공식 미러에서 오래된 앱을 내려받거나 설치된 앱 파일을 직접 수정하지 마세요.
같은 오류인지 구분하기
직렬화는 값을 전송하거나 저장할 수 있는 형태로 변환하는 과정입니다. 오류 문구만으로는 어떤 값에서 실패했는지, 모델 요청이 전송됐는지, 저장소가 손상됐는지 알 수 없습니다.
설정을 바꾸기 전에 다음 세 가지를 기록하세요.
- 발생 단계: 앱 자체가 열리지 않았나요, 첫 메시지를 제출하지 못했나요, 실행 중이던 작업이 나중에 실패했나요?
- 모드: 새 채팅은 Local이었나요, Worktree였나요? Git 프로젝트에 연결돼 있었나요?
- 정확한 오류: 괄호 안 내용까지 포함해 짧은 메시지 전체를 복사하세요. 함께 표시된 다른 오류는 따로 기록합니다.
실제 메시지가 couldn’t load workspace settings라면 작업 공간 초기화를 조사하세요. 확장 프로그램에 couldn’t load its resources가 표시된다면 리소스 로딩 안내를 참고합니다. 입력창에 permission mode is unavailable이 표시된다면 해당 제출 체크리스트를 따르세요. 발생 시점이 비슷하다고 같은 원인은 아닙니다.
해당 이슈에는 서식 있는 텍스트 문서의 속성에 관한 가설 등 클라이언트 측 직렬화 과정을 조사한 내용도 있습니다. 문제가 발생할 수 있는 구간을 좁히는 데는 도움이 되지만, 모든 사용자에게 문장 부호나 중국어를 지우거나 저장소의 JSON 파일을 다시 작성하라고 권할 근거는 아닙니다. 짧은 일반 텍스트 프롬프트는 비교용으로 유용할 뿐, 확실한 해결책은 아닙니다.
프로젝트 변경 없이 Local과 Worktree 비교하기
실제 작업 대신 진단용 프롬프트를 사용하세요.
OK라고만 답하세요. 파일을 읽거나 수정하지 말고, 명령 실행,
의존성 설치 또는 프로젝트 작업 시작도 하지 마세요.계정, 프로젝트, 버전을 동일하게 유지하세요. 먼저 새 Local 채팅을 시도한 뒤 같은 프롬프트로 새 Worktree 채팅을 시도합니다. Worktree를 만들면 프로젝트에 설정된 초기 설정 과정이 실행될 수 있습니다. 먼저 설정을 검토하고 부수 효과가 있을 경우 안전한 테스트 저장소를 사용하세요. 사례를 더 모으려는 목적으로 운영 프로젝트 여러 개에서 반복하지 마세요.
| 관찰 결과 | 다음 확인 단계 |
|---|---|
| Local은 응답하지만 Worktree는 첫 응답 전에 실패 | 모드에 따른 차이를 기록하고 Worktree 생성 경로 조사 |
| 둘 다 정확히 같은 오류로 실패 | Local 우회가 적용된다고 가정하지 말고 양쪽 진단 정보 수집 |
| Local은 작동하고 Worktree는 디렉터리 생성 후 다른 설정 오류로 실패 | 새 설정 오류를 별도로 조사 |
| 기존 채팅은 작동하지만 새 채팅은 둘 다 실패 | 새 채팅과 기존 채팅의 차이 기록. 기존 채팅 성공이 새 채팅 복구를 뜻하지는 않음 |
| 업데이트 후 둘 다 작동 | 평소 작업으로 돌아가기 전에 새 Worktree 채팅을 하나 더 확인 |
유의미한 차이를 확인하면 테스트를 멈추세요. 전송 버튼을 반복해서 누르면 불필요한 기록이 쌓여 첫 실패를 찾기 어려워집니다. Local의 모델 응답은 당시 그 경로가 작동했다는 사실만 입증합니다. 격리나 Worktree 초기 설정을 검증한 것은 아닙니다.
Local이 작동한다면 임시 작업 경로 선택하기
Local은 선택한 체크아웃에서 작동합니다. 별도의 worktree는 다른 작업 디렉터리를 제공합니다. 따라서 Local로 전환하면 프로젝트 작업이 이루어지는 위치가 달라지며, 동일한 격리를 보장하지 않습니다.
읽기 전용으로 논의하는 작업이라면 정상 작동하는 Local 채팅에 머무는 것으로 충분할 수 있습니다. 편집을 허용하기 전에 체크아웃 상태를 확인하고 같은 위치를 사용하는 다른 작업과 조율하세요. 커밋하지 않은 변경과 추적되지 않은 파일을 보존합니다. git reset --hard, git clean, 캐시 삭제를 일반적인 직렬화 오류 해결책으로 사용하지 마세요.
격리가 필요한 작업의 경우 해당 이슈에는 Local에서 시작한 뒤 앱이 관리하는 worktree를 만든 사례가 있습니다. 조건부 대안으로 취급하세요. 설치한 앱에서 해당 기능을 실제로 사용할 수 있을 때만 사용하고, 편집 전에 반환된 디렉터리를 확인합니다. 다음과 같이 지시할 수 있습니다.
현재 체크아웃을 편집하지 마세요. 먼저 시작점으로 사용할 브랜치나
커밋을 식별하고, 최종 확인된 커밋을 보고하세요. 앱에서 지원하는 기능을
사용할 수 있다면 별도의 관리형 worktree를 만드세요.
절대 경로와 HEAD를 보고하고, 이후 모든 프로젝트 작업은 그 디렉터리에서
수행하세요. 생성이나 연결이 실패하면 파일을 편집하기 전에 중단하고
오류를 보고하세요.시작 리비전은 실제 작업에 필요한 것으로 지정하고 무조건 master로 바꾸지 마세요. 새 worktree에는 원래 체크아웃의 미커밋 변경 사항이 자동으로 옮겨지지 않습니다. 변경 사항이 필요하다면 먼저 보존한 뒤 이전 방법을 명확히 정하세요.
계속하기 전에 읽기 전용 Git 명령으로 반환된 위치를 확인합니다.
git -C /absolute/path/to/worktree rev-parse --show-toplevel
git -C /absolute/path/to/worktree rev-parse HEAD
git -C /absolute/path/to/worktree status --short
git -C /absolute/path/to/worktree worktree list실제 경로를 사용하고 공백이 있으면 따옴표로 감싸세요. 디렉터리가 별도 위치인지, 커밋이 합의한 시작 리비전과 일치하는지, 초기 변경 사항의 이유를 파악했는지 확인합니다. 디렉터리가 만들어졌다는 사실만으로 앱이 연결했거나 이후 명령이 그곳에서 실행된다는 점이 입증되지는 않습니다. 앱이 지원 기능을 제공하지 못한다면 읽기 전용으로 진행하거나 이미 지원되는 개발 경로를 사용하세요. 단순히 복사한 폴더를 관리형 worktree라고 간주하지 마세요.
문제 보고에 유용한 진단 정보 모으기
앱이 지원하는 피드백 또는 진단 경로를 사용하세요. 공개 제보에는 TypeError, 입력창 제출 실패, mode=worktree가 포함돼 있습니다. 다른 사람의 스택 트레이스를 복사하는 대신 자신의 테스트 시각 전후에서 해당 이벤트를 찾으세요.
관련 이벤트와 맥락만 기록합니다. 원본 로그에는 프롬프트, 로컬 경로, 저장소 이름, 인증 정보, 세션 식별자가 포함될 수 있으므로 공유하기 전에 가리세요. 다음 양식은 기록을 돕는 템플릿이며 실제로 관찰한 로그가 아닙니다.
OS와 아키텍처:
데스크톱 앱 버전/빌드:
테스트 시각과 시간대:
화면에 표시된 정확한 오류:
새 채팅 또는 기존 채팅:
프로젝트 유형: Git / 비Git / 없음
Local 테스트: 성공 / 정확한 오류 / 테스트 안 함
Worktree 테스트: 성공 / 정확한 오류 / 테스트 안 함
제공된 업데이트와 적용 결과:
worktree 디렉터리가 생성됐는가?
민감 정보를 제거한 관련 진단 필드:
테스트 사이에 변경한 사항:직렬화 메커니즘에 관한 가설을 자신의 컴퓨터에서 확인된 근본 원인으로 적지 마세요. 유지보수 담당자에게 중요한 구분은 worktree가 생기기 전인지, 초기 설정 중인지, 작업이 시작된 후인지입니다. 비공개 소스 코드를 올리지 않고도 그 구분과 최소 재현 절차를 제공할 수 있습니다.
복구가 완료됐는지 판단하기
복구는 경고 배너가 사라진 상태가 아니라 필요한 작업이 다시 작동하는 상태입니다. 직접 Worktree 생성이 실패했던 경우에는 새 Worktree 채팅이 짧은 프롬프트를 수락하는지, 앱에 의도한 체크아웃이 표시되는지, 두 번째 새 채팅도 시작되는지 확인하세요. 그런 다음 검증한 디렉터리에서 작은 실제 작업을 재개하고 변경 사항을 점검합니다.
Local만 작동한다면 임시 대안은 사용 가능하지만 직접 Worktree 생성은 여전히 실패함으로 기록하세요. 업데이트를 받을 수 없다면 지원 문의에 쓸 버전과 진단 정보를 보관합니다. 오류가 바뀌었다면 예전 스레드의 모든 대처법을 적용하지 말고 Codex 오류 색인에서 새 오류를 조사하세요.
Ofox는 개발자를 위해 이 문제 해결 안내를 발행합니다. 모델 제공업체 변경, API 크레딧 구매, 모델 사용 한도 증가는 데스크톱 직렬화 오류를 해결한다는 근거가 되지 않습니다.
