Codex Cannot serialize value 오류: Worktree를 끄면 바로 보내집니다

ChatGPT 데스크톱 앱의 Codex에서 새 채팅의 첫 메시지를 보내자마자 "Error starting chat"과 함께 Cannot serialize value: (couldn't stringify value)가 뜬다면, 그 채팅을 Worktree 모드로 시작했는지 먼저 보세요. 이 오류는 데스크톱 앱 26.1016.51333(build 21161)에서 Worktree로 새 채팅을 시작할 때만 나는 알려진 버그이고, macOS·Windows·Linux 모두에서 보고됐습니다. 컴포저 아래에서 New worktree를 끄거나 Local을 고른 뒤 같은 메시지를 다시 보내면 앱을 재시작하지 않아도 바로 전송됩니다(GitHub #55744).

저장소, 프롬프트 내용, 네트워크, 설치 상태와는 관계가 없으므로 재시작·재설치·브랜치 재선택으로는 풀리지 않습니다. 2026년 10월 22일 기준으로 이슈는 열려 있고 공식 변경 기록에도 수정 내용이 없습니다. Local에서는 에이전트가 지금 작업 중인 폴더를 직접 수정하므로, 작업을 분리해야 한다면 아래의 격리 경로 가운데 운영체제와 검증 수준에 맞는 것을 고르세요.

Error starting chat이 이 버그인지 확인하는 기준

이 버그는 "Worktree에서만 실패하고 Local에서는 정상"이라는 대비로 가장 빨리 확인됩니다. 같은 프로젝트에서 같은 메시지를 Local로 보내 보세요. Local에서 전송되면 이 버그이고, Local에서도 실패하면 다른 원인을 찾아야 합니다.

Codex는 2026년 7월 9일부터 ChatGPT 데스크톱 앱의 일부가 되었기 때문에, 같은 빌드를 "Codex desktop 26.1016.51333"이라고 부르는 사람도 있고 "ChatGPT desktop 26.1016.51333"이라고 부르는 사람도 있습니다. 둘은 같은 앱입니다. 대부분의 보고는 2026년 10월 21일에 앱을 업데이트한 직후부터 오류가 났다고 적고 있습니다. Windows 사용자 한 명의 로그에는 10월 20일 이전 패키지(26.1013)에서 Worktree 채팅이 정상적으로 만들어진 기록이 있고, 새 패키지로 바뀐 10월 21일부터 같은 오류가 반복됩니다(Windows 재현 보고). 업데이트로 생긴 회귀로 보이지만, 이전 버전과 나란히 비교한 사람은 없어서 추정입니다.

VS Code 확장에서 2026년 9월에 보고된 "Error creating chat" 직렬화 문제는 제품도 시기도 다른 별개의 건입니다. 앱 자체가 뜨지 않거나 app-server 시작 오류가 나는 경우는 failed to start codex app-server 해결: Windows 앱·CLI 오류 문구별 조치를 보세요.

New worktree를 끄고 Local로 다시 보내면 바로 전송됩니다

여러 사용자가 세 운영체제에서 확인한 가장 빠른 조치입니다. 앱을 재시작할 필요도 없습니다(macOS 확인 보고, 세 프로젝트에서 확인한 보고).

1. 오류가 난 새 채팅 화면에서 컴포저 아래의 실행 위치 선택을 Worktree에서 Local로 바꿉니다. 새 채팅 설정의 톱니바퀴 아이콘 안에서 New worktree 스위치를 찾은 사용자도 있습니다. 한국어 UI에서는 버튼 이름이 다르게 표시될 수 있습니다.
2. 같은 메시지를 다시 보냅니다.
3. 채팅이 시작되고 Codex가 답하기 시작하면 성공입니다.

대가는 격리가 사라진다는 점입니다. Local은 내가 만든 저장소 체크아웃 그 자체여서, 에이전트가 지금 열어 둔 작업 폴더의 파일을 직접 고칩니다. 보내기 전에 진행 중인 변경을 커밋하거나 git stash로 치워 두면, 에이전트가 바꾼 부분만 git diff로 깔끔하게 확인하고 되돌릴 수 있습니다. 쓰기 범위 자체를 좁히고 싶다면 Codex 샌드박스와 config.toml: 승인·쓰기·네트워크 경계를 참고하세요.

격리가 필요할 때 고르는 여섯 가지 경로

여러 작업을 나란히 돌리거나 로컬 체크아웃을 건드리지 않아야 한다면, 수정이 나올 때까지 아래 경로 중 하나를 쓸 수 있습니다. 경로마다 무엇이 분리되는지와 실제로 확인된 범위가 크게 다르므로 운영체제와 함께 보세요.

고르는 기준은 다음과 같습니다.

• 채팅 자체를 워크트리에서 돌리고 싶다면 Codex에게 워크트리에서 도는 새 채팅을 시작해 달라고 요청하는 방법(macOS 2건)이나 Hand off(macOS 1건)를 쓰세요. 두 방법 모두 Windows·Linux 앱에서의 보고는 아직 없습니다.
• Windows라면 Codex에게 관리 워크트리를 만들게 하는 방법이 Windows에서 처음부터 끝까지 확인된 유일한 앱 내 격리 경로입니다. 다만 채팅은 원래 체크아웃에 남습니다.
• Linux이거나 앱 기능을 거치지 않고 확실하게 가고 싶다면 git worktree add로 직접 만드세요. 앱의 Worktree 시작 기능을 쓰지 않는 방식이라 결과를 내가 Git으로 직접 확인할 수 있습니다.
• 평소처럼 Worktree를 켠 채 시작하고 싶다면 사용자 지정 프롬프트로 보내는 방법이 있지만, 폐지 예정 기능에 기대는 임시 방편입니다.
• 여러 채팅을 오래 돌릴 별도 환경이 필요하다면 영구 워크트리를 시도해 볼 수 있지만, 이 버그를 피하는지는 아직 아무도 확인하지 않았습니다.

Local로 첫 메시지를 보낸 뒤 Hand off로 Worktree로 옮기기

macOS 사용자 한 명이 이 순서로 워크트리 생성, 변경 사항 이동, 채팅 전환이 모두 성공했고 이전 대화 기록도 그대로 남았다고 보고했습니다(Hand off 검증 보고). 버그는 "새 채팅을 Worktree로 바로 시작하는" 경로에만 있고, 이미 시작된 채팅을 옮기는 Hand off는 다른 경로를 탑니다.

1. Local로 새 채팅을 시작합니다. 첫 메시지는 로컬 파일을 고치지 않는 요청(코드 읽기, 계획 세우기)으로 두면, 옮기기 전에 로컬 체크아웃이 바뀌지 않습니다.
2. 채팅이 시작되면 채팅 헤더의 Hand off를 눌러 Worktree로 옮깁니다.
3. 옮긴 뒤 Codex에게 현재 작업 디렉터리를 물어 관리 워크트리 위치(기본값 $CODEX_HOME/worktrees 아래, Settings > Worktrees > Worktree root에서 바꿀 수 있음)인지 확인합니다.

공식 워크트리 문서에 따르면 Hand off는 채팅과 코드를 함께 옮기고, 필요한 Git 작업은 Codex가 처리합니다. 그래서 이 채팅과 관계없는 커밋하지 않은 변경이 로컬 체크아웃에 남아 있다면 먼저 정리해 두는 편이 안전합니다. .env 같은 .gitignore 대상 파일은 저장소 루트의 .worktreeinclude에 경로를 적어 두어야 관리 워크트리로 복사됩니다. Windows와 Linux에서는 이 방법의 성공·실패 보고가 아직 없습니다.

Codex에게 워크트리에서 도는 새 채팅을 시작해 달라고 요청하기

정상 작동하는 아무 채팅(Local 채팅 등)에서 Codex에게 이 프로젝트의 새 채팅을 워크트리에서 시작해 달라고 요청하는 방법입니다. 이슈에 올라온 사용자 보고 두 건이 모두 macOS 앱에서 처음부터 끝까지 확인했습니다. 원격 Linux 프로젝트에서는 새 관리 워크트리가 만들어지고 새 채팅이 그 안에서 시작해 첫 응답까지 마쳤으며, pwd와 git status로 확인한 작업 위치가 깨끗한 detached HEAD 상태의 워크트리였습니다(원격 Linux 프로젝트 보고). 로컬 Git 프로젝트에서도 새 채팅이 별도 워크트리에서 시작되어 정상으로 응답했습니다(로컬 프로젝트 보고).

아래의 "관리 워크트리를 만들게 하기"와 달리 새 채팅 자체가 워크트리에서 돕니다. 컴포저의 첫 메시지를 거치지 않으므로 문제의 편집기 기록도 만들어지지 않습니다.

1. 작동하는 채팅에서 "이 프로젝트에서 워크트리 환경으로 새 채팅을 하나 시작하고, 그 채팅에서 ○○ 작업을 해 줘"처럼 평소 말로 요청합니다. 제보자들은 Codex가 앱의 내장 도구를 써서 처리했다고 적었지만, 그 도구 이름은 앱 내부 사항이라 바뀔 수 있으므로 이름을 지정하지 말고 원하는 결과를 설명하세요.
2. 새 채팅이 사이드바에 생기면 그 채팅에서 pwd와 git status를 실행하게 해, 작업 위치가 관리 워크트리(기본값 $CODEX_HOME/worktrees 아래)인지 확인합니다.

검증은 macOS 앱에서의 두 건이고, Windows나 Linux 앱에서 같은 결과가 나왔다는 보고는 아직 없습니다.

Local 채팅에서 Codex에게 관리 워크트리를 만들게 하기

정상 작동하는 Local 채팅 안에서 Codex에게 관리 워크트리를 만들어 붙이라고 요청하는 방법입니다. macOS 사용자는 아래 문장을 그대로 보내 Codex가 앱의 내장 워크트리 도구로 워크트리를 만들고 채팅에 연결하는 것을 확인했고(macOS 검증 보고), Windows 사용자도 같은 방식으로 처음부터 끝까지 성공했습니다(Windows 검증 보고).

Create and attach a managed worktree for this task, then do all work in that checkout.

한국어로 "이 작업용 관리 워크트리를 만들어 이 채팅에 연결하고, 모든 작업을 그 체크아웃에서 해 줘"라고 요청해도 의도는 같지만, 검증된 것은 위의 영어 문장입니다.

함정이 하나 있습니다. 워크트리는 만들어져 채팅에 연결되지만 채팅 자체는 원래 체크아웃에 남습니다. Codex가 돌려준 워크트리 경로를 기록해 두고, 이후 지시에 "모든 파일 수정과 명령은 이 경로에서 실행"이라고 명시해야 로컬 체크아웃이 바뀌지 않습니다. 작업 도중에 git -C <워크트리 경로> status와 로컬 체크아웃의 git status를 한 번씩 비교하면 어느 쪽이 바뀌었는지 바로 보입니다. 새 워크트리에는 의존성 설치나 개발 서버 같은 준비가 되어 있지 않으므로 필요하면 따로 실행해야 합니다.

git worktree add로 직접 만든 폴더에서 Local로 작업하기

앱의 워크트리 기능을 아예 거치지 않는 방법입니다. 영향받은 환경에서도 Git으로 직접 워크트리를 만드는 것은 정상적으로 됐다는 보고가 있습니다(Windows 앱에서 SSH로 연결한 Linux 원격 호스트, 원격 호스트 보고).

# 저장소 루트에서: 새 브랜치 fix/my-task로 옆 폴더에 워크트리 생성
git worktree add ../myapp-fix -b fix/my-task

# Git이 추적하지 않는 설정 파일은 직접 복사
cp .env ../myapp-fix/

1. 위 명령으로 워크트리를 만들고, .env처럼 .gitignore에 들어 있는 파일 중 필요한 것을 직접 복사합니다. .worktreeinclude는 앱이 만드는 관리 워크트리에만 적용되고, 명령줄로 만든 워크트리에는 적용되지 않습니다.
2. 앱에서 ../myapp-fix 폴더를 프로젝트로 추가합니다.
3. 그 프로젝트에서 Local로 채팅을 시작합니다. Local 모드는 이 버그의 영향을 받지 않습니다.

Git 문서대로 한 브랜치는 한 번에 한 워크트리에서만 체크아웃할 수 있으므로, 로컬 체크아웃에서 쓰는 브랜치를 그대로 지정하면 거부됩니다. 위 예시처럼 -b로 새 브랜치를 만들거나 --detach를 쓰세요. 작업이 끝나면 git worktree remove ../myapp-fix로 폴더를 지우고, 필요 없으면 git branch -d fix/my-task로 브랜치도 정리합니다.

사용자 지정 프롬프트로 Worktree 그대로 시작하기: 임시 방편

Worktree 모드를 그대로 쓰면서 버그를 피하는 방법입니다. 원격 Mac mini의 프로젝트를 macOS 앱에서 쓰던 사용자 한 명이 이 방법으로 Worktree 채팅이 시작된다고 확인했습니다(사용자 지정 프롬프트 보고).

1. 앱을 실행하는 컴퓨터(원격 프로젝트라면 앱을 띄운 쪽)에 ~/.codex/prompts/worktree-start.md 파일을 만들고 아래 한 줄을 넣습니다.

   text

   Work in the isolated worktree created for this chat. Follow the request below.

2. 앱 창을 다시 불러와(reload) 새 프롬프트를 읽게 합니다.

3. 프로젝트와 Worktree 선택을 그대로 둔 채 /prompts:worktree-start 뒤에 요청을 이어 보냅니다. 예: /prompts:worktree-start Reply OK; do not change any files. 이후 작업도 같은 방식으로 요청 앞에 붙여 보내면 됩니다.

제보자의 코드 추적에 따르면, 프롬프트가 확장되면서 보낸 글이 편집기 원문과 달라지기 때문에 앱이 문제의 편집기 문서를 기록에 넣지 않고 넘어갑니다. 실제 요청 내용을 잡아 확인한 것은 아닙니다.

가장 큰 약점은 기능의 수명입니다. OpenAI는 2026년 1월 22일 변경 기록에서 사용자 지정 프롬프트(custom prompts)를 폐지 예정으로 표시하고 skills를 쓰라고 안내했습니다. 26.1016에서는 아직 동작했지만 언제든 사라질 수 있으므로, 수정이 나올 때까지만 쓰는 임시 방편으로 보세요. 확인한 사람도 한 명뿐입니다.

사이드바에서 영구 워크트리(permanent worktree) 만들기: 검증되지 않음

공식 문서에 따르면 사이드바의 프로젝트에서 점 세 개 메뉴를 열어 영구 워크트리를 만들 수 있습니다. 영구 워크트리는 별도 프로젝트로 나타나고, 자동으로 지워지지 않으며, 그 안에서 여러 채팅을 시작할 수 있습니다. Codex가 채팅마다 만들고 정리하는 관리 워크트리(Codex-managed worktree)와는 다른 기능입니다.

2026년 10월 22일 기준으로 이 경로가 이 버그를 피하는지 시험한 보고는 없습니다. 시도한다면 영구 워크트리 프로젝트 안에서 채팅을 Local로 시작하세요. 버그가 Worktree로 새 채팅을 시작하는 경로에 있으므로 그 경로를 피하는 방식이지만, 영구 워크트리를 만드는 단계 자체가 영향을 받는지는 알려져 있지 않습니다.

그 밖의 진입점: iOS 앱과 Codex CLI

같은 Mac에 연결된 ChatGPT iOS 앱에서 Worktree 채팅을 시작하면 성공했다는 보고가 한 건 있습니다(iOS 보고). codex CLI는 계속 작동한다는 보고도 한 건 있습니다(CLI 보고). CLI에는 데스크톱 앱의 컴포저가 없어서 실패하는 경로를 거치지 않는 것으로 보입니다. 두 경우 모두 단일 보고이며, VS Code 확장이 이 버그의 영향을 받는지는 보고가 없어 알 수 없습니다.

재시작·재설치로 안 되는 이유: 앱 코드의 attrs 직렬화 실패

사용자 보고를 종합하면 원인은 내 환경이 아니라 설치된 앱 코드 쪽에 있습니다. 여기서 직렬화(serialize)는 앱 화면이 "워크트리를 만들어 달라"는 요청을 앱 내부로 보내기 전에 데이터를 전송 가능한 형태로 바꾸는 단계입니다. 데스크톱 앱 로그에는 [Composer] submit failed, errorName=TypeError, mode=worktree가 남고, 실패 위치는 워크트리 생성 요청(managedWorktrees.pending.create)을 보내기 직전입니다. 즉 워크트리가 만들어지기도 전에 멈추며, git worktree list도 정상으로 동작하므로 저장소에는 문제가 없습니다(로그 보고).

이슈에 올라온 사용자 보고에 따르면, Windows와 macOS의 사용자 두 명이 각자 실행 중인 앱에 디버거를 붙여 거부된 값을 직접 잡아냈습니다(Windows 디버거 보고, macOS 디버거 보고).

• 거부된 값은 openingPromptForHistory.document.attrs입니다. 첫 메시지를 입력한 편집기 문서를 기록용으로 저장하면서 생기는 속성 객체로, 프로토타입이 없는 객체(start, end 키만 가짐)입니다.
• 앱의 직렬화기는 일반 객체만 받아들이므로 이 값을 거부합니다. 오류 메시지를 만들려고 값을 문자열로 바꾸는 단계마저 실패해서, 문제의 필드 이름 대신 (couldn't stringify value)라는 말만 남습니다.
• 이 속성은 짧은 일반 텍스트에도 붙기 때문에 메시지 내용을 바꿔도 소용이 없습니다. 그리고 이 문서는 Worktree로 새 채팅을 시작하는 요청에만 실리기 때문에 Local은 영향을 받지 않습니다.
• 두 사용자는 이 필드 하나를 일반 객체로 바꾸는 임시 패치를 메모리에서만 적용했고, 그 상태에서 Worktree 채팅이 정상으로 시작됐습니다. 앱을 다시 켜면 사라지는 수정이었고, 결과적으로 원인이 이 필드라는 것을 뒷받침합니다.

이 진단은 사용자들이 찾아낸 것이며 2026년 10월 22일 기준 OpenAI가 확인한 설명은 아닙니다. 다만 설치된 앱에 들어 있는 코드 문제라는 점에서, 재시작이나 재설치처럼 같은 코드를 다시 실행하는 조치가 왜 효과가 없는지는 이것으로 설명됩니다.

시간만 쓰는 조치: 재시작, 재설치, 브랜치 재선택, 다운그레이드

아래는 이슈에서 이미 시도했고 효과가 없었다고 보고된 조치입니다.

이전 버전으로 되돌리는 방법은 해결책으로 쓰기 어렵습니다. 26.1013.40934로 되돌리겠다는 사용자가 있었지만 실제로 해 보고 확인한 보고는 없고(롤백 계획 보고), 구버전 공식 배포나 롤백 안내도 찾을 수 없습니다.

앱 번들 파일을 직접 고치거나 디버거로 코드를 주입하는 방법도 권하지 않습니다. 원인을 확인하는 데는 도움이 됐지만, 서명된 앱을 건드리는 지원되지 않는 방식이고 재시작하면 사라집니다. Local과 위의 격리 경로로 충분히 일할 수 있습니다.

2026년 10월 22일 기준 수정 상태와 업데이트 후 확인할 것

2026년 10월 22일 기준으로 #55744는 열려 있고 bug, app, session 라벨이 붙어 있습니다. 댓글은 63개, 반응은 145개이지만 스레드에 OpenAI 구성원의 답변은 아직 없습니다. 같은 증상의 Linux 이슈 #55823과 Windows 이슈 #55827도 열려 있습니다. 공식 변경 기록의 최신 Codex 앱 항목은 10월 8일의 26.1007이어서, 26.1016도 이 버그의 수정도 아직 올라와 있지 않습니다. 수정 시기는 알려져 있지 않습니다.

수정이 배포됐는지 확인하는 순서

1. 앱 정보 화면의 버전이 26.1016.51333에서 다른 번호로 바뀌었는지 봅니다(Windows는 설치 패키지 번호도 함께 바뀝니다).
2. 변경 기록에 새 버전 항목이 생겼는지, #55744가 닫혔는지 확인합니다.
3. 원래 작업으로 돌아가기 전에 테스트용 프로젝트에서 Worktree 채팅 하나를 짧은 메시지로 시작해 봅니다. 이 시험이 통과한 다음 평소 흐름으로 돌아가면, 수정이 덜 된 빌드에서 작업 중에 다시 막히는 일을 줄일 수 있습니다.

쓸모 있는 피드백 남기기

이슈에서 도움이 된 보고는 앱 안의 Feedback 메뉴나 /feedback 명령으로 피드백을 보내 받은 ID를, 앱 버전(26.1016.51333 / build 21161 또는 Windows 패키지 번호), 운영체제, 채팅 모드(Worktree 또는 Local)와 함께 남긴 것입니다. 위의 우회 경로를 써 봤다면 어느 운영체제에서 성공 또는 실패했는지도 덧붙이면, 특히 Windows·Linux의 Hand off나 영구 워크트리처럼 아직 확인되지 않은 칸을 채우는 데 도움이 됩니다.

Codex Cannot serialize value 오류 FAQ

저장소나 Git 설정이 망가진 건가요?

아닙니다. 실패는 워크트리를 만들기 전, 앱이 요청을 내부로 보내는 단계에서 일어납니다. 같은 저장소에서 Local 채팅이 정상으로 열리고 git worktree list도 동작한다는 보고가 일관되며, Git으로 워크트리를 직접 만드는 것도 됩니다.

Codex 앱을 재설치하거나 이전 버전으로 되돌리면 고쳐지나요?

재설치는 효과가 없었다는 보고가 있습니다. 26.1016.51333 코드 자체에 문제가 있기 때문입니다. 이전 버전으로 되돌리는 방법은 실제로 성공했다는 보고도, 공식 안내도 2026년 10월 22일 기준으로 없습니다.

New worktree를 끄면 기존 Worktree 채팅도 사라지나요?

아닙니다. 끄고 켜는 것은 새로 시작할 채팅의 위치만 정합니다. 이 버그는 Worktree로 새 채팅을 시작하는 순간에만 나는 것으로 보고되고 있으며, 이미 만들어진 관리 워크트리와 채팅을 지워야 한다는 보고는 없습니다.

Local에서도 같은 오류가 나면 어떻게 하나요?

이 버그와는 다른 문제일 가능성이 큽니다. 같은 프로젝트에서 Worktree와 Local을 비교한 보고에서는 모두 Local이 정상이었습니다. 배너 첫 줄과 둘째 줄을 정확히 옮겨 적고, 앱 버전과 실행 위치(데스크톱 앱, VS Code 확장, CLI)를 확인한 뒤 그 문구로 따로 찾아보세요.