codex-code-mode-host를 Apple이 확인할 수 없을 때

macOS에서 codex-code-mode-host를 Apple이 확인할 수 없다는 경고가 뜨면 격리 속성을 지우는 명령부터 실행하지 마세요. 먼저 Codex 버전과 Mac 아키텍처, helper의 실제 위치, 서명 검증, 직접 실행 결과를 차례로 확인해야 합니다. spctl의 rejected 한 줄만으로 파일 손상이나 미공증을 단정해서도 안 됩니다.

2026년 9월 23일 공개된 Codex 이슈에는 Intel Mac의 Codex CLI 0.156.0 Homebrew Cask 설치본에서 source=Unnotarized Developer ID가 나오고 실제 보안 경고가 뜬 사례가 있습니다. 반면 제가 확인한 Apple Silicon의 CLI 0.156.1 npm 설치본은 서명 검증과 helper 직접 실행에 성공했습니다. 버전·아키텍처·설치 경로가 다르면 같은 이름의 오류처럼 보여도 결과가 다를 수 있습니다.

Codex 버전과 설치 경로는 어떻게 확인하나요?

터미널을 열고 다음 두 줄을 실행합니다.

command -v codex
codex --version

첫 줄은 현재 실행되는 Codex의 위치, 둘째 줄은 버전을 보여 줍니다. 공개 이슈의 문제 환경은 Intel Mac의 /usr/local Homebrew Cask와 CLI 0.156.0이었습니다. Apple Silicon의 /opt/homebrew, npm 전역 설치, 0.156.1을 같은 환경으로 취급하면 안 됩니다.

Mac 아키텍처도 확인합니다.

uname -m

x86_64면 Intel, arm64면 Apple Silicon입니다. 이 값과 Codex 버전을 메모해 두면 이미 해결된 패키징 문제인지, 특정 아키텍처의 배포 파일 문제인지 구분하기 쉬워집니다.

OpenAI 공식 Codex CLI 문서는 macOS/Linux standalone installer를 기본 설치 경로로 안내하고 npm과 Homebrew도 별도 설치 방법으로 제공합니다. 따라서 /opt/homebrew/bin처럼 보이는 경로만으로 설치 관리자를 단정하지 말고 실제 링크 대상과 패키지를 함께 확인해야 합니다.

codex-code-mode-host 파일은 어디서 찾나요?

npm 전역 설치라면 다음 명령으로 파일을 찾을 수 있습니다.

find "$(npm root -g)/@openai/codex" \
  -type f -name codex-code-mode-host -print

이 명령은 npm 설치 전용입니다. 경로가 하나 나오면 그 값을 복사해 아래 명령의 /찾은/경로/codex-code-mode-host 자리에 넣습니다. 아무것도 나오지 않아도 설치 파일 누락을 뜻하지는 않습니다. Homebrew Cask나 standalone installer를 썼다면 먼저 다음처럼 현재 실행 파일의 링크 대상을 확인하세요.

ls -l "$(command -v codex)"
brew info --cask codex 2>/dev/null

첫 줄이 node_modules/@openai/codex로 이어지면 npm 설치입니다. Cask 정보가 나오면 Homebrew 설치입니다. 어느 쪽인지 확인되지 않거나 helper 경로를 찾지 못하면 임의 파일을 내려받아 끼우지 말고 OpenAI 공식 설치 문서의 현재 설치 방법으로 업데이트하거나 다시 설치하세요.

서명 검증과 실제 실행은 어떻게 나누나요?

먼저 파일 형식과 서명을 읽기 전용으로 확인합니다.

file "/찾은/경로/codex-code-mode-host"
codesign --verify --deep --strict --verbose=2 \
  "/찾은/경로/codex-code-mode-host"

valid on disk와 satisfies its Designated Requirement가 나오면 현재 파일의 코드 서명 검증은 통과한 것입니다. 개발사 표시는 다음 명령으로 볼 수 있습니다.

codesign -dv --verbose=4 \
  "/찾은/경로/codex-code-mode-host" 2>&1

제가 Apple Silicon과 Codex CLI 0.156.1에서 확인했을 때 helper는 ARM64 Mach-O였고 OpenAI Developer ID 서명을 표시했습니다. codesign --verify는 exit 0이었습니다.

spctl rejected가 나오면 무엇을 읽어야 하나요?

다음 명령은 Gatekeeper 평가 결과를 보여 줍니다.

spctl -a -vv -t exec \
  "/찾은/경로/codex-code-mode-host"

여기서 중요한 것은 rejected라는 단어 하나가 아니라 뒤의 이유입니다.

• 공개 이슈의 Intel 0.156.0 Cask: source=Unnotarized Developer ID
• 이번 ARM64 0.156.1 npm 대조: the code is valid but does not seem to be an app

두 출력은 같지 않습니다. 제 환경에서는 spctl이 exit 3이었지만 같은 helper의 엄격한 서명 검증과 --help 실행은 모두 성공했습니다. 따라서 CLI helper를 일반 앱 번들과 같은 방식으로 평가한 결과만 보고 “실행 불가”라고 결론내리면 오진할 수 있습니다.

반대로 실제 macOS 경고가 뜨고 Unnotarized Developer ID까지 표시된다면 단순한 표시 문제로 넘기지 마세요. 현재 버전과 아키텍처, 설치 경로, 전체 이유 문자열을 보존하고 최신 공식 버전으로 업데이트한 뒤 다시 확인하는 편이 안전합니다.

실제 보안 경고가 없고 공식 배포본임을 확인했으며 codesign --verify도 통과한 경우에만 helper의 도움말 실행을 마지막 대조군으로 사용할 수 있습니다.

"/찾은/경로/codex-code-mode-host" --help

--help도 파일을 실행하는 명령입니다. 실제 경고가 떴거나 Unnotarized Developer ID, 서명 오류가 남아 있다면 실행하지 마세요. 안전 조건을 통과한 파일에서 usage와 옵션이 출력되고 종료되면 현재 Mac에서 helper 실행이 가능하다는 뜻입니다. 제 ARM64 0.156.1 npm 환경에서는 이 조건을 확인한 뒤 --help가 exit 0으로 끝났습니다.

경고가 계속될 때의 안전한 다음 행동

1. Codex를 공식 설치 경로에서 최신 버전으로 업데이트합니다.
2. 위 네 가지 결과를 다시 확인합니다.
3. 실제 경고가 계속되면 버전·아키텍처·설치 방식과 spctl 이유 문자열을 포함해 Codex 이슈에 보고합니다.
4. 회사나 학교가 관리하는 Mac이면 보안 담당자에게 같은 정보를 전달합니다.

Apple도 출처가 확실하지 않은 앱의 보안 설정을 우회하면 Mac이 악성 코드에 노출될 수 있다고 안내합니다. 그래서 xattr -d com.apple.quarantine처럼 보호 속성을 지우는 명령을 이 글의 기본 해결책으로 제시하지 않습니다. 업데이트된 공식 배포본으로 해결되지 않을 때는 제작사 또는 관리자의 확인을 받는 것이 먼저입니다.

다른 AI 코딩 도구의 결과와 비교할 때는 보안 경고가 난 실행을 단순 실패 시간으로 합치지 말고 같은 입력과 검사 조건으로 AI 코딩 도구를 비교하는 방법처럼 환경과 완료 검사를 따로 기록하세요. Codex가 어느 프로젝트 지침을 읽었는지까지 흔들린다면 활성 AGENTS.md 파일을 확인하는 순서로 설치 문제와 지침 문제를 분리할 수 있습니다.

명령이 실패할 때

codesign에서 서명 오류가 나오면 해당 파일의 직접 실행을 멈추고 공식 재설치를 우선합니다. find가 아무 파일도 찾지 못하면 현재 설치 방식이 npm이 아닐 수 있으므로 command -v codex가 가리키는 설치 관리자를 확인하세요.

xcrun stapler validate가 실패해도 그 한 줄을 공증 실패로 단정하지 마세요. 이번 대조 환경에서는 Command Line Tools 경로가 불완전해 xcrun 자체가 실행되지 않았습니다. 도구 준비 실패와 대상 파일의 공증 상태는 별개의 문제입니다.

자주 묻는 질문

spctl이 rejected면 helper를 삭제해야 하나요?

아닙니다. 먼저 rejected 뒤의 이유와 codesign --verify 결과를 함께 봐야 합니다. 실제 경고, Unnotarized Developer ID, 서명 오류 중 하나라도 남아 있으면 helper를 실행하지 말고 공식 배포본으로 다시 설치하세요. 경고가 없고 공식 배포본·서명 검증까지 확인된 경우에만 --help를 마지막 실행 대조군으로 씁니다.

격리 속성을 지우면 바로 해결되나요?

보호 속성 삭제를 첫 해결책으로 삼지 마세요. 신뢰할 수 있는 공식 배포본인지, 현재 파일의 서명과 버전이 맞는지 먼저 확인해야 합니다. 관리형 Mac이라면 임의로 우회하지 말고 보안 담당자에게 확인 결과를 전달하세요.

확인 범위

이 글은 공개된 Intel Mac·CLI 0.156.0 Cask 사례 한 건과 Apple Silicon·CLI 0.156.1 npm 설치본의 직접 대조를 바탕으로 합니다. Intel 0.156.0 파일은 이 Mac에서 독립 재현하지 않았고, 정확 월간 검색량과 seoin.dev 독자의 직접 반응도 확인하지 못했습니다. 그래서 특정 버전 전체가 안전하거나 위험하다고 일반화하지 않고, 결과를 구분하는 진단 순서만 제공합니다.

검증 기준

• 마지막 업데이트일: 2026-09-23
• 확인 환경: macOS Apple Silicon, Codex CLI 0.156.1 npm 설치본. helper의 파일 형식, Developer ID 서명, codesign --verify, --help, spctl -t exec를 비민감 로컬 환경에서 확인했습니다.
• 주요 근거: OpenAI Codex CLI 공식 문서, Codex 공개 이슈 #47521, Apple의 안전한 앱 열기 안내
• 검색 확인: 2026-09-23 Orca의 Google 웹 검색과 Naver 통합검색에서 codex code mode host Gatekeeper macOS를 확인했습니다. Google 상위 결과는 Desktop 앱의 syspolicyd 문제, 앱 서명 실패, 과거 CLI 인증서 폐기 해결을 섞었고 Naver에서는 helper 이름과 같은 질문을 직접 답하는 한국어 상위 본문을 확인하지 못했습니다.
• 미확인: Intel CLI 0.156.0 Cask 파일의 독립 재현, 정확 월간 검색량, seoin.dev 독자의 실행 성공