Codex CLI 0.139.0 업데이트 정리: 2026년 6월 9일 changelog 핵심 변화

• Codex 2026-06-09 업데이트는 무엇이 바뀐 건가
• Code mode 웹 검색 지원이 의미하는 것
• MCP 도구와 커넥터 호환성 개선
• 진단과 플러그인 관리가 달라진 부분
• 버그 수정에서 봐야 할 실제 사용 안정성
• 업데이트 후 개발자가 확인할 체크포인트
• 정리

Codex 2026-06-09 업데이트는 무엇이 바뀐 건가

2026년 6월 9일 Codex changelog에서 먼저 구분해야 할 부분은 업데이트 대상입니다. 이번 항목은 Codex app의 새 화면이나 모바일 기능이 아니라 Codex CLI 0.139.0 업데이트입니다. 그래서 브라우저에서 보이는 UI 변화보다 터미널에서 Codex를 실행하고, 프로젝트 파일을 읽고, 도구를 호출하고, 샌드박스 안에서 명령을 처리하는 흐름을 기준으로 읽어야 합니다.

공식 changelog의 설치 명령은 아래처럼 안내되어 있습니다. 이미 Codex CLI를 쓰고 있다면 바로 덮어쓰기보다 현재 버전과 설치 경로를 먼저 확인해야 합니다.

npm install -g @openai/codex@0.139.0

이번 업데이트를 한 줄로 줄이면 “Codex가 더 많은 작업을 할 수 있게 됐다”보다 “Codex가 도구를 더 정확히 부르고, 작업 환경을 더 잘 진단하고, 파일과 권한을 덜 헷갈리게 바뀌었다”는 쪽에 무게가 있습니다. AI 코딩 도구를 실제 프로젝트에 붙여 쓰다 보면 기능 개수보다 실패했을 때 어디서 실패했는지 확인하는 능력이 더 중요해집니다. 0.139.0은 그 지점과 맞닿아 있습니다.

특히 프론트엔드 프로젝트에서 Codex에게 “이 오류 원인 찾아서 수정해줘”라고 맡기는 경우를 생각하면 변화가 조금 더 분명해집니다. 오류 메시지만 보고 고치는 작업도 있지만, 최신 라이브러리 문서나 설정 옵션을 확인해야 하는 경우도 있습니다. 또 MCP 도구나 플러그인을 붙여 쓰면 Codex가 단순히 파일만 보는 것이 아니라 외부 도구의 입력값 구조까지 이해해야 합니다. 이번 업데이트는 바로 그 주변부를 손보는 성격이 강합니다.

Code mode 웹 검색 지원이 의미하는 것

가장 눈에 띄는 변화는 Code mode에서 standalone web search를 직접 호출할 수 있게 된 부분입니다. nested JavaScript tool call 안에서도 웹 검색을 호출할 수 있고, 검색 결과는 plaintext 형태로 받을 수 있습니다. 단순히 “웹 검색 버튼이 생겼다”는 의미로 보면 작게 느껴질 수 있지만, Code mode 안에서 작업 흐름을 끊지 않고 외부 정보를 확인할 수 있다는 점이 핵심입니다.

예를 들어 Next.js, React, TypeScript처럼 버전별로 동작이 달라지는 기술을 다룰 때는 기억에 의존한 답변이 위험할 수 있습니다. Codex가 프로젝트 코드를 고치면서 동시에 최신 문서나 이슈 맥락을 확인할 수 있다면, “일단 그럴듯한 수정”보다 “현재 버전에 맞는 수정”에 가까워집니다. 물론 최종 판단은 개발자가 해야 하지만, 검색과 코드 수정 사이의 왕복이 줄어드는 것은 실제 작업 시간에 영향을 줍니다.

프론트엔드 작업에서는 이런 상황이 자주 생깁니다. 빌드는 실패하는데 에러 메시지가 번들러, 타입스크립트, 라이브러리 내부 타입 중 어디에서 온 것인지 애매할 때가 있습니다. 이때 Code mode가 웹 검색을 활용하면 오류 메시지와 현재 프로젝트 구조를 같이 놓고 판단할 수 있습니다. 검색 결과만 따로 보고 복사해 오는 방식보다, 코드 수정 맥락 안에서 근거를 확인한다는 점이 다릅니다.

다만 웹 검색이 가능해졌다고 해서 Codex에게 모든 판단을 넘겨도 되는 것은 아닙니다. 검색 결과가 맞더라도 프로젝트 설정과 맞지 않을 수 있고, 문서의 예시가 현재 코드베이스의 구조와 다를 수 있습니다. 그래서 업데이트 후에는 Codex가 어떤 자료를 근거로 수정했는지, 실제 변경 파일이 그 근거와 맞는지 확인하는 절차가 더 중요해집니다.

MCP 도구와 커넥터 호환성 개선

이번 업데이트에서 겉으로는 덜 화려하지만 실사용에 중요한 항목은 도구와 커넥터의 입력 스키마 처리입니다. changelog에는 tool과 connector input schema가 oneOf, allOf를 보존하고, 큰 스키마를 compact할 때 얕은 구조를 더 많이 유지한다고 되어 있습니다. 이 설명은 처음 보면 내부 구현 변경처럼 보이지만, MCP 도구를 붙여 쓰는 사람에게는 꽤 직접적인 변화입니다.

MCP 도구는 Codex가 외부 시스템과 대화하는 통로 역할을 합니다. 파일 검색, 문서 조회, 이슈 관리, 배포 자동화처럼 도구가 많아질수록 입력값 구조도 단순하지 않아집니다. 어떤 도구는 A 형식 또는 B 형식 중 하나를 받아야 하고, 어떤 도구는 여러 스키마를 조합해 최종 입력을 구성합니다. 이때 oneOf와 allOf 같은 구조가 흐려지면 Codex가 잘못된 입력을 만들 가능성이 커집니다.

예를 들어 플러그인이나 커넥터가 “파일 경로로 조회하는 방식”과 “문서 ID로 조회하는 방식”을 모두 지원한다고 해보겠습니다. 스키마가 명확히 유지되면 Codex는 어느 입력 방식이 필요한지 더 잘 구분할 수 있습니다. 반대로 스키마가 압축되는 과정에서 구조가 뭉개지면, 서로 다른 입력 필드가 뒤섞여 실패하거나 엉뚱한 도구 호출이 나올 수 있습니다.

변경 영역	작업에서 체감되는 지점
웹 검색 호출	Code mode 안에서 공식 문서나 최신 오류 정보를 확인하는 흐름이 짧아집니다.
MCP 스키마 보존	복잡한 도구 입력값을 다룰 때 잘못된 인자 구성 가능성을 줄입니다.
진단 리포트	Codex 실행 환경 문제를 확인할 때 에디터와 pager 관련 단서를 더 얻을 수 있습니다.
이미지 경로 처리	첨부한 이미지 파일을 편집할 때 대화 기록이 아니라 실제 참조 경로를 기준으로 처리합니다.
샌드박스 네트워크	승인된 권한과 프록시 전용 네트워크 설정을 더 일관되게 유지합니다.

자동화 도구를 많이 붙일수록 이런 변화는 더 중요해집니다. Codex를 단순 코드 생성기로만 쓰면 MCP 스키마 개선이 크게 와닿지 않을 수 있습니다. 하지만 GitHub, 문서, 이슈 트래커, 내부 API, 워드프레스 같은 도구를 연결해 작업시키는 구조라면 입력 스키마의 정확도는 곧 작업 실패율과 연결됩니다.

진단과 플러그인 관리가 달라진 부분

codex doctor가 editor와 pager 환경 정보를 local report에 포함하게 된 점도 눈여겨볼 만합니다. Codex CLI는 터미널에서 동작하기 때문에 에디터 설정, 출력 pager, 셸 환경, 권한 설정에 영향을 많이 받습니다. 오류가 났을 때 단순히 “Codex가 안 된다”로 끝나는 것이 아니라, 현재 환경에서 어떤 부분을 먼저 의심해야 하는지 보는 도구가 필요합니다.

특히 Windows, WSL, macOS, 원격 서버처럼 실행 환경이 섞이면 문제 원인이 더 흐려집니다. 에디터가 열리지 않는 문제인지, pager가 출력을 가로막는 문제인지, 권한이나 네트워크 제약인지 구분해야 합니다. codex doctor가 진단 정보를 더 많이 보여주면 이런 문제를 설명하거나 재현할 때 기준점이 생깁니다.

여기서 중요한 점은 JSON output에서 raw value를 redacting한다는 부분입니다. 진단 리포트는 공유할 일이 생길 수 있는데, 환경 변수나 로컬 경로, 설정값이 그대로 노출되면 곤란합니다. 모든 정보가 완전히 안전하다고 단정할 수는 없지만, 적어도 리포트 공유 시 민감한 값이 그대로 노출되지 않도록 의식한 변경으로 볼 수 있습니다.

플러그인 마켓플레이스 쪽도 작은 개선이 들어갔습니다. codex plugin marketplace list --json 출력에 각 marketplace source가 포함되고, 플러그인 목록은 cached remote catalog를 먼저 반환한 뒤 백그라운드에서 새로고침할 수 있습니다. 플러그인을 CLI나 자동화 스크립트에서 다루는 경우에는 JSON 출력이 더 풍부해지는 쪽이 관리에 유리합니다.

이 부분은 블로그 운영 자동화나 사내 도구 연동처럼 반복 작업을 구성할 때 의미가 있습니다. 화면에서 직접 클릭하는 방식이면 목록이 조금 늦게 떠도 크게 불편하지 않을 수 있습니다. 하지만 스크립트가 플러그인 목록을 읽고 조건에 맞는 도구를 선택해야 한다면, 목록 응답 속도와 source 정보는 자동화 판단에 영향을 줍니다.

버그 수정에서 봐야 할 실제 사용 안정성

버그 수정 항목은 하나씩 보면 자잘해 보일 수 있습니다. 하지만 Codex처럼 파일을 읽고, 세션을 이어가고, 이미지를 참조하고, 샌드박스 안에서 명령을 실행하는 도구에서는 이런 수정이 실제 신뢰도와 연결됩니다. 기능이 아무리 많아도 이전 세션을 잘못 이어받거나, 엉뚱한 이미지를 편집하거나, 권한 설정이 풀리면 개발자가 다시 확인해야 하는 비용이 커집니다.

codex resume --last "..."와 codex fork --last "..."에서 trailing argument를 session ID로 잘못 읽던 문제가 수정된 것도 그런 맥락입니다. 사용자는 마지막 세션을 이어가면서 새 prompt를 넣었다고 생각하는데, CLI가 그 값을 세션 ID처럼 해석하면 작업 시작점부터 어긋납니다. 세션 기반 도구에서는 명령 인자 해석이 예상대로 동작하는지가 생각보다 중요합니다.

이미지 편집 수정은 UI 캡처나 블로그 이미지를 다루는 작업에서 체감될 수 있습니다. 이전에는 대화 기록을 바탕으로 이미지를 추측하는 흐름이 있었다면, 이제는 정확히 참조된 이미지 파일 경로를 사용하도록 바뀌었습니다. 이미지가 여러 개 있는 대화에서 “방금 첨부한 첫 번째 이미지”와 “이전 대화의 다른 이미지”가 섞이면 결과가 완전히 달라집니다. 파일 경로 기준 처리는 이런 혼선을 줄이는 방향입니다.

TUI에서 ~가 들어간 bare URL을 끝까지 linkify하는 수정도 있습니다. 기술 문서나 GitHub 경로, 개인 계정 페이지에는 ~가 들어가는 URL이 나올 수 있습니다. 링크가 중간에서 끊기면 터미널에서 바로 열 수 없고, 사용자가 수동으로 다시 복사해야 합니다. 작지만 작업 흐름을 끊는 문제를 줄인 수정입니다.

샌드박스 실행 쪽에서는 승인된 escalation decision을 보존하고, proxy-only networking 설정을 더 일관되게 강제하도록 수정되었습니다. 회사 프로젝트나 운영 서버 설정을 다루는 상황에서는 이 부분을 가볍게 보면 안 됩니다. Codex가 명령을 실행할 수 있다고 해서 모든 네트워크 접근이 허용되어야 하는 것은 아니며, 프로젝트별 보안 정책이 있다면 그 경계가 계속 유지되어야 합니다.

또 /new, /clear, /fork 같은 thread reset 이후에도 cloud-managed requirements나 feature flags가 떨어지지 않도록 한 변경도 있습니다. 세션을 새로 시작하거나 분기할 때 설정이 일부 사라지면, 같은 작업을 이어가는데도 도구 접근이나 기능 동작이 달라질 수 있습니다. 이런 불일치는 디버깅하기 어렵기 때문에 미리 막는 쪽이 낫습니다.

업데이트 후 개발자가 확인할 체크포인트

Codex CLI 0.139.0으로 업데이트한 뒤에는 새 기능을 바로 큰 작업에 투입하기보다 현재 작업 환경이 의도대로 유지되는지 먼저 확인해야 합니다. 특히 기존에 MCP 도구, 플러그인, 샌드박스 권한, 이미지 첨부 작업을 쓰고 있었다면 업데이트 직후 짧은 검증 단계를 거치는 쪽이 안정적입니다.

먼저 현재 설치된 버전을 확인합니다. 전역 설치 환경에서는 Node, npm, PATH가 얽혀 이전 버전이 계속 호출되는 경우가 있습니다. 업데이트 명령을 실행했는데도 터미널에서 다른 경로의 Codex가 잡히면 changelog에 있는 기능을 기대해도 실제로는 반영되지 않을 수 있습니다.

codex --version

다음으로 Code mode에서 웹 검색이 필요한 작업을 작은 범위로 테스트합니다. 처음부터 큰 리팩터링을 맡기기보다, 특정 오류 메시지나 라이브러리 옵션 하나를 기준으로 검색과 코드 검토가 자연스럽게 이어지는지 확인합니다. 검색 결과를 받아도 실제 수정 파일이 엉뚱한 방향으로 바뀌면 의미가 없기 때문입니다.

MCP 도구를 쓰고 있다면 스키마가 복잡한 도구를 하나 골라 호출해봅니다. 파일 경로, 문서 ID, 옵션 객체처럼 입력 방식이 나뉘는 도구가 있다면 더 적합합니다. 기존에 실패하던 도구 호출이 있었다면 같은 prompt로 다시 실행해보고, 인자 구성이 바뀌었는지 비교하면 업데이트 효과를 확인하기 쉽습니다.

이미지 첨부 작업을 자주 한다면 이미지 2개 이상을 넣고 특정 파일을 지정하는 테스트도 필요합니다. UI 캡처, 블로그용 인포그래픽, 에러 화면처럼 이미지가 여러 장인 상황에서 Codex가 요청한 파일을 정확히 참조하는지 확인합니다. 이미지 작업은 한 번 잘못 참조하면 결과물이 바로 어긋나기 때문에 초기에 점검하는 편이 낫습니다.

마지막으로 샌드박스와 네트워크 설정을 확인합니다. proxy-only networking이나 승인 기반 escalation을 쓰는 환경이라면 설정이 실제 명령 실행에서도 유지되는지 봐야 합니다. Codex가 편해질수록 권한 경계는 더 중요해집니다. 자동화 도구가 강력해졌다는 말은 잘못된 권한으로 실행됐을 때 영향도 커질 수 있다는 뜻이기도 합니다.

정리

Codex CLI 0.139.0 업데이트는 겉으로 보기에는 웹 검색, MCP 스키마, doctor, 플러그인 목록, 이미지 경로, 샌드박스 같은 항목이 나뉘어 있습니다. 하지만 한 방향으로 묶어보면 Codex가 실제 개발 환경에서 덜 헷갈리고, 더 잘 진단되고, 도구 호출을 더 정확히 처리하도록 다듬어진 업데이트입니다.

이번 changelog를 볼 때는 “새 기능이 몇 개 늘었나”보다 “Codex에게 작업을 맡겼을 때 내가 무엇을 검증해야 하나”를 기준으로 보는 것이 좋습니다. 웹 검색은 근거 확인을 도와주지만 최종 변경 파일 검토를 대신하지는 않습니다. MCP 스키마 개선은 도구 호출 실패를 줄일 수 있지만, 연결한 도구의 권한 범위를 점검하는 일은 여전히 개발자 몫입니다. 이미지 경로와 샌드박스 수정도 마찬가지입니다. 편해진 만큼 확인 기준을 더 분명히 잡아야 합니다.

Codex를 단순 코드 생성용으로만 쓰고 있다면 이번 업데이트는 작은 편의 개선처럼 보일 수 있습니다. 반대로 CLI, 플러그인, MCP, 이미지 입력, 샌드박스 설정을 함께 쓰고 있다면 0.139.0은 작업 실패를 줄이는 쪽에서 의미가 있습니다. 업데이트 후에는 버전 확인, 작은 검색 테스트, MCP 도구 호출 테스트, 이미지 참조 테스트, 네트워크 권한 확인까지 한 번 짚고 넘어가는 흐름이 가장 현실적입니다.

참고 자료

OpenAI Developers Codex changelog의 2026년 6월 9일 Codex CLI 0.139.0 항목을 기준으로 변경 내용을 확인했습니다.