Codex에서 'Couldn't load workspace settings'라는 메시지가 표시되면, config.toml을 수정하거나 앱을 재설치하기 전에 어떤 처리 과정이 실패했는지 분리하여 확인해야 합니다. 앱이 열려 있더라도 이 메시지는 나타날 수 있으며, 같은 채팅방에서 모델의 답변을 받을 수도 있습니다. 단순히 이 메시지만으로는 설정 파일 손상, 모델 중단, 계정 정지 여부를 판단할 수 없습니다.
본 문서는 Ofox 운영팀이 작성한 영어 가이드의 한국어 번역본입니다. AI 지원으로 번역 및 편집되었습니다. 대상은 데스크톱 앱에서 새 채팅을 열거나 워크스페이스를 로드할 때 발생하는 오류입니다. Ofox는 API 서비스를 제공하지만, API 서비스로 전환하는 것이 데스크톱 계정 초기화 문제를 해결하는 방법은 아닙니다.
원래 조사는 2026년 10월 16일에 OpenAI의 Codex 리포지토리 내 공개 보고서를 확인한 내용이며, 버전과 실패 특징이 다른 사례들을 다루고 있습니다. 저희는 관리되는 테스트 환경에서 이러한 버그를 재현하지 못했습니다. 아래 비교표와 복구 확인 절차는 해당 보고서를 기반으로 편집된 진단 과정일 뿐이며, 모든 보고서에 적용할 수 있는 해결 방법은 아닙니다.
2026년 10월 25일 출처 재확인: #52342는 현재 closed 상태입니다. 10월 21일~23일의 댓글에는 업데이트 후 워크스페이스 로드가 복구되었다는 보고와, 이후에도 다른 dot 전송 오류가 남아있다는 보고가 있습니다. 이 두 가지 원인이 같다고 확인된 바는 없습니다. 과거 버전에서의 실패를 현재 모든 환경에 적용하지 마시고, 본인의 설치본에서 제공되는 업데이트 내용과 실패하는 작업을 확인해 주십시오.
VS Code 패널의 리소스가 로드되지 않거나 백엔드 프로세스 자체가 시작되지 않는 경우라면, 이보다 더 앞 단계의 다른 문제일 수 있습니다. 또한, 정확한 표시가 Permission mode is unavailable인 상태에서 입력이 전송되지 않았다면, 먼저 전송 처리와 권한 모드를 확인해야 합니다. 비슷한 문구만으로 같은 원인이라고 단정 짓지 마십시오.
재부팅하기 전에 About 화면의 앱 버전, OS, 시간대 정보가 포함된 발생 시각, 그리고 무엇을 열려고 했는지를 기록하고, 저장되지 않은 작업을 저장하십시오. 필요한 것은 최초 실패에 대한 기록입니다. 무관한 변경을 10번 가한 후의 로그만으로는 원인 분리가 어려워집니다.
| 관찰된 내용 | 의미하는 바 | 다음으로 확인할 것 |
|---|
| 새 채팅은 실패하지만, 기존 채팅은 사용 가능함 | 기존 상태의 일부는 이용 가능하다 | 프로젝트 유/무에 따른 새 채팅을 비교해보기 |
| ... | | |
Windows 공개 보고서 #54168에서는 오류가 발생한 동일한 새 채팅에서 설정 로드 경고와 정상적인 모델 답변이 공존하는 사례가 있었습니다. 로그에는 워크스페이스 라우팅이나 challenge 오류가 있었지만, 로컬 설정 읽기는 성공했습니다. 따라서 클라이언트 전체를 사용할 수 없다고 추측하기보다는 실제 작업을 확인해야 합니다. 모든 설정 오류가 무해하다는 의미는 아닙니다.
도구를 호출하지 않는 무해한 입력을 사용하십시오.
Reply with OK without reading files or running commands.
이는 '파일을 읽거나 명령어를 실행하지 않고, OK라고만 답변해 주세요'라는 의미입니다. 현재 진행 중인 실제 작업을 복구 테스트에 사용하지 마십시오. 사용할 수 없는 경로는 '미테스트(未テスト)'로 기록하고, 표를 채우기 위해서 다른 클라이언트를 설치할 필요는 없습니다.
| 테스트 | 기록할 결과 |
|---|
| 기존 데스크톱 채팅 | 답변 있음 / 입력 차단 / 오류 / 미테스트 |
| ... | |
결과의 차이는 조사 범위를 좁히지만, 원인을 확정하지는 못합니다. 프로젝트가 없을 때는 작동하더라도, 그것이 프로젝트 파일이 손상되었다는 증거가 되지는 않습니다. 브라우저가 작동한다고 해서 데스크톱 앱이 같은 네트워크 경로 또는 인증 플로우를 사용하는 것은 아닙니다.
비교하는 동안 계정과 워크스페이스는 일정하게 유지하십시오. 계정, 네트워크, 앱 버전을 한 번에 바꾸면 오류가 사라지더라도 무엇이 효과적이었는지 알 수 없습니다.
앱의 진단 기능이나 로컬에 저장된 데스크톱 로그를 사용하여 테스트 시점 근처의 실패로부터 필요한 필드만 기록합니다. 참고한 macOS 보고서에서는 ~/Library/Logs/com.openai.codex/
현재는 [macOS] 로그 위치가 안내되고 있지만, Windows나 향후 버전에서는 같은 위치가 아닐 수 있습니다. Windows의 경우 앱에서 제공하는 공식 진단 수단이나 지원 안내를 사용하고, 추측하여 삭제한 패키지 디렉토리는 제거하지 마십시오.
다음은 공개된 보고서에서 발견되는 특징들을 정리한 표입니다. 이 내용은 저희 계정의 로그를 전재한 것이 아닙니다.
| 동일한 로그 기록에 있는 필드 | 기록이 지지하는 해석 | 그렇게까지는 단언할 수 없는 것 |
|---|
/settings/user 또는 계정 확인, 403, cloudflare_challenge | 요청이 challenge에 직면함 | 계정 정지, 또는 프록시가 확실한 원인임 |
계정 확인, 로그상의 status=500 , devicecheck_token_generation_failed | 앱이 디바이스 토큰 생성 실패를 보고함 | OpenAI가 HTTP 500을 반환했거나, 설정 오류가 모두 DeviceCheck에서 기인함 |
/settings/user 、432, workspace-routing 메시지 | 해당 설치에서 워크스페이스 라우팅 사용 불가로 보고됨 | 432가 모든 API에서 동일한 의미를 가짐 |
설정 요청 실패와 함께 로컬의 config/read는 성공함 | 장애 중에도 로컬 설정을 읽을 수 있는 경우가 있음 | 원격 초기화나 모든 파일 작업이 성공했음 |
근처에 fs/readFile requires an environmentId가 있음 | 파일 작업에 필요한 환경 정보가 누락됨 | 이것이 화면 경고의 원인이라고 확정할 수는 없음 |
DeviceCheck 분기에서는, status=500은 애플리케이션 계층에서 기록된 값입니다. 이 요청이 OpenAI에 도달했거나, 원격 서버가 HTTP 500을 반환했다는 것을 의미하지 않습니다. #52342의 10월 15일 보충 설명에서도 이러한 구분이 설명되어 있습니다.
여러 줄에서 발견된 403 오류, 다른 경로, 그리고 또 다른 DeviceCheck 오류를 결합하여 하나의 가상의 요청을 만들지 마십시오. 조건에 일치하는 로그 라인의 개수도 사용자 수나 중복되지 않은 실패 작업 횟수가 아닙니다.
#52790에는 Windows에서 설정/계정 요청이 challenge에 직면했다는 보고가 있습니다. 로그아웃 후 재로그인으로 일시적으로 복구된 사례가 있는 반면, 같은 방법으로 복구되지 않은 후속 보고도 있습니다. 재인증은 범위를 한정하여 진단하는 시도로 간주해야 하며, 영구적인 수리책으로는 다루지 마십시오.
작업을 저장하고 다시 로그인할 수 있는지 확인한 후, 일반적인 앱 내 조작으로 로그아웃 및 로그인을 한 번 수행하십시오. 새 채팅을 열고 동일한 작은 테스트를 반복합니다. 또한 다른 새로운 채팅에서도 복구가 지속되는지 기록해 주십시오. 브라우저의 Cookie를 데스크톱으로 복사하거나, 인증서 검증을 비활성화하거나, challenge 토큰을 수정해서는 안 됩니다.
#53994에서는 Chrome은 사용 가능하지만, macOS에서 잠금 해제된 후 등에 데스크톱에서의 실패가 반복되고 있습니다. 후속 진단에서는 서로 다른 요청에 여러 종류의 오류가 확인되었습니다. 프록시 모드 변경이나 브라우저에서의 성공만으로 단일한 근본 원인을 결정할 수 없습니다. 본인의 환경에서 잠금/해제가 방아쇠라면, 그 절차를 보고서에 포함하십시오. 확인하지 않은 기기에도 공통적인 방아쇠라고 서술해서는 안 됩니다.
10월 25일에 확인된 #52790의 후속 댓글에는, 다른 Windows 환경에서 선행된 로컬 프록시 업데이트 처리가 사용자 프록시 설정을 변경했다는 설명도 있습니다. 이는 해당 기기의 조사 결과입니다. 원래 Cloudflare challenge 보고와 동일한 원인임이 확인되지 않았으며, 모두에게 레지스트리 변경을 권장할 근거가 되기도 합니다.
#52342의 초기 보고는 특정 macOS 환경에서 DeviceToken 오류로 인해 새 채팅이 실패한다는 것이었습니다. CLI는 작동했지만, 재부팅이나 재인증으로는 해결되지 않았다고 알려졌습니다. 이 정보가 지지하는 것은 진단적 분기이며, 모든 사용자의 인증 정보를 리셋하라는 조언은 아닙니다. 서두에 언급했듯이, 나중에 업데이트되면서 로딩이 복구되었다는 보고도 있습니다.
앱과 macOS의 정확한 버전, 실패가 토큰의 '생성(Generation)' 문제인지 '등록(Registration)' 문제인지를 기록합니다. 일반적인 업데이트 도구를 사용하여 해당 설치에 제공되는 업데이트를 확인하십시오. 업데이트가 표시되지 않으면 그 결과를 남깁니다. Issue에 기재된 버전 번호는 구형 빌드를 사용하라는 지시가 아닙니다. 장치 검증을 우회하거나 관리되는 보안 제어를 해제하지 마십시오.
- 저장하고 기록하기. 작업 내용, 최초의 오류, 앱 버전, 테스트 시간을 남깁니다. 모든 데이터를 삭제하여 증거를 잃지 않도록 합니다. - 서비스 상태 확인하기. OpenAI Status에서 대상 제품과 시간에 관련된 장애 여부를 확인합니다. 녹색 표시라도 본인의 계정에 고유한 경로가 정상이라는 의미는 아닙니다. - 앱 업데이트 확인하기. 설치된 버전과 제공되는 업데이트 유무를 기록합니다. 업데이트했다면, 다른 변경을 가하기 전에 동일한 테스트를 반복합니다. - 안전한 시점에서 한 번 재부팅하기. 작업을 저장한 후 완전히 종료하고 다시 시작합니다. 다음 새 채팅에서 문제가 재발한다면 '일시적인 회복'일 뿐 '수리된 것'이 아닙니다. - 증거에 맞는 경로 진행하기. challenge, device token, 로컬 실행 실패 시에는 필요한 정보가 다릅니다. 재인증은 일반적인 조작만을 사용하며, 다시 접근할 수 있는 경우에 한해서만 시도합니다. - 동일 실패가 지속되면 중단하기. 아래의 기록표를 첨부하여 지원팀으로 인계합니다. 데이터를 잃는 재설치, 계정 변경, 설정 수정 등을 무한히 반복하지 마십시오.
브라우저나 기존 채팅을 사용할 수 있다면, 적절한 작업을 일시적으로 지속할 수 있는 수단이 됩니다. 다만, 의도했던 작업 공간과 사용 가능한 도구를 확인해야 합니다. 텍스트 응답이 온다는 것이 파일 접근, 브라우저 자동 조작, 동일한 작업 환경 사용 가능성을 증명하는 것은 아닙니다.
확인하는 조치는 실패한 조치와 대응시켜야 합니다. 새 채팅의 실패라면, 대상 프로젝트에서 새로운 채팅을 열고 무해한 테스트를 전송하여 기대하는 작업 공간이 로드되었는지 확인합니다. 파일 접근이 필요하다면, 본인이 명시적으로 허용한 기밀성이 없는 파일을 사용하고 실제로 내용이 읽히는 것을 확인해야 합니다. '접근 가능하다'라는 모델의 응답만으로 판단해서는 안 됩니다.
원래 트리거가 새 창이나 화면의 잠금/해제가 문제였다면, 작업 저장 후 해당 조치도 재현합니다. 결과는 '일회성 관찰된 회복'으로 기록하며, 보편적인 안정성을 보장하지 않습니다. 응답은 오지만 설정 실패가 지속된다면, 부분적 회복입니다.
지원팀에 요약할 때는 다음 기록표를 사용할 수 있습니다. 비공개 로그 전체를 붙여넣을 필요는 없습니다.
제품: 데스크톱 앱 (터미널 CLI만의 문제는 아님)
앱 버전/OS 버전:
발생 시각 및 시간대:
...
공유하기 전에 토큰, Cookie, Authorization 헤더, 계정 식별자, 비공개 경로, 대화 내용을 제외합니다. 기밀 정보가 요구되는 경우에도 적절한 비공개 지원 경로를 통해서만 전송합니다. 목적은 재현 가능한 실패에 대한 설명이지, 대량의 원시 로그 공개가 아닙니다.
- CLI가 background-server 기능 설정 불일치를 표시하는 경우, CLI와 daemon의 설정 일관성을 확인합니다.
- 실행 중인 요청이 완료되기 전에 연결이 끊어지는 경우, 통신 단절을 조사합니다.
- 대화는 되지만 데스크톱이나 브라우저 조작이 실패하는 경우, Computer Use 권한과 연결을 조사합니다.
각각 다른 단계의 문제입니다. 하나가 해결되어도 나머지 정상 작동 여부는 확인할 수 없습니다. 모델이나 API 제공업체의 변경이 작업 공간 설정 초기화를 복구한다는 증거는 제시되지 않았습니다.
영어 원문 및 관련 증상별 가이드: Codex couldn’t load workspace settings: a diagnostic checklist
