2026年8月11日、OpenAIの開発者フォーラムに Codex in ChatGPT desktop app for Linux is now in preview という投稿が出ました。ChatGPTのデスクトップアプリがLinuxでも動くようになった、という話です。macOSとWindowsには前からあったので、残っていた最後の1つがようやく埋まった形になります。
告知のタイトルは「Codex in ChatGPT desktop app for Linux is now in preview」です。OpenAIが頭に置いたのはCodexでした。このアプリは手元のフォルダを開いて、その中でCodexにコードを書かせたりコマンドを走らせたりできます。Linuxを開発機にしている人からすれば、自分のマシンでエージェントを動かすGUIが1つ増えました。
ただしプレビューです。公開の翌日までに、日本語入力が通らない、Wayland環境なのにX11で動いてしまう、CLIで作ったプロジェクトが一覧に出てこない、といった報告が同じスレッドへ投稿されました。自分なら、この20件ほどのやりとりを読んでから入れます。
この記事では、何が公開されたのか、インストールで何が起きるのか、Codexに手元のファイルを触らせるときの権限はどうなっているのか、そして今の時点で踏みやすい落とし穴を順に見ていきます。
Table of contents
Open Table of contents
発表の中身
OpenAIは告知で、対応環境をそっけないくらい簡潔に並べています。
| 項目 | 内容 |
|---|---|
| 対応ディストリビューション | Ubuntu 24.04 LTS と 26.04 LTS、Debian 13、Fedora 43 と 44 |
| アーキテクチャ | x64 と ARM64 |
| パッケージ形式 | .deb と .rpm |
| 段階 | プレビュー |
出典：Codex in ChatGPT desktop app for Linux is now in preview（2026年8月11日投稿、2026年8月12日参照）
OpenAIは対象をデスクトップ版に限り、しかもLTSと最近のFedoraだけを挙げました。検証の範囲をかなり絞ったのだと思います。ここに載っていない環境が動かないと決まったわけではありませんが、動かなくても文句は言えません。
ディストリビューションと配布形式、アーキテクチャの対応を1枚にすると次のようになります。
OpenAIは告知の本文で、このアプリをプロジェクトを管理し、ファイルを扱い、ブラウザを使った作業を回し、ChatGPTと並べてCodexを走らせるための作業場だと説明しています。ブラウザのタブで開くChatGPTとの違いは、ファイルを扱う点とCodexを走らせる点の2つです。
告知にはもう1つ、ChatGPT、ChatGPT Work、Codex の3つを1つのアプリにまとめた、と書かれています。ChatGPT Work は仕事用の面ですが、ここではLinux対応を追うので深入りしません。
デスクトップアプリとCodexの関係
先に用語を整理します。
Codex は、OpenAIのコーディング用エージェントです。エージェントというのは、こちらが指示を出すと、自分でファイルを読み、必要なら書き換え、コマンドを実行して結果を確かめる、という一連の作業を回してくれるプログラムのことです。チャットで答えを返すだけの使い方と違い、実際に手を動かす部分まで任せられます。
Codexには入口がいくつもあります。ターミナルで使う Codex CLI、エディタに入れる IDE拡張、クラウド側で動かす Codex cloud、そして今回Linuxに来た デスクトップアプリ です。OpenAIは公式ドキュメントで、デスクトップアプリはプロジェクトの管理に、IDE拡張はエディタの中での作業に、Codex cloudは並列実行に向いていると整理しています（Codex CLI）。
同じCodexでも入口によって触れるものが変わります。CLIとIDE拡張とデスクトップアプリは手元のリポジトリを直接触り、Codex cloudはクラウド側の環境で動きます。今回Linuxで使えるようになったのは、図のデスクトップアプリの箱です。CLIはもともとLinuxで動いていたので、Linuxユーザーにとって新しいのはGUIの側だけです。
アプリの中では左上のメニューで Chat と Work と Codex を切り替えます。Codexに切り替えると、ローカルのプロジェクトを開き、エディタでファイルを見て、テストを走らせ、変更をレビューする、という流れが1つの窓の中で完結します（OpenAI Launches Official ChatGPT Desktop App for Linux in Preview、2026年8月11日公開、2026年8月12日参照）。
プロジェクトという単位
デスクトップアプリの中心にあるのが プロジェクト です。関連するチャットとファイルと参照元をひとまとめにしておく入れ物、と考えると分かりやすいです。
公式ドキュメントによると、プロジェクトには2種類あります。ファイルをアップロードして使うChatGPTのプロジェクトと、パソコン上のフォルダに接続して読み書きするローカルプロジェクトです。後者がCodexで使うほうで、アプリのProjectsビューでは両方が同じ場所に並びます（Projects）。
OpenAIは、成果物ごとに新しいチャットを始めて、関連する作業をプロジェクト側でまとめる使い方を想定しています。チャットは使い捨てにして、積み上げたいものだけプロジェクトへ置く、と読み替えると分かりやすいです。
2種類のプロジェクトの違いを並べると、Codexで使うのがどちらなのかがはっきりします。
インストール
ダウンロードは openai.com/codex から行います。.deb と .rpm が用意されていて、x64とARM64の両方があります。
落としたパッケージは、パッケージマネージャに直接渡すのが手軽です。
# Debian 13 / Ubuntu 24.04 と 26.04
sudo apt install ./chatgpt_amd64.deb
# Fedora 43 / 44
sudo dnf install ./<ダウンロードしたrpmファイル>.deb を入れると、OpenAIのリポジトリがシステムに追加され、以降の更新は他のソフトウェアと一緒に降ってくるようになります（ChatGPT desktop app is now available for Linux (in preview)、2026年8月11日公開、2026年8月12日参照）。手動で入れ直す手間がない代わりに、自分の環境へ外部のaptリポジトリが1つ増えることになります。組織の端末で運用ルールがあるなら、ここは事前に確認しておく場所です。
サイズはそれなりにあります。この記事を書くにあたって amd64 の .deb をHTTPヘッダで確認したところ、約350MBありました。回線が細いところでは、それなりに待ちます。
ダウンロードから更新までの流れをまとめると、次の4段階になります。
ダウンロードボタンが見つからないとき
スレッドで最初に文句が出たのは、ダウンロードの導線でした。サイトが閲覧中のOSを見てボタンを出し分けるので、Windows機からLinux版を落として仮想マシンへ持ち込めない、と投稿した人がいます。場所によってはWindowsとmacOSのボタンが並ぶのに、別の場所ではそうならない一貫性のなさも、同じ人が批判していました。
これに対して、同じスレッドで .deb の直リンクが共有されています。
https://persistent.oaistatic.com/codex-app-prod/linux/deb/latest/chatgpt_amd64.debこのURLは実際に配布物へ到達します。ただしフォーラムの投稿で共有されたものであって、OpenAIが安定した入口として案内しているアドレスではありません。通常はダウンロードページから取得して、この直リンクは他のOSから持ち込むときの逃げ道として覚えておくくらいが妥当です。
ついでに、WSLのUbuntu 24.04でWSLg経由でも動いた、という報告も出ていました。サポート対象ではないので、動いたらもうけものです。
ブラウザ版やCLIとの使い分け
Linuxで作業する人には、すでにブラウザ版のChatGPTとCodex CLIがあります。そこへGUIのアプリが加わったので、使い分けを考えることになります。
| ブラウザ版ChatGPT | Codex CLI | デスクトップアプリ | |
|---|---|---|---|
| 手元のファイル | アップロードが必要 | 直接読み書き | 直接読み書き |
| コマンド実行 | できない | できる | できる |
| 操作方法 | チャット | ターミナル | GUI |
| 向いている場面 | 調べもの、文章 | 慣れた手順の反復、スクリプト化 | 複数プロジェクトの管理、変更のレビュー |
ターミナルの中で完結する作業を、CLIから引き剥がしてまでGUIへ移す理由はありません。デスクトップアプリが役に立つのは、プロジェクトが複数あって行き来する場合と、Codexが出してきた変更を目で追いながら判断したい場合です。
逆に、ブラウザ版で足りていた用途をアプリへ移すのは分かりやすい利点があります。手元のファイルをどこかへアップロードしなくてよくなるからです。ChatGPTのウィンドウにドラッグして渡していたファイルを、そのまま置いた場所で読ませられます。
判断の順番にすると、2つの問いで大まかに振り分けられます。
手元のファイルを触らせるときの権限
エージェントに手元のフォルダを渡すのは、要するに自分のマシンでコマンドを走らせる権限を渡すことです。ここは仕組みを知らないまま使い始めない方がいい場所なので、公式ドキュメントの記述を確認しておきます。
Codexの権限は、性質の違う2つのつまみで決まります。権限プロファイル がどこまで触れるかを決め、承認ポリシー が操作を実行する前にいつ利用者へ聞くかを決めます。片方だけ見ても、実際に何が起きるかは分かりません。
まず権限プロファイルです。組み込みのものが3つあります（Permissions）。
| プロファイル | 挙動 |
|---|---|
read-only | ローカルのコマンド実行を読み取りだけに保つ |
workspace | 作業中のワークスペースとシステムの一時領域への書き込みを許可する |
danger-full-access | ローカルのサンドボックスによる制限を外す |
もう一方の承認ポリシーは、untrusted と on-request と never の3つです。untrusted は、状態を変える操作や外部の実行につながる操作のたびに聞きます。プロファイルが許した範囲の中でも聞いてくるので、範囲の話とは別の軸だと分かります。on-request は範囲の外へ出るときに聞き、never は聞きません。never にしても触れる範囲が広がるわけではありません。範囲の外の操作は、承認を求められないまま失敗します（Agent approvals & security）。
設定ファイルで指定するときは、新しい default_permissions と [permissions] か、古い sandbox_mode と sandbox_workspace_write のどちらか一方に寄せてください。OpenAIはこの2つを混ぜて使えないと明記しています（Permissions）。
2つを組み合わせたプリセットが Auto です。--sandbox workspace-write --ask-for-approval on-request と同じ意味になります。ワークスペースの中なら読み取りも編集もコマンド実行もそのまま進み、外を編集するときとネットワークへ出るときに承認を求めます。
ただし、Auto がいつでも既定になるわけではありません。Codexは起動時にフォルダがバージョン管理されているかを見て、Gitなどで管理されているフォルダには Auto を、管理されていないフォルダには read-only を勧めます。あくまで推奨で、作業ディレクトリを明示的に信頼するまで read-only で始まる設定もあります（Agent approvals & security）。同じアプリでも、渡すフォルダによって初手が変わります。
ファイルシステムの許可は read と write と deny の3段階で、より細かいルールが優先され、deny が最も強く効きます。ワークスペース全体を書き込み可能にしたうえで .env だけを deny にする、といった書き方ができます。
workspace で書き込みを許していても、.git は読み取り専用として保護されます。ディレクトリとして存在する場合もファイルとして存在する場合も同じ扱いで、.agents と .codex にも同じ保護がかかります。そのため git commit のようなコマンドは、ワークスペースの中の操作であっても承認を求めてくることがあります。うるさく感じるかもしれませんが、履歴を勝手に書き換えられないための線引きです。
ネットワークは有効にしてからドメイン単位で制御する形です。既定ではローカルアドレスとプライベートネットワークに対するガードがかかっていて、DNSリバインディングのような手口で内部のアドレスへ回り込まれるのを防いでいます。
書き込める範囲と保護される場所を、入れ子にして描くと次のようになります。
強制の仕組みはOSごとに違っていて、macOSはSeatbelt、LinuxとWSLは bubblewrap と seccomp、Windowsは専用のサンドボックス機能を使います。Linuxでは、書き込みを止めているのはカーネルの機能です。アプリの行儀のよさに任せているわけではありません。
サンドボックスを完全に外す danger-full-access を、OpenAIははっきり非推奨としています。--dangerously-bypass-approvals-and-sandbox（別名 --yolo）にも「サンドボックスなし、承認なし、推奨しない」と添えてあります。使い捨ての仮想マシンの中など、環境そのものが隔離されている場合以外は触らない、と決めておくのが安全です。
プレビュー段階で出ている不具合
公開の翌日までに、スレッドには具体的な報告がいくつも上がりました。プレビューという言葉がどのくらいの意味かを測るには、ここが一番参考になります。
| 報告内容 | 環境 |
|---|---|
| 日本語のFcitx5で入力欄が日本語に切り替わらない | Fedora 44、KDE Plasma、Wayland |
| 韓国語のFcitx5でも同じ症状 | EndeavourOS、KDE、Wayland |
| Waylandセッションなのに X11 で動き、4Kディスプレイで表示が崩れる | Fedora 44、GNOME |
| Codex CLIで作ったプロジェクトがアプリのプロジェクト一覧に出てこない | 記載なし |
wtype による仮想キーボード入力が数字と記号として誤って解釈される | Hyprland、Wayland |
| Arch LinuxやNixOSのようにdebでもrpmでもない環境は対象外 | 記載なし |
出典：Codex in ChatGPT desktop app for Linux is now in preview（2026年8月12日時点のスレッド、2026年8月12日参照）
並べてみると、報告の多くが日本語入力とWaylandまわりに集まっています。GNOMEでX11にフォールバックしていた人は、再起動したら直ったと後から書き込んでいるので、環境によって出たり出なかったりする類のようです。
CLIで作ったプロジェクトが一覧に出てこないという報告は、毛色が違います。作業ディレクトリもgitのブランチも保持されているのに、CLIのセッションが全部ただのチャットとして並び、フォルダを手動で追加してプロジェクトを作っても中身が空のままだ、と報告者は書いています。CLIとGUIを行き来する使い方を考えていたなら、ここは今の時点であてにしないほうがいいです。
パッケージ形式についても、いつもの議論が起きました。debとrpmだけではArch LinuxやNixOSの利用者が置き去りになるので、Flatpakにしてほしい、と要望した人がいます。Arch向けにはAURのコミュニティパッケージがあるという情報もありますが、非公式です。
メモリ使用量を尋ねた投稿もありましたが、2026年8月12日時点では回答が付いていません。中身がChromium系であることは、後述する起動オプションが効くことからほぼ確実なので、それなりに食べると見ておくのが現実的です。
報告をグループに分けると、どこに集中しているかが見えます。
日本語入力が通らないときの対処
日本語で使う人に直接効いてくるのが、Fcitx5の件です。スレッドの報告が具体的なので、内容を追っておきます。
報告者の環境は Fedora 44、KDE Plasma、Wayland、Fcitx 5 で、公式のx64版RPMを入れたところ、KDEのアプリケーションメニューから普通に起動するとメッセージ入力欄で日本語に切り替えられなかったそうです。同じ環境でもKWriteのようなKDE標準のアプリなら日本語入力が効くので、報告者はアプリ側の問題だと切り分けています。
回避策として報告されたのが、Wayland向けの起動オプションを明示的に付けることでした。
chatgpt \
--enable-features=UseOzonePlatform \
--ozone-platform=wayland \
--enable-wayland-imeこの3つを付けて起動すると、入力欄で日本語が使えるようになったとのことです。ここに出てくる --ozone-platform はChromiumの起動オプションなので、アプリの中身がChromiumやElectronの系統だと推測できます。報告者自身も、同じ環境でObsidianに同種のIME問題があったと書いていて、そちらではXWaylandへ逃がす必要があったのに対し、こちらはWaylandのままで解決したという違いを挙げています。
毎回ターミナルから打つのは面倒なので、報告者はデスクトップエントリを複製して対応しています。
# desktopエントリをユーザー領域へ複製し、Exec行へオプションを足す
# Exec=chatgpt --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime %U
kbuildsycoca6複製先は ~/.local/share/applications/ で、Exec= の行に上記のオプションを書き足したうえで kbuildsycoca6 を実行すると、メニューから普通に起動しても日本語が使えるようになったそうです。kbuildsycoca6 はKDEがアプリケーションの一覧をキャッシュから作り直すためのコマンドで、.desktop ファイルを変更したあとに走らせます。
この回避策には注意点があります。別の参加者が、ランチャの設定を変えただけで本当にWaylandで動いているのかと疑問を投げ、自分の環境ではX11のまま動いていたと書きました。報告者はこれに、ランチャの設定ではなく実際のプロセスを見るべきだと答えて、次のような確認方法を挙げています。
ps -ef | grep -i '[c]hatgpt'出力の中に --ozone-platform=wayland が付いているかどうかを、メインプロセスとレンダラプロセスについて確かめます。オプションを書いたつもりで渡っていない、という状態を潰すための手順です。
ここまでの作業を段階に分けると、次の3つになります。
韓国語のFcitx5でも --enable-wayland-ime で直ったという報告が続いているので、日本語に限った話ではなく、Fcitx5を使う環境全般で起きる症状のようです。いずれもフォーラムの利用者による報告と回避策であって、OpenAIが公式に案内しているものではない点は押さえておいてください。
入れる前に決めておきたいこと
最後に、試す前に確認しておくと後で困りにくい点を挙げます。
対象環境から。Ubuntu 24.04 LTS か 26.04 LTS、Debian 13、Fedora 43 か 44 のデスクトップ版なら素直に試せます。それ以外は動く可能性はあっても、不具合が出たときに自分で切り分けることになります。
.deb を入れるとaptリポジトリが1つ増えます。管理された端末なら、ここは事前確認が要る変更です。
いちばん大事なのは権限です。Git管理下のフォルダには Auto、管理外のフォルダには read-only が勧められます。Git管理下でも、明示的に信頼するまでは read-only で始まることがあります。渡したフォルダによって初手が違うので、まず今どの権限で動いているかを確かめてください。そのうえで、しばらくは勧められたまま使い、承認を求められた内容を毎回読んでください。慣れる前に danger-full-access や never へ寄せると、何が起きたのか分からなくなります。ここだけは横着しないほうがいいです。
日本語で使うなら、Fcitx5で入力が切り替わらないときの逃げ道として、起動オプションの件を頭に入れておいてください。報告はKDEとWaylandの組み合わせに集中していますが、GNOMEでも表示まわりの報告が出ています。
CLIとの併用を考えているなら、プロジェクト一覧が共有されない件が刺さります。直るまでは、CLIとアプリを別々の道具として使うほうが混乱しません。
自分の結論を書いておきます。対象のディストリビューションを使っている開発機なら、入れて触ってみて構いません。ただし、いま回っているCLIの手順をこのアプリへ寄せるのは、プロジェクト一覧の件が直ってからで十分です。
以上を確認リストの形にまとめておきます。
要点
- 2026年8月11日、ChatGPTデスクトップアプリのLinux版がプレビューとして公開された。対応はUbuntu 24.04 LTSと26.04 LTS、Debian 13、Fedora 43と44で、x64とARM64向けに
.debと.rpmが配布されている - ブラウザ版との違いは、手元のファイルをアップロードせずに扱えることと、ローカルのリポジトリでCodexを動かせること。Linuxユーザーにとって新しいのはGUIの側で、Codex CLIはもともと動いていた
- Codexの権限は、触れる範囲を決める権限プロファイルと、いつ聞くかを決める承認ポリシーの2本立て。初期値は渡すフォルダ次第で、Git管理下ならAuto、管理外なら
read-onlyが勧められる（Git管理下でも、信頼するまでread-onlyで始まることがある） - Linuxでのサンドボックスはbubblewrapとseccompで強制される。
.gitと.agentsと.codexは書き込み可能な設定でも読み取り専用に保護され、制限を外すdanger-full-accessと--yoloをOpenAIは非推奨としている - プレビュー段階の報告として、Fcitx5で日本語入力が切り替わらない、WaylandなのにX11で動く、CLIで作ったプロジェクトがアプリに出てこない、といった内容がフォーラムに並んでいる
参考資料
- Codex in ChatGPT desktop app for Linux is now in preview（OpenAI Developer Community、2026年8月11日投稿、2026年8月12日参照）
- ChatGPT desktop app（ChatGPT Learn、2026年8月12日参照）
- Projects（ChatGPT Learn、2026年8月12日参照）
- Permissions（ChatGPT Learn、2026年8月12日参照）
- Agent approvals & security（ChatGPT Learn、2026年8月12日参照）
- Sandbox（ChatGPT Learn、2026年8月12日参照）
- Config basics（ChatGPT Learn、2026年8月12日参照）
- Codex CLI（ChatGPT Learn、2026年8月12日参照）
- ChatGPT desktop app is now available for Linux (in preview)（OMG! Ubuntu、2026年8月11日公開、2026年8月12日参照）
- OpenAI Launches Official ChatGPT Desktop App for Linux in Preview（Linuxiac、2026年8月11日公開、2026年8月12日参照）
- OpenAI Brings ChatGPT Desktop App To Linux（Phoronix、2026年8月11日公開、2026年8月12日参照）