Codexのローカル開発環境を選ぶ｜Windows・WSL・CLI・Remoteの違い

スマホは操作面、実行は接続先host

接続前の最小チェック

• desktop appとmobile appを最新にし、同じaccount / workspaceでサインインする。hostはスリープせず、作業中にオンラインを保つ。
• desktop appのSettings > Connections > Control this Mac or PCからSet up / Addを開き、表示された承認とQR pairingを確認する。
• 接続先のrepo、subdirectory、Git branch、触ってよいファイルを固定し、スマホからのfollow-upやapprovalを無制限の実行許可と扱わない。
• hostが持つcredentials、MCP、browser session、Computer Use、sandbox、local toolsの権限がremote taskにも影響する前提で、最小権限と秘密情報の非表示を確認する。
• SSHを使う場合は~/.ssh/configのhost alias、trusted key、remote login shell、Codex remote hostの導入を確認し、app-server transportを共有・公開ネットワークへ直接晒さない。

Remoteとローカル・cloudの境界

Remoteは、接続した自分のMac / WindowsまたはSSH先の環境を操作する実行面です。hostのcredentials、permissions、MCP、browser、sandboxを引き継ぐため、スマホから見えている会話だけで安全範囲を判断しません。Cloud environmentのcontainerで動くtaskや、Web taskのuploaded contextとは別に、どのhost・filesystem・Git stateが実際の対象かを毎回確認します。

ローカルのchatをremote hostへhandoffすると、既存chatとGit stateを接続先へ移せます。公式Docsでは、保存済みの同じrepo / subdirectoryが必要で、worktreeを作成または再利用する場合があります。handoff中の応答は中断され、Codex cloud environmentへhandoffする機能ではないため、移動後にbranch、worktree、未コミット差分を確認します。

現行のpairing・host設定・再接続

• hostがsleep、offline、app終了になるとRemoteは停止する。長時間使う専用hostなら、電源・network・awake設定を先に確認する。
• ChatGPTからsign outするとRemote Controlはoffになるが、既存のdevice pairing自体は削除されない。再sign in後にRemote Controlを再度有効化する。
• Remoteが一覧に出ない、approvalが届かない、Add後にerrorになる場合は、同じaccount / workspace、desktop appの稼働、adminのRemote Control設定、QR pairingを確認し、必要ならhostのdesktop appを再起動する。

SSH接続はalias・login shell・remote projectを分けて確認する

SSH hostを使う場合、公式Docsは~/.ssh/configの具体的なhost aliasをCodexがauto-discoverし、pattern-onlyのHostは無視すると説明しています。まずappを動かす端末からSSH接続を確認し、remote userのlogin shellでcodex commandがPATHにあることを確認します。desktop appはSSH経由でremote Codex app serverを起動するため、Settings > ConnectionsでSSH hostを追加・有効化してからremote project folderを選びます。

remote project chatではremote filesystemを読み書きし、remote hostでcommandを実行します。trusted key、least-privilege account、同じsecurity policyを保ち、app-server transportをshared / public networkへ直接公開しません。現在のnetwork外へ接続する必要がある場合は、公式Docsの境界どおりVPNやmesh networkingを使い、公開listenerを作らない前提で設計します。

`.codex`の設定、worktree setup、Actionを分けて確認する

Local environmentを使う前の停止条件

• Local environmentはChatGPT desktop appのCodexで使う機能として扱い、CLIやIDE extensionにも同じSettings UIがあると決めつけない。
• setup scriptはworktree作成時に自動実行される可能性があるため、`npm install`、build、postinstall、外部取得、license、secret参照、生成ファイルを実行前にレビューする。
• `.codex`をGitで共有する場合は、設定が想定するproject root、platform別command、runtime、port、環境変数を確認し、API keyやtokenの実値を置かない。
• Actionはintegrated terminalの便利な入口であり、sandbox、filesystem、network、MCP、browser、hostのpermissionを狭める承認機構ではない。
• desktop appのGit controlsを使っても、現在のcheckout、worktree、branch、未追跡ファイル、生成物、test結果、push先を確認してから公開操作へ進む。

Local environmentは、ローカルのChatGPT desktop appとそのproject / worktreeを準備する設定です。Remoteは接続済みhostへ到達する実行面、Cloud environmentはcontainerを使う別の実行面なので、同じsetup scriptやGit stateが自動的に共有されるとは扱いません。どのcheckoutでscriptが動き、どのterminalとpermissionでActionが実行されるかを毎回確認します。

Windowsの導入はinstall・sign in・最初のtaskを分ける

Codex CLIは一つのterminal loopから用途を分ける

公式ページは、CLIをlocal repositoryのinspect・edit・run、repeatable workflowの`codex exec`、変更をcommit前に見るreview、Codex cloudへのhandoffに使う面として整理しています。`codex resume`、画像・web context、subagents、`codex mcp`、`/permissions`、`codex completion`も同じCLIにありますが、local filesystem、cloud environment、MCP server、外部送信の権限が一つに統合されるとは扱いません。

• まずlocal repoで読み取り・小さな変更・diff確認を行い、installや外部通信の副作用を先に把握する。
• `codex exec`をCIやrepeatable workflowへ広げる時は、interactive sessionと出力・approval・sandbox・secretの境界を別に確認する。
• `codex cloud`からlocal repositoryへ結果を戻す時は、cloud taskのdiffを通常の未commit変更としてreviewし、apply成功をcommitやdeploy成功と混同しない。
• `codex mcp`、Plugins、Skills、`/permissions`を追加する時は、接続先、tool、scope、session、sandbox、approvalを一つずつ確認する。

CLIの見た目と入力経路を用途別に設定する

completionとeditorを権限設定と混同しない

• `codex completion`はShellで`codex`の入力を補助するscriptを生成する機能で、filesystem、network、MCP、approvalを許可するcommandではない。
• Shell設定へ追加する前に、生成されたscript、profileの変更箇所、対象Shell、削除方法を保存しておく。公式ページの例はZ shell向けなので、PowerShellでは現在のShellと公式の出力を確認してから反映する。
• `/theme`と`$CODEX_HOME/themes`はCLIの表示設定、`VISUAL` / `EDITOR`はprompt編集の入口であり、projectのAGENTS.mdや`config.toml`のpermission設定を置き換えない。
• 見た目や入力を整えた後も、実行前にはCLI referenceのsandbox、approval、`--cd`、`--config`、Git差分を別に確認する。

Windowsでは環境変数の用途と寿命を先に分ける

秘密情報を環境変数に置いても、漏えい境界は消えない

• `CODEX_API_KEY`、`CODEX_ACCESS_TOKEN`、providerの`env_key`で参照する値は、記事・README・AGENTS.md・config.toml・Git管理下の`.env`へ実値を書かない。環境変数名だけを共有し、値はsecret managerやOSの管理領域で扱う。
• `CODEX_API_KEY`は`codex exec`の1回のnon-interactive実行向けなので、job全体や後続commandへ無制限に継承させない。`CODEX_ACCESS_TOKEN`をtrusted automationで使う場合も、対象repoとprocessを限定する。
• provider側の認証変数名は、設定した`env_key`で決まり、Codexに固定されたprovider API key名とは限らない。設定ファイルのprovider、base URL、wire API、env_keyを値なしでreviewする。
• `CODEX_HOME`と`CODEX_SQLITE_HOME`は単なる一時変数ではなく、認証・履歴・session・SQLite stateの保存先に影響する。別directoryを指定する場合は、意図したprofileと既存stateを確認する。
• インストーラーのnon-interactive設定はpromptを隠すだけで、scriptの安全性を保証しない。install / updateのsource、対象path、PATH変更、post-install処理、外部通信を先に確認する。

環境変数は、config.tomlに置くべきdurable setting、現在のshellだけのoverride、installerの動作制御、認証、TLS、診断を一つの場所にまとめる仕組みではありません。PowerShellで確認する時も、値そのものを表示せず、変数名、設定元、継承先process、保存先、終了後に残るstateだけを監査します。

IDE extensionのeditor contextと変更レビューを分ける

WindowsでIDEからCodexを再開する確認順

• IDEを開く前に対象repoのabsolute path、Git root、workspaceまたはmulti-rootのroot、remote、branch、`git status`、未commit diff、AGENTS.md、`.codex`、configを確認する。
• composerへ追加するopen file・selection・recent chatをtaskのcontextとして明示し、見えていないsourceや別folderが自動で適用されるとは扱わない。耐久的な指示はAGENTS.mdやchecked-in docsに残す。
• VS Code / Cursor / WindsurfのCodex iconまたはCommand Paletteを使い、Xcode / JetBrainsでは公式integrationの入口を使う。extension未導入、未sign-in、workspace未open、command非表示を混同しない。
• 作業がlocalかCodex webへのdelegateかを選び、host、cwd、sandbox、approval、network、MCP、secret、Git targetを別々に確認する。長い作業のhandoffは権限や完了を広げない。
• IDEのsummaryとfocused diffを読んだ後、実ファイル、Git diff、test・lint・build、生成物、upload parityを確認し、前後のcheckpointと未実行範囲を記録する。

WSL2・native Windows・IDE・CLIの実行面を分ける

WSLを使うWindows作業の再開確認順

• native WindowsかWSL2かを最初に選び、Codex version、WSL version、distro、実際のhost、sandbox mode、network、approval、MCPを記録する。WSL1は現行Codexの選択肢にしない。
• WSLで作業するならrepoのabsolute pathを`/home/...`などLinux側で確認し、`/mnt/c/...`のI/O、symlink、permission、line endingの影響を別に評価する。Windows側の同名repoを現在対象と推測しない。
• VS CodeではWSL extensionと`WSL: <distro>` status、Linux pathのterminal、workspace rootを確認する。Codex iconやIDE extensionが見えても、Windows native windowとWSL windowの実行面を混ぜない。
• WSL shellの`PATH`、`which codex`、node・gitの実体、config、credential、MCP、secretの参照先を確認する。Windows側のPATH・credential・configを自動共有されるとは扱わない。
• WindowsとWSLを切り替えた後は、Git root、branch、未commit diff、生成物、dist/upload、test・build、source path、外部アクセスの未実行範囲を再確認する。WSL導入・update・shutdownはOS状態の変更として別に扱う。