codex doctor warning이 나왔을 때 확인 순서

codex doctor의 전체 상태가 warning이어도 곧바로 Codex 전체가 고장 났다는 뜻은 아닙니다. 먼저 error인 check가 있는지 보고, warning의 summary와 remediation이 지금 실패한 기능과 관련 있는지 확인하세요. 관련이 없으면 설정을 지우거나 재설치하기 전에 실제 실패 기능을 한 번 더 대조합니다.

Codex CLI 0.156.1에서 개인정보를 가린 JSON 진단을 직접 실행했을 때 check는 24개였고 ok 21개, warning 3개, error 0개였습니다. 전체 상태는 warning이었지만 세 경고는 macOS 보안 기록 접근, 선택 MCP 설정, 비대화형 터미널 환경처럼 서로 다른 범위였습니다.

codex doctor 결과는 어떻게 저장하나요?

터미널에서 다음 명령을 실행합니다.

report="$(mktemp ./codex-doctor.XXXXXX)"
codex doctor --json > "$report"
echo "$report"

먼저 새 임시 파일에 redacted JSON을 저장합니다. mktemp가 매번 다른 이름을 만들기 때문에 이전 보고서를 덮어쓰지 않습니다. 마지막 줄에 표시된 파일 경로를 아래 $report 명령에서 그대로 사용합니다.

현재 CLI 도움말은 --json을 개인정보를 가린 기계 판독용 보고서로 설명합니다. 그래도 공개 이슈나 메신저에 파일 전체를 바로 올리지 말고, 필요한 check의 ID·status·summary만 먼저 봅니다.

jq '{overallStatus, counts: (reduce (.checks[]?.status // empty) as $s ({ok:0, warning:0, error:0}; .[$s] += 1))}' "$report"

직접 재시험한 기대 결과는 overallStatus가 warning이고, counts 아래에 ok: 21, warning: 3, error: 0이 모두 표시되는 형태였습니다. 환경별 개수는 달라질 수 있지만 이 명령은 0개 상태도 생략하지 않습니다.

jq: command not found가 나오면 먼저 command -v jq로 설치 여부를 확인하세요. 설치되지 않았다면 설정을 바꾸지 말고 $report 파일을 텍스트 편집기로 열어 checks 배열의 status를 확인합니다. 필드가 없거나 JSON 구조가 다르면 억지로 해석하지 말고 codex --version과 원본 구조를 함께 기록하세요.

warning은 어떤 필드부터 읽나요?

id, summary, remediation 순서로 읽습니다. 먼저 각 warning의 세 필드만 추립니다.

jq '.checks[] | select(.status != "ok") | {id, status, summary, remediation}' "$report"

읽는 순서는 다음과 같습니다.

1. id: 어느 기능 범위인지 확인합니다. 예를 들어 terminal, MCP, desktop 경고는 같은 문제가 아닙니다.
2. summary: 무엇이 관측됐는지 읽습니다. “확인할 수 없음”과 “실패함”을 구분합니다.
3. remediation: 도구가 제시한 다음 확인만 적용합니다. 경고 하나 때문에 전체 설정 폴더를 지우지 않습니다.

이번 비대화형 실행의 terminal.env 경고는 TERM=dumb 때문에 색상과 커서 제어가 꺼졌다는 내용이었습니다. 이는 이 자동 실행 환경의 조건이며, 일반 터미널에서도 같은 경고가 난다고 단정할 수 없습니다.

어떤 경고부터 고쳐야 하나요?

현재 실패한 작업과 직접 연결되는 경고부터 봅니다.

지금 막힌 작업	먼저 볼 check	다음 확인
터미널 화면이 깨지거나 입력이 이상함	terminal.*	일반 대화형 터미널에서 doctor를 다시 실행하고 TERM 조건을 비교
MCP 서버가 시작되지 않음	mcp.*	해당 서버 하나의 명령·환경 변수·활성 상태 확인
Desktop 보안 경고가 의심됨	desktop.*	summary가 실제 차단인지 기록 접근 불가인지 구분
모델 응답·계정 사용량 문제	관련 check가 있는지 확인	doctor에 없으면 계정 상태와 실제 오류를 별도로 확인

관련 warning이 없다고 실제 오류가 없다는 뜻도 아닙니다. 공개 이슈에는 doctor가 유효 설정을 경고하거나 필요한 정보를 보고하지 않는 사례도 있습니다. doctor는 범위를 좁히는 단서이지 모든 장애를 판정하는 보증서가 아닙니다.

재설치 전에는 무엇을 다시 시험하나요?

경고의 remediation을 적용한 뒤에는 doctor 상태만 다시 보는 데서 끝내지 않습니다.

1. 실패했던 최소 작업을 같은 입력으로 다시 실행합니다.
2. 마지막 성공 단계와 첫 실패 줄을 기록합니다.
3. doctor warning이 사라졌어도 실제 작업이 계속 실패하면 별도 원인으로 봅니다.
4. warning이 남아 있어도 실제 작업이 성공하고 해당 기능을 쓰지 않는다면 즉시 전체 재설치할 근거는 약합니다.

설정 삭제, logout, 앱 제거는 되돌리기 비용이 큽니다. 먼저 redacted 보고서를 보존하고 관련 check 하나만 좁힌 뒤 실제 기능을 재시험하세요.

진단이 설정 파일을 제대로 읽었는지부터 의심된다면 Codex가 읽은 AGENTS.md 파일을 확인하는 방법으로 지침 로드 범위를 따로 확인할 수 있습니다. 실제 기능을 재시험할 때는 AI 코딩 도구를 같은 입력과 검사 명령으로 비교하는 법처럼 입력·기대값·검사 명령을 고정합니다. 두 문제를 doctor의 전체 warning 하나로 뭉치지 않는 것이 핵심입니다.

자주 묻는 질문

warning이 하나라도 있으면 Codex를 재설치해야 하나요?

아닙니다. 먼저 error 개수와 warning의 기능 범위를 봅니다. 현재 실패한 작업과 관련된 remediation만 적용한 뒤 같은 최소 작업을 다시 시험하세요.

error가 0이면 실제 오류도 없다는 뜻인가요?

아닙니다. doctor에 해당 기능의 check가 없거나 별도 계정·서비스 문제가 남을 수 있습니다. doctor 결과와 실제 작업의 성공·실패를 따로 기록해야 합니다.

검증 기준

• 마지막 확인: 2026-09-24
• 확인 환경: macOS, Codex CLI 0.156.1, 비대화형 셸
• 직접 결과: check 24개 중 ok 21, warning 3, error 0; overallStatus warning
• 공개 질문: doctor의 누락 정보, macOS 보안 오경고, 설치 진단 기대를 다룬 GitHub 이슈 3건
• 한계: 정확 월간 검색량, seoin.dev 독자 직접 질문, 운영체제별 check 차이, doctor의 전체 탐지 범위는 미확인
• 주요 근거: legacy rollout 오진 이슈, macOS 보안 경고 이슈, 설치 진단 질문
• 공식 문서: 2026-09-24 공식 OpenAI Docs 검색에서 doctor 전용 설명을 찾지 못해 설치된 CLI 도움말과 직접 출력 범위만 사용함
• 독자 판정선: 보고서 생성 성공, error 개수를 포함한 집계 확인, 현재 실패 기능과 관련된 warning 식별, 같은 최소 작업의 성공·실패 기록까지 마치면 재설치 여부를 판단할 수 있음