# Codex 메시지 전송 오류 해결: 두 번째 줄 문구로 원인 찾기

> '메시지 제출 중 오류가 발생했습니다'는 어떤 실패에나 붙는 제목이고 원인은 두 번째 줄에 있습니다. 다시 시도하기 전에 메시지가 이미 전달됐는지 확인한 뒤, 문구에 맞는 해결책을 고르세요.

- URL: https://blog.laozhang.ai/ko/posts/codex-error-submitting-message
- Published: 2026-10-16
- Updated: 2026-10-16
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ko/about)
- Topic: 개발 도구·에이전트
- Tags: OpenAI Codex, ChatGPT 데스크톱 앱, Codex IDE 확장, Windows, 문제 해결

---
ChatGPT 데스크톱 앱(예전 Codex 앱)이나 VS Code·Cursor의 Codex 확장에서 메시지를 보냈는데 "메시지 제출 중 오류가 발생했습니다"가 떴다면, 그 첫 줄은 원인이 아닙니다. 클라우드 작업에서는 "메시지 전송 중 오류가 발생했습니다", 영어 화면에서는 "Error submitting message"로 보이는 이 문구는 전송이 실패하면 이유와 상관없이 붙는 제목이고, 실제 원인은 바로 아래 두 번째 줄에 나옵니다. 그래서 순서는 이렇습니다. 두 번째 줄을 그대로 복사해 두고, 실패로 표시된 메시지가 사실은 전달됐는지 확인한 다음, 문구에 맞는 해결책을 고릅니다. 확인 없이 "다시 시도"부터 누르면 같은 지시가 두 번 실행될 수 있습니다.

2026년 10월 16일 기준으로 OpenAI는 이 오류의 원인이나 수정된 빌드를 공개하지 않았습니다. 아래 내용은 설치된 ChatGPT 데스크톱 앱 26.1013.31256의 코드, 오픈소스 Codex app-server 코드, macOS 한 대의 데스크톱 앱 로그(10월 2~16일), openai/codex GitHub 이슈 34건과 OpenAI 개발자 포럼 글에서 확인한 것입니다. 각 오류를 일부러 재현해 본 결과는 아닙니다. "제보자가 효과를 확인"이라고 적은 방법은 이슈에 글을 남긴 사용자가 자기 환경에서 통했다고 보고한 것이며, OpenAI의 공식 해결책이나 보장이 아닙니다.

## "메시지 제출 중 오류가 발생했습니다": 원인은 두 번째 줄

이 알림은 서버가 보내는 오류 코드가 아니라 앱이 직접 띄우는 알림입니다. ChatGPT 데스크톱 앱 26.1013.31256의 코드에서 알림 틀은 `Error submitting message{br}{error}`이고, 첫 줄은 고정 제목, `{error}` 자리에 실제로 실패한 이유가 들어갑니다. 한국어 화면에는 같은 틀이 두 가지로 번역돼 있습니다.

| 화면의 첫 줄 | 나오는 경우 |
| --- | --- |
| 메시지 제출 중 오류가 발생했습니다 | Codex 작업에 첫 메시지나 후속 메시지를 보낼 때 |
| 메시지 전송 중 오류가 발생했습니다 | 클라우드 작업에 보낼 때 |
| Error submitting message | 영어 화면 |

"작업 생성 중 오류가 발생했습니다"(영어 화면의 "Error creating task", "Error creating chat")도 같은 두 번째 줄을 달고 나옵니다. 첫 메시지로 작업을 만들다 실패하면 이 제목이 보이는 것이고, 원인을 읽는 방법은 같습니다.

두 번째 줄이 아예 없는 경우도 있습니다. 대화 안에 남는 실패 표시는 오류 문구가 있으면 그 문구를, 없으면 영어 "Error submitting message"만 보여 주도록 짜여 있습니다. 제목만 떴다면 앱이 실패 이유를 받지 못한 것이고, 사용자 로그로 보면 대개 시간 초과나 연결 끊김입니다. VS Code 확장(26.513 버전 코드)은 메시지를 넘기는 `turn/start` 요청에 30초 제한을 두며, 데스크톱 앱 사용자들이 올린 로그에도 `timeoutMs=30000` 다음에 `submit failed errorMessage=Timeout`이 찍혀 있습니다([openai/codex GitHub 이슈 #27395](https://github.com/openai/codex/issues/27395), [#23644](https://github.com/openai/codex/issues/23644)). 앱 안에서 돌아가는 Codex 실행 서버(app-server)가 30초 안에 "받았다"고 답하지 않으면 실패로 처리된다는 뜻입니다.

[OpenAI의 Codex 문제 해결 문서](https://learn.chatgpt.com/docs/reference/troubleshooting)에는 이 오류 이름이 나오지 않습니다. 아래 원인별 해결책이 대부분 GitHub 이슈의 사용자 보고에서 나온 이유입니다.

## 다시 시도 전에: 실패한 메시지가 이미 전달됐는지 확인

실패로 표시됐다고 메시지가 안 간 것은 아닙니다. 앱이 기다리다 포기한 뒤에 서버가 요청을 받아 작업을 시작하는 경우가 있고, 이때 "다시 시도"를 누르면 같은 지시가 두 번 실행됩니다. Windows의 EPERM 오류 보고([openai/codex #52012](https://github.com/openai/codex/issues/52012))에서는 화면에 실패로 표시된 메시지 일부가 실제로는 에이전트에 도달했고, 다시 시도하자 사용자 메시지와 응답이 통째로 중복됐습니다. 대기열 오류 이슈([openai/codex #44781](https://github.com/openai/codex/issues/44781))에도 이미 저장되고 작업까지 시작된 메시지에 이 오류가 뜬 사례가 있습니다.

같은 현상은 macOS 한 대의 로그에서도 보입니다. 2026년 10월 2~16일 ChatGPT 데스크톱 앱 로그(파일 230개)에서 `turn/start` 응답 156건은 모두 오류 없이 처리됐고 응답 시간 중앙값은 63ms였습니다. 그런데 `turn/start` 시간 초과가 2번 있었고, 그중 10월 3일 예약 자동화 실행 1건은 앱이 시간 초과로 포기한 직후 서버 응답이 도착해 받을 곳 없는 응답(`response_orphaned`)으로 버려졌습니다. 앱은 실패로 기록했지만 요청은 서버에 닿았던 것입니다. 한 사용자의 작업량에서 나온 작은 표본이라 발생 빈도를 일반화할 수는 없습니다.

앱 자체에도 이 가능성을 경고하는 문구가 있습니다. 데스크톱 앱 26.1013.31256에는 전송이 중간에 끊긴 대기열 메시지에 붙는 안내 문구로 "전송 여부를 확인하지 못했습니다. 저장된 메시지를 삭제하기 전에 대화를 확인하세요"가 들어 있습니다. 코드의 설명대로라면 이런 메시지는 자동으로 다시 보내면 안전하지 않은 경우에 붙습니다. 이 안내가 보이면 지우거나 다시 보내기 전에 아래 순서로 대화부터 확인합니다.

반대로 실패한 전송이 `turn/start`에 닿지도, 대화 기록에 저장되지도 않은 사례도 여럿입니다([#35949](https://github.com/openai/codex/issues/35949), [#45019](https://github.com/openai/codex/issues/45019)). 이때는 다시 보내도 중복되지 않습니다. 어느 쪽인지는 다음 순서로 확인합니다.

1. 보내려던 문장을 먼저 복사해 둡니다. 입력창이 비어 버렸다면 입력창에서 ↑ 키를 눌러 직전 프롬프트를 되살릴 수 있습니다(OpenAI 문제 해결 문서에 나온 방법).
2. 그 채팅을 끝까지 내려 메시지가 대화에 올라가 있는지, Codex가 답을 쓰거나 파일을 바꾸기 시작했는지 봅니다.
3. 화면만으로 애매하면 대화 기록 파일에서 문장 일부를 찾습니다. 기록은 `~/.codex/sessions`(Windows는 `%USERPROFILE%\.codex\sessions`) 아래 날짜별 폴더에 JSONL 파일로 쌓입니다. macOS·Linux 터미널에서는 다음처럼 검색합니다.

   ```bash
   grep -rl "보낸 문장의 일부" ~/.codex/sessions | tail -5
   ```

   결과에 오늘 날짜 폴더의 파일이 나오면 메시지가 이미 기록된 것입니다. 줄바꿈이나 따옴표가 섞인 부분은 저장 형식 때문에 맞지 않을 수 있으니 한 줄 안의 짧은 구절로 찾습니다. Windows에서는 그 폴더의 가장 최근 파일을 텍스트 편집기로 열어 검색합니다.
4. 전달됐다면 다시 시도하지 말고 응답을 기다리거나, 덧붙일 말만 새로 보냅니다. 기록에 없다면 복사해 둔 문장을 한 번만 다시 보냅니다.

![다시 시도 전 4단계: 문장 복사, 대화 끝까지 확인, 대화 기록 파일 검색, 전달 여부에 따라 기다리거나 한 번만 다시 보내기. 아래에는 앱이 시간 초과로 포기한 직후 서버 응답이 도착해 버려진 10월 3일 로그 사례](https://blog.laozhang.ai/posts/ko/codex-error-submitting-message/img/check-delivery-before-retry.webp)

기록을 확인하는 동안 `~/.codex/sessions` 안의 파일은 손으로 지우지 마세요. 세션 파일을 직접 삭제한 Windows 사용자에게 새 대화마다 "failed to resolve rollout path … file does not exist" 오류가 났고, 재설치나 새 `.codex` 폴더로도 풀리지 않았습니다([openai/codex #30924](https://github.com/openai/codex/issues/30924)). 채팅을 정리하려면 앱의 채팅 보관과 삭제 기능을 씁니다.

## 채팅 하나만 막혔나, 앱 전체 문제인가: 새 채팅으로 가르기

원인 문구를 보기 전에 범위부터 가르면 해결책이 좁혀집니다. 같은 프로젝트에서 새 채팅을 열고 짧은 메시지를 하나 보내 봅니다.

- **새 채팅은 되고 원래 채팅만 실패**: 그 채팅의 상태가 꼬인 경우입니다. 대기열 오류, "thread not found", 오래된 대형 채팅의 시간 초과, "agent loop died"가 여기에 들어가고, 다른 채팅에 갔다 돌아오기, 진행 중인 작업이 끝난 뒤 새로 보내기, 새 채팅에서 이어 가기가 통했다는 보고가 많습니다. 시간 초과 이슈(#27395)에는 같은 프로젝트에서 오래된 채팅만 느리고 새 채팅은 빨랐다고 직접 잰 제보가 있습니다.
- **새 채팅도 실패**: 앱이나 앱 안의 app-server 쪽 문제일 가능성이 큽니다. 진행 중인 작업이 끝나기를 기다린 뒤 앱을 완전히 종료하고(창만 닫지 말고) 다시 실행하는 방법을 여러 제보자가 확인했는데, 대부분 효과가 일시적이었습니다. 앞의 macOS 로그에서도 시간 초과는 `turn/start`만이 아니라 채팅 시작(`thread/start` 8번), 채팅 목록(`thread/list` 8번), 채팅 재개(`thread/resume` 6번) 같은 다른 요청에서 같은 시간대에 몰려 일어났습니다. 내부 서버가 통째로 멈칫하는 순간에 전송이 걸린 것입니다.
- **터미널의 Codex CLI는 되는데 앱만 실패**: OpenAI 문서에 따르면 ChatGPT 데스크톱 앱과 Codex CLI는 서로 다른 Codex 버전을 품고 있을 수 있습니다. 급한 작업은 CLI로 이어 가고 앱 문제는 따로 봅니다.

![새 채팅에 짧은 메시지를 보내 범위를 가르는 판단도: 새 채팅만 되면 그 채팅 문제, 새 채팅도 실패하면 앱 전체 문제, Codex CLI만 되면 앱만의 문제로 나누고 각각 먼저 해 볼 조치를 정리](https://blog.laozhang.ai/posts/ko/codex-error-submitting-message/img/new-chat-scope-check.webp)

OpenAI 문제 해결 문서가 "채팅이 멈춘 것처럼 보일 때" 권하는 확인도 함께 해 봅니다. Codex가 승인을 기다리고 있지 않은지 보고, 터미널에서 `git status` 같은 기본 명령을 실행해 보고, 더 작고 구체적인 프롬프트로 새 채팅을 시작합니다.

증상이 비슷해도 다른 오류일 수 있습니다. 전송은 됐는데 응답 도중 429·401이나 Stream disconnected가 뜨면 [Codex exceeded retry limit 429 해결: 401·Stream Disconnected 구분](https://blog.laozhang.ai/ko/posts/codex-exceeded-retry-limit-429)을, VS Code에서 Codex 패널 자체가 열리지 않고 "Codex could not start"가 뜨면 [Codex could not start VS Code 확장 오류: 원인별 해결, WSL은 1.141.2로](https://blog.laozhang.ai/ko/posts/codex-could-not-start-vscode)를 보세요. Windows 앱 전체가 느려졌다면 [Codex Windows 앱이 느릴 때 CLI와 데스크톱을 나누는 방법](https://blog.laozhang.ai/ko/posts/codex-app-slow-cli-vs-desktop)으로 범위를 먼저 가를 수 있습니다.

## 두 번째 줄 문구별 원인과 해결책 (2026년 10월 16일 기준)

두 번째 줄 문구로 아래 표에서 해당 줄을 찾고, 자세한 조건과 효과가 없었던 방법은 이어지는 절에서 확인합니다. "먼저 해 볼 것"은 모두 제보자가 효과를 확인했다고 보고한 방법이며, 확인된 방법이 없는 경우는 그렇게 적었습니다.

| 두 번째 줄 | 주로 생기는 상황 | 먼저 해 볼 것 |
| --- | --- | --- |
| `App-server queued follow-up no longer exists` | 작업 중 대기열에 넣은 후속 메시지를 편집하거나 회수 | 다른 채팅에 갔다 돌아오기, 작업이 끝난 뒤 새로 보내기 |
| `Queued follow-up changed before dispatch` | VS Code에서 후속 메시지를 빠르게 여러 개 보냄 | 중복을 확인한 뒤 다시 보내기 |
| `invalid turn/start params: AbsolutePathBuf deserialized without a base path` | Windows에서 dot이 만든 작업에 직접 답장 | 권한을 "맞춤형"에서 "나 대신 승인"으로 변경 |
| `Timeout`, 두 번째 줄 없음, `App server request expired while queued` | 며칠 켜 둔 앱, 거대한 채팅, CPU 부하, 남은 프로세스 | 완전히 종료 후 재실행, 1~5분 뒤 다시 보내기, 새 채팅 |
| `Cannot steer conversation … without an active turn id` | VS Code에서 작업은 끝났는데 화면은 진행 중으로 남음 | `Developer: Restart Extension Host` |
| `agent loop died unexpectedly` | 대답하지 않은 승인 요청, 승인 중 사용 한도 도달 | 앱 완전 종료 후 재실행, 앱 업데이트 |
| `thread not found:` 뒤에 채팅 ID | 저장된 채팅을 열자마자 전송 | 앱 재시작 또는 새 창 |
| `no client found` | Remote SSH나 여러 창에서 채팅의 주인이 다른 창으로 넘어감 | 확인된 방법 없음 |
| `EPERM: operation not permitted, rename …` | Windows, 회사에서 관리하는 PC | 확인된 방법 없음, 중복 확인 필수 |
| `ENOENT: no such file or directory, mkdir '\\?'` | Windows의 프로젝트 없는 채팅 | config.toml의 폴더 경로를 존재하는 폴더로 수정 |
| `failed to resolve rollout path … file does not exist` | 세션 파일을 손으로 삭제한 뒤 | 빠진 파일을 되살린 뒤 앱에서 보관·삭제 |
| `Unable to determine project root for task`, `a managed thread must retain its original environment` | Codex 웹·클라우드 작업 | 확인된 방법 없음, 환경 초기화 금지 |
| `Input exceeds the maximum length of 1048576 characters.` | 한 번에 너무 긴 입력 | 나눠서 보내기 |

### 대기열 후속 메시지: "App-server queued follow-up no longer exists"

2026년 9월 11일부터 10월 1일까지 Windows·macOS·Linux 데스크톱 앱과 VS Code 확장 26.908.40401에서 이슈 7건이 올라온 묶음입니다. 가장 흔한 순서는 Codex가 작업하는 동안 후속 메시지를 대기열에 넣고, 그 메시지를 편집하거나 회수했다가 다시 보내는 것입니다. 편집하지 않은 평범한 후속 메시지나 자동 컨텍스트 압축 뒤에 생겼다는 보고도 있고, 한 번 걸리면 그 채팅의 이후 전송도 계속 실패했습니다([OpenAI 개발자 포럼의 대기열 메시지 편집 버그 글](https://community.openai.com/t/bug-when-editing-queued-message-error-submitting-message-app-server-queued-follow-up-no-longer-exists/1398267)).

제보자가 효과를 확인한 방법은 두 가지입니다.

- **다른 채팅으로 갔다가 돌아오기**: 8명 정도가 확인했습니다. 다만 한 제보자는 이렇게 하자 대기열의 다른 메시지가 모두 지워졌다고 했으므로, 대기 중인 문장은 먼저 복사해 둡니다.
- **진행 중인 작업이 끝나기를 기다리거나 멈춘 뒤 같은 내용을 새 메시지로 보내기**: 여러 명이 확인했지만 "가끔만 된다"는 제보도 있습니다.

메시지를 지우거나 재시작·업데이트를 반복하는 것은 효과가 없었다고 보고됐습니다.

이 묶음에 OpenAI 직원이 답한 것은 한 번뿐입니다. 9월 13일 [openai/codex #44781](https://github.com/openai/codex/issues/44781)에서 etraut-openai가 "The problem is understood. We have a fix in place, and it will be included in the next release."(문제를 파악했고 수정이 준비돼 다음 릴리스에 들어간다)라고 썼지만 버전은 밝히지 않았고, 그 뒤에도 9월 21일 무렵까지 26.908 빌드에서 제보가 이어졌습니다. 데스크톱 앱 26.1013.31256 코드에는 이 문구가 더 이상 없고, 대기열 경로에서 "Queued follow-up changed before dispatch"라는 새 문구를 냅니다. 최신 빌드에서는 예전 문구 대신 이 새 문구가 보일 것으로 추정되지만, 코드를 보고 한 추정일 뿐 OpenAI가 확인한 내용은 아닙니다.

"Queued follow-up changed before dispatch"는 VS Code 확장 26.930~26.1007에서 `chatgpt.followUpQueueMode`를 `queue`로 두고 후속 메시지를 5~7개 빠르게 연달아 보낼 때 보고됐습니다([openai/codex #50914](https://github.com/openai/codex/issues/50914), 10월 4~14일). 제보자는 다시 시도하다 보면 결국 전송됐다고 했고, Interrupt 모드로 바꾸면 피할 수 있지만 그러면 진행 중인 응답이 멈춥니다. 재시작, 재로그인, 캐시 삭제, Steer 모드는 효과가 없었습니다. 같은 이슈에서 이미 접수된 메시지를 다시 보낼 수 있는 경로가 시뮬레이션으로 지적됐으니, 다시 보내기 전에 앞의 방법으로 중복 여부를 확인합니다. 이슈에 올라온 확장 수정 패치는 OpenAI가 만든 것이 아니므로 설치된 확장 파일을 직접 고치는 방법은 권하지 않습니다.

### Windows dot 작업 답장의 "AbsolutePathBuf" 오류

전체 문구는 `invalid turn/start params: AbsolutePathBuf deserialized without a base path`(코드 -32602)이고, 9월 30일부터 10월 15일까지 이어지며 9월 말 이후 가장 활발한 묶음입니다([openai/codex #49477](https://github.com/openai/codex/issues/49477), [#50428](https://github.com/openai/codex/issues/50428), [#51593](https://github.com/openai/codex/issues/51593)). 연결된 Windows 컴퓨터에서 dot이 만든 작업(영어 화면 표시는 "Cloud / Runs on your computer when available")에 데스크톱 입력창으로 직접 답장할 때 생깁니다. 작업 기록은 그대로 열리고, dot이 그 작업으로 보내는 메시지는 여전히 전달됩니다. Windows의 ChatGPT 웹에서 같은 오류를 봤다는 보고도 있습니다.

제보자들이 확인한 방법은 작업마다 따로 적용해야 합니다.

- **입력창 아래 권한 메뉴를 "맞춤형"에서 "나 대신 승인"으로 바꾸기**: 4~5명이 확인했습니다. 메뉴 안에서 "맞춤형"은 "사용자 지정(config.toml)"으로 표시됩니다. 한 제보자는 나중에 같은 작업에서 다시 실패했다고 했으니, 바뀐 설정이 유지되는지 확인합니다.
- **"전체 액세스"로 바꾸기**: 2명이 확인했지만 제보자들 스스로 권한을 넓히라는 권장이 아니라고 강조했습니다. 전체 액세스는 Codex가 승인 없이 더 많은 작업을 하게 하므로 회사 PC나 중요한 저장소에서는 피하는 편이 낫습니다. "나 대신 승인"도 승인 판단을 Codex의 자동 검토에 맡기는 설정이라, 원래 쓰던 권한과 범위가 같지 않습니다.
- **새 로컬 작업이나 WSL의 Codex CLI로 넘겨서 이어 가기**: 한 제보자는 넘기기 전에 작업 폴더의 파일을 해시로 대조하고 git 번들로 백업해 63개 파일이 모두 그대로인 것을 확인했습니다.

재시작, 재부팅, 업데이트, 재설치, 보관, 다시 시도, Windows 폴더를 명시한 새 작업은 효과가 없었습니다. 2026년 10월 16일 기준으로 GitHub와 X 어디에도 이 오류에 대한 OpenAI 직원 답변은 없습니다.

### 시간 초과: "Timeout"이 뜨거나 두 번째 줄이 비어 있을 때

"Timeout", "App server request expired while queued", 또는 두 번째 줄 없는 제목만 뜨는 경우입니다. 5월부터 9월 말까지 macOS 데스크톱 앱, 10월에는 Linux의 VS Code 확장 26.1007.21434에서 보고됐습니다(#23644, #27395, [#53353](https://github.com/openai/codex/issues/53353)). 제보된 조건은 이렇습니다.

- 앱을 3.5일가량 켜 둔 상태
- 대화 기록 파일이 154MB에 이른 거대한 채팅
- 여러 Codex 프로세스가 함께 쓰는 `~/.codex/logs_2.sqlite`가 1.4~2.2GB로 커진 상태
- 이전 실행에서 남은 `codex_chronicle` 프로세스
- 다른 프로그램 때문에 CPU가 바쁜 상태

제보자가 효과를 확인한 방법은 다음과 같습니다.

1. 앱을 완전히 종료하고 다시 실행합니다. 효과는 대개 일시적이었습니다.
2. 1~5분 기다렸다가 다시 보냅니다. 앞 절의 방법으로 메시지가 이미 들어갔는지 먼저 확인합니다.
3. macOS에서 남은 `codex_chronicle` 프로세스를 찾아 종료합니다. 아래 명령은 프로세스 번호, 시작 시각, 경과 시간을 함께 보여 주므로 지금 앱을 켠 시각보다 오래전에 시작된 것이 남은 프로세스입니다. 한 제보자는 이것을 정리한 뒤 전송 실패가 4번에서 0번으로 줄었습니다.

   ```bash
   ps -axo pid,lstart,etime,command | grep codex_chronicle
   ```

4. 관계없는 고부하 프로세스를 끄거나, 새 채팅에서 이어 갑니다.

컨텍스트 압축은 효과가 없었습니다. `logs_2.sqlite`가 커져 있어도 이 파일을 지우라고 권한 제보자는 없으니 손대지 않는 편이 안전합니다. Windows에서 어떤 Codex 프로세스를 꺼도 되는지는 [Windows의 Codex 백그라운드 프로세스: 종료해도 되는 상태 판별법](https://blog.laozhang.ai/ko/posts/codex-windows-background-processes)에서 확인할 수 있습니다.

### VS Code에서 "Cannot steer conversation … without an active turn id"

VS Code 확장 26.1007.21434(Ubuntu)에서 한 제보자가 자세히 남긴 경우입니다([OpenAI 개발자 포럼의 "Why did the message fail to submit?" 글](https://community.openai.com/t/why-did-the-message-fail-to-submit/1405534), 10월 12~13일). 서버는 작업이 끝났다고 기록했는데 확장 화면은 계속 진행 중으로 남았고, 33초 뒤 후속 메시지가 "active turn id가 없다"며 거부된 뒤로는 전송이 모두 시간 초과로 실패했습니다. 이 제보자에게 통한 방법은 명령 팔레트에서 `Developer: Restart Extension Host`를 실행하는 것뿐이었습니다. 이 명령은 다른 확장까지 다시 시작하고 진행 중이던 Codex 세션과 하위 에이전트도 끊으므로, 실행한 뒤에는 각 채팅이 어디까지 진행됐는지 다시 확인해야 합니다.

같은 글에는 "Codex: New Codex Agent"로 새 패널을 열고 기록에서 해당 대화를 다시 여는 방법도 제안됐지만 효과를 확인한 사람은 없습니다. 원인에 대한 공식 설명도 없습니다.

### "agent loop died unexpectedly": 작업 루프가 죽은 채팅

`failed to start turn: internal error; agent loop died unexpectedly` 또는 `failed to submit turn input: …`로 나오며, 5월 22일부터 10월 10일까지 macOS·Windows 데스크톱 앱에서 보고됐습니다([#23971](https://github.com/openai/codex/issues/23971), [#34937](https://github.com/openai/codex/issues/34937), [#47139](https://github.com/openai/codex/issues/47139) 등). 대답하지 않고 둔 승인 요청으로 돌아왔을 때, 승인 도중 Plus 요금제의 5시간 사용 한도에 걸렸을 때(이 경우 한도가 풀린 뒤에도 그 채팅은 살아나지 않았습니다), 하위 에이전트를 닫을 때, 압축을 여러 번 거친 오래된 채팅에서 생겼습니다.

앱을 완전히 종료하고 다시 실행하면 일시적으로 풀렸다는 제보가 6명 정도 있고, 한 제보자는 앱 업데이트로 고쳐졌으며 죽었던 세션도 망가지지 않았다고 했습니다. 다른 채팅은 정상으로 동작하므로 급하면 새 채팅에서 이어 갑니다. 실패한 메시지는 대화 기록에 저장되지 않았다는 보고(#35949)가 있어, 이 경우 다시 보내도 중복될 가능성은 낮습니다. 사용 한도가 원인이라면 [Codex 주간 한도 초기화: 복구 시각 확인부터 유료 즉시 재설정까지](https://blog.laozhang.ai/ko/posts/openai-codex-usage-limits)에서 다시 쓸 수 있는 시각을 확인합니다.

### "thread not found"와 "no client found": 채팅 상태가 어긋난 경우

`thread not found:` 뒤에 채팅 ID가 붙는 오류는 저장된 채팅을 열자마자 메시지를 보냈을 때, 또는 내부 서버에서는 이미 닫힌 채팅을 앱 화면이 계속 열린 상태로 기억하고 있을 때 생겼습니다([openai/codex #30710](https://github.com/openai/codex/issues/30710)). 데스크톱 앱을 다시 시작하거나 새 창을 열면 풀렸고, 채팅 분기(fork)는 효과가 없었습니다. 가장 최근 보고는 10월 15일 Windows입니다.

`no client found`는 Remote SSH로 원격 호스트를 쓰거나 창을 여러 개 띄웠을 때, 채팅의 주인이 다른 창이나 클라이언트로 넘어가 지금 창이 따라가기만 하는 상태에서 나왔습니다([openai/codex #49892](https://github.com/openai/codex/issues/49892)). 대화를 다시 여는 것은 효과가 없었고, 보조 창을 닫아 보라는 제안은 검증되지 않았습니다.

### Windows 파일 오류: EPERM, ENOENT, rollout path

**EPERM**: `EPERM: operation not permitted, rename '…\.codex-global-state.json.tmp-…' -> '…\.codex-global-state.json'`은 Windows 10·11 데스크톱 앱 26.1002~26.1007에서 보고됐고, 로그에는 "Failed to persist queued submission outcome"이 함께 찍혔습니다(#52012). 첫 제보자의 PC는 회사 보안 정책으로 파일 시스템 필터가 걸린 관리 대상 PC였지만, 특정 보안 프로그램이 원인으로 밝혀지지는 않았습니다. 이 오류에서는 실패로 보인 메시지가 실제로 전달된 경우가 있었고 다시 시도가 중복을 낳았으니, 반드시 앞의 확인 순서를 먼저 거칩니다. 상태 파일 재생성, 완전 재시작, Windows Search 중지는 효과가 없었습니다. 회사 PC라면 두 번째 줄 원문과 발생 시각을 사내 IT 담당자에게 함께 전하는 것이 다음 단계입니다.

**ENOENT**: 프로젝트를 지정하지 않은 채팅에서 `ENOENT: no such file or directory, mkdir '\\?'`가 나면, `~/.codex/config.toml`의 `[desktop]` 항목에 있는 `projectlessWorkspaceRoot`가 지금은 없는 폴더를 가리키고 있을 수 있습니다. 제보자는 이 값을 실제로 있는 폴더로 바꾸고 앱을 다시 시작해 해결했습니다([openai/codex #52386](https://github.com/openai/codex/issues/52386)). 이 설정 키는 데스크톱 앱 26.1013.31256에도 들어 있습니다. Windows 원격 제어로 프로젝트 없는 채팅을 만들 때 나오는 "Unable to resolve projectless chat folder"는 호스트 PC에서 직접 만들거나 휴대폰에서 만들면 됐다는 보고가 있습니다([openai/codex #53264](https://github.com/openai/codex/issues/53264)).

**rollout path**: 앞에서 말한 "failed to resolve rollout path … file does not exist"는 세션 파일을 손으로 지운 뒤에 생겼습니다(#30924). 한 제보자는 빠진 JSONL 파일을 다시 만들어 넣은 다음 앱에서 그 채팅을 보관하고 삭제해 해결했습니다. 재설치와 새 `.codex` 폴더는 효과가 없었으니, 깨끗한 프로필로 시험해 볼 때도 `%USERPROFILE%\.codex` 폴더는 먼저 백업합니다.

### Codex 웹·클라우드 작업: "Unable to determine project root for task"

Codex 웹이나 클라우드 작업에서 나오는 `Unable to determine project root for task`(9월 30일~10월 4일)와 `a managed thread must retain its original environment`(10월 12~16일, 데스크톱·웹·Android)는 2026년 10월 16일 기준으로 통하는 우회책이 보고되지 않았습니다([openai/codex #49497](https://github.com/openai/codex/issues/49497), [#53459](https://github.com/openai/codex/issues/53459), [#54395](https://github.com/openai/codex/issues/54395)). 강력 새로고침, 환경 수정 후 다시 게시, 환경 새로 만들기는 효과가 없었고, OpenAI 지원팀이 권한 방법인 새 환경 만들기는 한 사용자의 경우 "Task creation is not yet confirmed…" 표시에서 24분 동안 멈춰 버렸습니다. 제보자들은 작업 내용을 보존하기 전에는 환경을 초기화하거나 삭제하지 말라고 당부합니다. 한 제보자는 dot을 통해서는 그 세션에 메시지를 전달할 수 있었다고 했습니다.

### 입력 크기 제한: 1,048,576자와 4MiB

오픈소스 app-server 코드에서 텍스트 입력 상한은 1,048,576자이고, 넘으면 `Input exceeds the maximum length of 1048576 characters.`가 두 번째 줄에 나옵니다. 긴 로그나 파일 내용을 통째로 붙였다면 나눠서 보내거나 파일로 첨부합니다. 브라우저 주석을 한꺼번에 많이 보낼 때는 `decoded message length too large: found 8255971 bytes, the limit is: 4194304 bytes`처럼 4MiB 메시지 한도에 걸린 보고가 있고([openai/codex #52649](https://github.com/openai/codex/issues/52649)), 더 작은 묶음으로 나눠 보내라는 제안은 검증되지 않았습니다.

같은 코드에는 이 밖에도 두 번째 줄로 나올 수 있는 거부 문구가 있습니다. `remote image URLs are not supported; use an inline data URL instead`는 외부 이미지 주소 대신 이미지를 직접 첨부하라는 뜻이고, `Server is draining; retry after reconnecting`은 내부 서버가 종료 중이라 다시 연결한 뒤 보내라는 뜻이며, `invalid thread settings override`나 설정 불러오기 오류는 `config.toml` 설정을 점검하라는 신호입니다. 데스크톱 앱에는 이보다 오래된 app-server가 들어 있을 수 있고, 이 문구들이 모두 사용자 보고에 등장한 것은 아닙니다.

## 해결되지 않을 때 OpenAI에 보낼 정보와 로그 위치

2026년 10월 16일 기준으로 OpenAI의 변경 기록과 도움말, Codex 팀 직원들의 X 게시물 어디에도 이 오류의 원인이나 수정된 빌드는 나오지 않습니다. 직원 답변은 앞에서 본 9월 13일 대기열 오류 건 하나뿐입니다. 위 방법이 통하지 않으면 다음 정보를 모아 알립니다.

- **보내는 곳**: 입력창에 `/`를 입력해 피드백을 보냅니다. 문제가 생긴 채팅에서 보내면 그 세션을 함께 공유할지 고를 수 있고, 보낸 뒤 받는 세션 ID를 이슈나 문의에 붙이면 됩니다. [openai/codex GitHub 이슈 목록](https://github.com/openai/codex/issues)에서 두 번째 줄 문구로 검색해 같은 이슈가 있으면 거기에 덧붙입니다.
- **적을 내용**: 두 번째 줄 원문, 발생 시각, 쓰는 앱과 버전(ChatGPT 데스크톱 앱인지 VS Code·Cursor 확장인지), 운영체제, 로컬 채팅·클라우드 작업·dot 작업 중 어느 것인지, 권한 설정, 이미 해 본 조치와 결과.
- **로그 위치**: macOS 데스크톱 앱 로그는 `~/Library/Logs/com.openai.codex/YYYY/MM/DD`, 대화 기록은 `~/.codex/sessions`, 보관된 대화는 `~/.codex/archived_sessions`에 있습니다. 발생 시각 전후에서 `turn/start`나 `submit failed`가 들어간 줄을 찾으면 원인을 좁히는 데 도움이 됩니다.
- **공유 전 확인**: 로그와 세션 파일에는 프로젝트 경로, 코드, 대화 내용이 들어 있습니다. OpenAI 문서도 공유 전에 민감한 정보가 없는지 검토하라고 안내합니다.

조치하는 동안 지킬 것도 정리해 둡니다. `~/.codex/sessions`의 파일은 손으로 지우지 않고, 깨끗한 프로필로 시험하기 전에는 `.codex` 폴더를 백업하며, 클라우드 작업 환경은 작업을 보존하기 전에 초기화하지 않습니다.

## 재시작과 Windows에 관한 질문

### Codex 앱을 완전히 종료하면 채팅 내용이 사라지나요?

보고된 사례에서는 사라지지 않았습니다. 대화 기록은 `~/.codex/sessions`에 파일로 남고, 시간 초과 이슈(#27395)의 제보자는 재시작 뒤 데이터 손실이 없었다고 했으며, "agent loop died" 이슈(#23971)에서도 앱 업데이트가 죽었던 세션을 망가뜨리지 않았다는 보고가 있습니다. 다만 아직 보내지 않은 입력창의 문장이나 대기열 메시지가 보존된다는 보장은 없으니 종료 전에 복사해 둡니다. VS Code에서 확장 호스트를 다시 시작하면 진행 중이던 세션과 하위 에이전트가 끊기므로, 다시 연 뒤 각 채팅의 진행 상태를 확인합니다.

### 회사 PC나 Windows에서만 Codex 채팅 전송이 안 되는 이유는 무엇인가요?

Windows에만 몰린 원인이 몇 가지 있습니다. dot이 만든 작업에 답장할 때의 AbsolutePathBuf 오류, 상태 파일 이름을 바꾸지 못하는 EPERM 오류(첫 제보는 회사 관리 PC), 프로젝트 없는 채팅의 ENOENT 오류입니다. 어느 쪽인지는 두 번째 줄 문구로 구분되며, 각각의 조치는 위 표와 해당 절에 있습니다. 두 번째 줄 없이 전송 버튼만 반응하지 않는다면 시간 초과 쪽을 먼저 의심하고, 새 채팅과 CLI로 범위를 가르는 것부터 시작합니다.

## 참고 자료

이 글이 링크한 외부 페이지를 본문에 나온 순서대로 정리했습니다. 마지막 업데이트: 2026-10-16.

- [openai/codex GitHub 이슈 #27395](https://github.com/openai/codex/issues/27395) (github.com)
- [#23644](https://github.com/openai/codex/issues/23644) (github.com)
- [OpenAI의 Codex 문제 해결 문서](https://learn.chatgpt.com/docs/reference/troubleshooting) (learn.chatgpt.com)
- [openai/codex #52012](https://github.com/openai/codex/issues/52012) (github.com)
- [openai/codex #44781](https://github.com/openai/codex/issues/44781) (github.com)
- [#35949](https://github.com/openai/codex/issues/35949) (github.com)
- [#45019](https://github.com/openai/codex/issues/45019) (github.com)
- [openai/codex #30924](https://github.com/openai/codex/issues/30924) (github.com)
- [OpenAI 개발자 포럼의 대기열 메시지 편집 버그 글](https://community.openai.com/t/bug-when-editing-queued-message-error-submitting-message-app-server-queued-follow-up-no-longer-exists/1398267) (community.openai.com)
- [openai/codex #50914](https://github.com/openai/codex/issues/50914) (github.com)
- [openai/codex #49477](https://github.com/openai/codex/issues/49477) (github.com)
- [#50428](https://github.com/openai/codex/issues/50428) (github.com)
- [#51593](https://github.com/openai/codex/issues/51593) (github.com)
- [#53353](https://github.com/openai/codex/issues/53353) (github.com)
- [OpenAI 개발자 포럼의 "Why did the message fail to submit?" 글](https://community.openai.com/t/why-did-the-message-fail-to-submit/1405534) (community.openai.com)
- [#23971](https://github.com/openai/codex/issues/23971) (github.com)
- [#34937](https://github.com/openai/codex/issues/34937) (github.com)
- [#47139](https://github.com/openai/codex/issues/47139) (github.com)
- [openai/codex #30710](https://github.com/openai/codex/issues/30710) (github.com)
- [openai/codex #49892](https://github.com/openai/codex/issues/49892) (github.com)
- [openai/codex #52386](https://github.com/openai/codex/issues/52386) (github.com)
- [openai/codex #53264](https://github.com/openai/codex/issues/53264) (github.com)
- [openai/codex #49497](https://github.com/openai/codex/issues/49497) (github.com)
- [#53459](https://github.com/openai/codex/issues/53459) (github.com)
- [#54395](https://github.com/openai/codex/issues/54395) (github.com)
- [openai/codex #52649](https://github.com/openai/codex/issues/52649) (github.com)
- [openai/codex GitHub 이슈 목록](https://github.com/openai/codex/issues) (github.com)