Codex Cloudでは、タスクごとに独立した作業領域が使われます。だから、変更が見つからないときは新しいタスクを開き続けず、まず元のタスクを再表示してください。大切な差分は確認後にバージョン管理へ記録します。OpenAIの公式説明にある保存済みVM状態の復元期間も、会話やファイルがいつまでも残る保証ではありません。
この記事が役立つ人
旅先でCodex Cloudを使い、タスクの終了や切り替え後にコードを見失いたくない開発者。
端末を替えて作業を続ける前に、変更を確かめて記録する手順を整えたい人。
iOSプロジェクトで、クラウド上のコード作業とMacでの検証を分けたい人。
最終更新:2026年11月8日。仕様はOpenAIのCodex Cloud公式ヘルプで確認しています。
Codex Cloudのタスク変更の保存先を切り分ける
「タスクの会話に変更内容が書かれている」ことと、「変更がリポジトリにコミットされている」ことは別です。復帰時は、会話履歴、タスクの作業領域、VM状態、Gitリポジトリをひとまとめにせず、順に確かめます。
| 確認対象 | 何が分かるか | 見つからない場合の次の確認 |
|---|---|---|
| タスクの会話 | 指示や実行結果、作業の経緯 | 元のタスクを開いて状態を確認 |
| タスクの作業領域 | そのタスク内で扱ったファイルと差分 | 新しいタスクではなく元のタスクへ戻る |
| 保存済みVM状態 | 公式説明の条件に合う環境状態の復元可否 | 対象となる状態と期間を公式ヘルプで確認 |
| Gitリポジトリ | コミット済み変更とブランチの履歴 | ローカル差分、認証、ブランチ権限を個別に確認 |
この違いが見落とされやすいのは、作業の説明が会話に残っていても、ファイルの差分やコミットが同じ場所にあるとは限らないためです。成果を後から別の端末や作業環境で確認したいなら、会話だけを保存先として扱わず、Gitの記録まで確認してください。
新しいタスクで前の未コミット変更を探さない
Codex Cloudでは、タスクごとに独立した作業領域が用意されます。元の作業を続ける操作と、新しいタスクを始める操作は同じではありません。新しいタスクを開いて前の未コミット変更が見えなくても、それだけで変更が消えたとは判断できません。まず元のタスクに戻ってください。
元のタスクから差分を確認する
タスク一覧から該当するタスクを開き、指示と実行結果を見直します。続けて、変更されたファイルや差分が表示されるかを確認してください。元のタスクに差分があれば、変更内容を読み、必要な修正やテストを続けます。
反対に、別タスクの画面で変更が見つからない場合は、その作業領域を前のタスクの復元結果とみなさないでください。「タスクを再開する」操作を優先し、新しいタスクの作業結果と混ぜないのが安全です。
切断や中断後は状態を確認してから作業を再開する
旅先で通信が切れたときや、iPadから軽量ノートへ切り替えたときは、画面が開けるかどうかだけでコードの状態を判断しないでください。アクセスできない理由は、端末側の接続、タスクの状態、リポジトリの権限などに分かれます。
| 症状 | 先に見る場所 | 避けたい判断 |
|---|---|---|
| Codex Cloudに接続できない | 端末と接続環境、その後に元のタスク | 接続失敗をファイル消失と決めつける |
| タスクの状態が以前と違う | 元のタスクと公式ヘルプの復元条件 | 会話が残っているからVM状態も戻ると考える |
| GitHubへプッシュできない | 認証状態とブランチのルール | プッシュ失敗を作業ファイルの消失と扱う |
公式ヘルプに記載されたVM状態の復元期間は、保存された環境状態に関する条件です。すべてのタスク、ファイル、アカウントが常に復元できるという意味ではなく、会話履歴の保存期間とも同一ではありません。期間を一律に断定せず、作業を戻す時点で公式ヘルプの最新説明を確認してください。
注意:タスクの画面が見えることだけを根拠に、重要な変更が保存済みと判断しないでください。ファイル差分とGit上の記録は別々に確認します。
旅先でも迷わない復帰手順を作る
次の手順を、タスクを離れる前と戻ってきたときの確認に使えます。
最初に、元のタスクを開きます。 新規タスクを作る前に、以前のタスク名や指示を特定し、状態と変更ファイルを確認してください。
次に、差分を読みます。 変更された内容が依頼した範囲に収まっているかを見ます。会話上の完了報告だけで、ファイルの変更まで完了したと判断しないでください。
そのうえで、テストを実行します。 プロジェクトで用意されているテストやチェックを実行し、成功・失敗の結果を記録します。iOSアプリでは、コード上の確認と、実際のビルドや端末での検証を区別します。
重要な差分をコミットします。 コミット前に変更ファイルを見直し、不要なファイルや秘密情報が含まれていないことを確認します。GitHubへのファイル追加やコミットの基本はGitHubの公式手順を参照してください。
必要ならブランチへプッシュします。 GitHubのプッシュ手順に沿って、対象ブランチと送信結果を確認します。認証で止まる場合はGitHubの認証説明、保護ルールで拒否される場合は保護ブランチの説明を確認します。
最後に、戻って再確認します。 元のタスクとGitリポジトリを開き、差分・コミット・プッシュ結果を照合してください。端末を替えても同じ記録をたどれる状態になってから、次の作業へ移ります。
よくある復帰トラブルを先回りして解消する
新しいタスクに前の変更が見当たらない
Codex Cloudの新しいタスクは、前のタスクの未コミット変更を自動的に引き継ぐものではありません。元のタスクを開き直し、ファイル差分を確認してください。共有や別環境での再開が必要なら、重要な変更をリポジトリにコミットしてから扱います。
休止したタスクをどこから続けるか分からない
元のタスクを開き、タスクの状態とファイルを確認してから作業を再開します。保存済みVM状態を戻せるかは、公式説明にある対象条件と復元期間に従います。会話履歴が残っていることだけを根拠に、実行環境まで復元済みと考えないでください。
GitHubへの送信が失敗する
ファイルが作業領域にあるかを先に確認し、その後で認証とブランチの権限を調べます。認証エラーや保護ブランチの拒否は、作業領域にある差分の有無とは別の切り分け項目です。変更が見えているなら、エラーを解消するまで差分を保全し、無関係なタスクを作って移し替えないようにします。
iOS作業はコードの保存とMacでの検証を分ける
Codex Cloudでコード変更を確認できても、その環境をmacOSやXcodeの実行環境と同じものとして扱わないでください。iOSプロジェクトの納品にビルド、シミュレーターでの確認、署名などが必要なら、リポジトリに残す作業とMac上で行う検証を分けて計画します。AppleのXcode公式ドキュメントで、必要な開発作業を確認してください。
| 選択肢 | 向いている場面 | 注意点 |
|---|---|---|
| Codex Cloudのタスク | コード変更やタスク単位の作業 | 差分を確認し、必要な変更はGitに記録する |
| 手元のMac | 継続してMac環境を使い、手元の機器も必要 | 端末を携帯し、作業環境を自分で維持する |
| リモートMac | iOSのビルド・テストなど、実際のMac環境が必要 | リポジトリと認証を用意し、Mac上で検証する |
短期間の納品や一時的な検証なら、MACCOMEのリモートMac利用案内を確認し、必要な期間だけ利用する方法があります。Macを常時使う長期の重い作業なら、自分のMacを用意する方が都合のよい場合もあります。USB機器などの物理接続が必須なら、リモート環境だけで完結するか事前に確かめてください。サービスの案内はMACCOMEの日本語ページから確認できます。
Codex Cloudのタスクを切り替えた後に差分が見えないときは、新規タスクではなく元のタスクを調べ、重要な変更をコミットしてから次へ進んでください。iOS作業でMac固有のビルドやテストが必要な場合は、コードの保管とは別に、その検証環境をどう用意するか決めましょう。