TALENTCLOUD

NEW新サービスのご案内：HTMLを社内外にセキュアに共有できる無料ツール「briefroom」をリリースしました

◀ AI情報ブログ一覧へ
約10分で読めます

codexを開くとコンピュータが破損します マルウェア判定の正体と直し方

AIセキュリティ業務活用
寺師 岳見監修: 寺師 岳見(株式会社タレントクラウド 代表取締役)フォロー最新のAI情報を発信中
Codex CLIがmacOSにブロックされる原因と対処を示した図解。旧証明書で署名された0.119.0より前のnpm版がmacOSにブロックされ、公式スタンドアロン版の新証明書0.119.0以降へ入れ替える流れを示し、下段で警告の強制解除ではなく古いものを削除して新しいものを入れるのが正解だと示した、「警告を消しにいかない」というコピー付きのインフォグラフィック

Claude CodeからOpenAIのCodex CLIを呼び出したら、Macに止められました。

ターミナルから直接 codex --version を叩いても同じです。しかも出てきたのは、よくある「開発元を確認できないため開けません」ではありませんでした。

Macに表示された警告ダイアログ。「codexを開くとコンピュータが破損します。ゴミ箱に入れる必要があります。」という文言と、ゴミ箱に入れる・キャンセルの2つのボタン

「開く」に相当するボタンがありません。

この記事は、Macで開発環境を触る方向けの記録です。ただ、結論の部分は非エンジニアにも効きます。セキュリティ警告を消しにいってはいけない理由が、今回きれいに実証されたので。

2種類の警告が出る どちらも「開発元を確認できません」とは別物

同じ原因でも、出てくるダイアログは2種類あります。

パターンA。実行しようとした時点で止められる型。

"codex"を開くとコンピュータが破損します。ゴミ箱に入れる必要があります。

このファイルはダウンロードされたものです。ダウンロード日は不明です。

ボタンは「ゴミ箱に入れる」と「キャンセル」の2つだけです。

パターンB。すでに処理されたあとに知らされる型。

Macに表示された警告ダイアログ。「マルウェアはブロックされてゴミ箱に移動されました」「codexにはマルウェアが含まれているため開けませんでした。この操作によるMacへの損害はありませんでした。」という文言と、完了ボタン

マルウェアはブロックされてゴミ箱に移動されました

codexにはマルウェアが含まれているため開けませんでした。この操作によるMacへの損害はありませんでした。

こちらはボタンが「完了」だけ。しかも過去形です。 「移動されました」と書いてあるとおり、この時点でファイルは実際にゴミ箱へ移されています。あとで再インストールが必要になるのは、これが理由です。

さて、ここが大事なところです。どちらのダイアログにも「開く」に相当する選択肢がありません。

見慣れた「開発元を確認できないため開けません」のほうは、システム設定のプライバシーとセキュリティに「このまま開く」が出てきます。署名や公証が確認できないだけなので、利用者の判断で通す道が残されている。

今回のは違います。例外許可の導線がそもそも用意されていない種類の表示です。設定画面を探しても「このまま開く」は見つかりません。私も最初に探しました。ありませんでした。

先に書いておくと、この警告は、Codexそのものからマルウェアが見つかったという意味ではありません。 旧証明書で署名されたバイナリを、macOSのセキュリティ保護がブロックした結果として、この文言が出ています。理由は次の章で説明します。

つまり、この2つは見た目が似ているだけで別のレイヤーの話です。ここを取り違えると、対処の方向を間違えます。

原因はOpenAIの証明書失効 2026年4月に告知されていた

不思議な話です。OpenAI公式のCodex CLIが、なぜマルウェア扱いされるのか。

答えは公式が出していました。Our response to the Axios developer tool compromiseという2026年4月10日の発表です。

経緯はこうです。

  1. 2026年3月31日、広く使われている第三者ライブラリAxiosがサプライチェーン攻撃で侵害された(悪意あるバージョン1.14.1)
  2. OpenAIがmacOSアプリの署名に使うGitHub Actionsのワークフローが、その悪意あるAxiosを実行していた
  3. そのワークフローは、ChatGPT Desktop・Codex・Codex CLI・Atlasの署名証明書にアクセスできる状態だった
  4. OpenAIの分析では、証明書が実際に盗まれた可能性は低い。それでも念のため侵害扱いとし、証明書を失効させて入れ替えた

そして、この一文が今回の答えです。

2026年5月8日に証明書を完全に失効させると、旧証明書で署名されたアプリの新規ダウンロードと起動は、macOSのセキュリティ保護によってブロックされます。

新しい証明書で署名された最初のバージョンも公表されています。

アプリ新証明書で署名された最初のバージョン
ChatGPT Desktop1.2026.051
Codex App26.406.40811
Codex CLI0.119.0
Atlas1.2026.84.2

つまり、Codex CLI 0.119.0より前のものを入れっぱなしにしていると、5月8日以降ブロックされます。 Codexにマルウェアが入っていたわけではなく、OpenAIが意図的に失効させた旧証明書を、macOSがブロックした結果です。これが「マルウェア判定」の正体でした。

公式も、悪意あるソフトウェアがOpenAIの証明書を悪用した証拠はなく、公開済みのソフトウェアに不正な改変も確認していない、と明記しています。ユーザーデータの侵害証拠もなく、パスワードとAPIキーにも影響はありません。慌てる話ではありません。

最初にやるのは、どのcodexが動いているかの特定

ここで手が滑りやすいところです。「マルウェア判定を解除する方法」を検索したくなる。私も一瞬そう考えました。

でも、その前にやることがあります。いま自分のMacで実行されているcodexが、どこの何なのかを確かめること。

type -a codex
which codex
ls -l "$(which codex)"

私の環境ではこう出ました。

codex is /Users/ユーザー名/.nvm/versions/node/v24.14.0/bin/codex

/Users/ユーザー名/.nvm/versions/node/v24.14.0/bin/codex

lrwxr-xr-x ... /Users/ユーザー名/.nvm/versions/node/v24.14.0/bin/codex
-> ../lib/node_modules/@openai/codex/bin/codex.js

これで正体が分かりました。NVMで管理しているNode.js配下に、npmでグローバルインストールしたCodex CLIです。

大事なのは、Claude Codeが変なコマンドを呼んでいたわけではないと分かったことです。PATH上のcodexを普通に呼んでいて、その先が古いnpm版だった。それだけの話でした。

もう1つ分かったことがあります。npmで入れたCodex CLIは、公式のスタンドアロン版とは別のインストール経路だということです。

これが今回の落とし穴でした。スタンドアロン版の更新コマンドを実行しても、PATH上で古いnpm版が先に見つかれば、そちらが呼ばれ続けます。 npm版はnpm側で更新する必要があります。今回ブロックされたのは、まさにその置き去りになった版でした。

警告を消しにいかず、公式版へ入れ替える

対処には2つの道がありました。

A. 警告を強制的に解除して使い続ける。 xattr -d com.apple.quarantine などで属性を落とす方法です。

B. 古いものを削除して、公式のスタンドアロン版に入れ替える。

Bを選びました。理由は好みではなく、Aが今回の文脈では危ないからです。

同じOpenAIの発表に、こう書かれています。旧証明書で署名された偽アプリはmacOSがブロックするが、利用者が明示的にバイパスすれば通ってしまう、と。

証明書を失効させた目的は、悪意ある第三者が「OpenAI製に見える偽物」を配れないようにすることでした。警告を手で外すという行為は、その本物と偽物を見分ける最後の仕組みを、自分で無効にすることにあたります。今回はたまたま本物でした。次も本物とは限りません。

手順はこうです。まずnpm版を削除します。

npm uninstall -g @openai/codex
hash -r

hash -r はシェルが覚えているコマンドの場所をリセットするためのものです。これを忘れると、消したはずのパスを見に行き続けます。

ここで気になるのが、ChatGPTアプリのCodexに影響しないかという点。しません。消えるのはMacにnpmで入れたCLIだけで、ChatGPTアプリもアカウントも契約も別物です。

続いて公式のスタンドアロン版を入れます。

curl -fsSL https://chatgpt.com/codex/install.sh | sh

実際のログはこうなりました。

==> Installing Codex CLI
==> Detected platform: macOS (Apple Silicon)
==> Resolved version: 0.147.0
==> Downloading Codex CLI
==> Installing standalone package to /Users/ユーザー名/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin
==> Current terminal: export PATH="/Users/ユーザー名/.local/bin:$PATH" && codex
==> Future terminals: open a new terminal and run: codex
==> PATH was added to /Users/ユーザー名/.zprofile
Codex CLI 0.147.0 installed successfully.

この 0.147.0 は、執筆時点でインストーラーが取ってきたバージョンです。 実行する時期によって数字は変わりますし、以降に出てくる 0.147.0 も同じで、数字そのものを合わせる必要はありません。

確認したいのは次の2つです。0.119.0より前の旧証明書版ではないこと。 そして which codex が、今回公式インストーラーで入れたCodexを指していること。 できれば、その時点の公式最新版になっていることも確認してください。

「stdin is not a terminal」は失敗ではない

インストーラーの最後に Start Codex now? [y/N] と聞かれて y と答えたら、こうなりました。

==> Launching Codex
Error: stdin is not a terminal

一瞬、失敗したのかと思います。失敗していません。

curl ... | sh はパイプ経由でインストーラーを動かしています。そこからさらに対話型のCodex CLIを起動しようとすると、Codexから見た標準入力が普通のターミナルではないため、この形で止まります。インストール自体は上のログのとおり installed successfully で完了しています。入れ直す必要はありません。

確認します。

export PATH="$HOME/.local/bin:$PATH"
which codex
codex --version

/Users/ユーザー名/.local/bin/codex
codex-cli 0.147.0

パスが変わりました。 以前は ~/.nvm/versions/node/v24.14.0/bin/codex だったものが、~/.local/bin/codex になっています。切り替え成功です。

この状態で codex を実行すると、今度は普通に立ち上がりました。あの警告は出ません。終了は Ctrl + C です。

Claude Codeから呼べる状態にする

本来の目的はここでした。ターミナルでCodexを使うことではなく、Claude CodeからCodex CLIを呼び出すことです。

1つ注意があります。Claude Code Desktopを一度完全に終了して、起動し直してください。 デスクトップアプリは起動時のPATHを保持していることがあるので、入れ替え直後だと古い場所を見に行きます。

再起動したらClaude Codeに codex --version を実行させて、codex-cli のバージョンが返れば通っています(私の環境では codex-cli 0.147.0 でした)。

呼び出し方はシンプルです。

codex exec "このコードをレビューして"

Codexの回答は、Claude Codeがシェルコマンドの実行結果として受け取ります。 Claude Codeの中にCodexの画面が開くわけではありません。標準出力が返ってきて、Claudeがそれを読んで解釈し、同じセッションの中で答えてくれる。使う側はClaude Codeの1画面だけ見ていれば済みます。

レビューを頼むだけではありません。Claudeが書いた実装指示書をそのまま渡すこともできます。

cat implementation.md | codex exec -

ここで1つ注意です。codex exec は既定ではread-onlyのサンドボックスで動きます。 実際にファイルを編集させたいなら、--sandbox workspace-write のように権限を指定する必要があります。指示書を渡したのに何も変わらない、というときはたいていこれです。自動化では必要最小限の権限にとどめるよう、公式も案内しています。

こうすると、こんな流れが組めます。

  1. Claude Codeがコードベースを読んで、実装方針を設計する
  2. 詳細な指示書を書き出す
  3. その指示書をCodexに渡して実装させる
  4. Claude Codeが差分を確認してレビューする
  5. 直しが必要ならCodexに投げ返す

司令塔がClaude、手を動かす別働隊がCodex、という構成です。私たちはこの形で、ブログのヒーロー画像の生成もCodexに任せています。

セッションの残り方も触れておきます。Codex CLIのセッションは ~/.codex/ 配下でローカルに管理されます。単発のレビューを大量に投げると履歴が溜まるので、残したくないときは codex exec --ephemeral という選択肢があります。重要な作業は通常セッション、Claude Code内部の使い捨てレビューはephemeral、という使い分けが現実的でした。

まとめ 警告が出たら、まず何が動いているかを見る

今回の要点です。

  • Macで codex を実行すると出る「コンピュータが破損します」「マルウェアが含まれている」は、「開発元を確認できません」とは別のレイヤーの警告。「このまま開く」は出ない
  • 原因はOpenAIによる証明書の失効。2026年3月のAxios侵害を受けて証明書を入れ替え、5月8日に旧証明書を完全失効させた
  • Codex CLIは0.119.0以降が新証明書。それより前を入れっぱなしだとブロックされる
  • npm経由で入れたCLIは公式のアップデート導線に乗らないので、古いまま取り残されやすい
  • 対処は警告の強制解除ではなく、npm版を削除して公式スタンドアロン版へ入れ替える
  • stdin is not a terminal はインストール失敗ではない

最後に、エンジニアでない方にも効く話をひとつ。

セキュリティ警告が出たとき、消し方を検索するのは筋が悪い。 今回の件は、その理由がはっきり見える例でした。あの警告は、OpenAIが「偽物が出回るかもしれないから」と自ら仕込んだ仕組みが正しく働いた結果です。手で外していたら、本物と偽物を区別する手段を自分から捨てることになっていました。

やるべきだったのは、いま何が動いているのかを確かめることでした。which codex の1行です。それさえ分かれば、あとは古いものを消して新しいものを入れるだけの話でした。

社内で「AIツールが動かない」と相談されたときも、順番は同じです。回避策を探す前に、何がどこから入ったものなのかを聞く。 シャドーAIの記事にも通じますが、把握していないものは直しようがありません。

関連性の高い記事

御社のAI導入や活用、私たちが一緒に考えます

記事の内容へのご質問も歓迎です。構想段階のご相談からどうぞ。

相談する