「Error starting chat」とCannot serialize value:まずLocalで送り直す
ChatGPTデスクトップアプリのCodexで新しいチャットを始め、最初のメッセージを送った直後に次の表示が出た場合、原因はリポジトリやプロンプトではありません。
Error starting chat
Cannot serialize value: (couldn't stringify value)アプリのバージョン26.1016.51333で、Worktreeモードのチャットを開始するときだけ失敗する不具合です。macOS・Windows・Linuxのすべてで報告があり、helloのような短いテキストだけでも再現します(GitHub issue #55744)。上の行の「Error starting chat」はUIの言語によって翻訳されて表示されることがありますが、2行目は英語のままです。
今すぐ作業を続けるには、次の2手順で足ります。
- 新しいチャット画面で、入力欄の下にあるWorktreeの選択(New worktree)をオフにし、Localを選ぶ。新規チャット設定の歯車アイコンから切り替えられたという報告もあります。
- 同じメッセージを送り直す。アプリの再起動は不要です。
この方法は3つのOSで多くのユーザーが確認しています(報告1、報告2)。代わりに、Codexは手元のチェックアウト(いま開いている作業フォルダ)を直接編集します。作業中の変更がある場合は、先にコミットするかブランチを分けておくと、Codexの変更と混ざりません。
ボタン名は英語UIでの表記です。日本語UIでは表示が異なる場合があります。
分離したワークツリーで作業を続けたい場合は、後半の「分離を保ったまま作業する方法」から選んでください。
この不具合かどうか:Worktreeだけ失敗し、26.1016.51333で起きる
次の3点がそろえば、この不具合と考えてよいです。
| 確認すること | この不具合の場合 | 違う場合に考えること |
|---|---|---|
| チャットのモード | Worktree(New worktree)で開始したときだけ失敗する | Localでも失敗するなら別の問題 |
| 失敗のタイミング | 新しいチャットの最初のメッセージを送った直後。「新しいチャット」を押した時点では出ない | 会話の途中で出るなら別の問題 |
| アプリのバージョン | 26.1016.51333(build 21161) | 別バージョンなら、まずバージョンを確認し直す |
バージョンはアプリの「バージョン情報」で確認できます。Windowsではインストール済みパッケージ名がOpenAI.Codex_26.1016.6573.0_x64のように別の番号で表示されますが、バージョン情報では26.1016.51333と表示される同じビルドです(Windowsでの報告)。どちらの番号を見ても、26.1016であれば該当します。
2026年7月9日からCodexはChatGPTデスクトップアプリの一部になっており、報告では同じビルドが「Codex desktop 26.1016.51333」とも「ChatGPT desktop 26.1016.51333」とも呼ばれています。どちらの名前で使っていても同じ不具合です。
報告者の多くは、10月21日にアプリを更新した直後から発生したと書いています。Windowsのログでは、更新前の26.1013ではWorktreeチャットが正常に作成され、更新後の最初の起動から同じエラーが記録されていました(同じ報告)。ただし、旧バージョンに戻して比べた検証はないため、更新で入った不具合(リグレッション)というのは推定です。
SSHで接続したリモートホスト上のGitプロジェクトでも、Worktreeで開始すると同じエラーになります(WindowsからリモートLinux、macOSからリモートMac)。
Localでも失敗する、VS Codeで出る場合は別の問題
次の場合は、見た目が似ていてもこの不具合ではありません。
- Localモードのチャットでも同じように失敗する。
- VS Code拡張で出ている。9月にはVS Code拡張で「Error creating chat」とシリアライズに関するエラーが報告されていましたが、別の件です。
- バナーが「Error submitting message」で、2行目に別の文言が出ている。
アプリそのものが起動しない場合は「WindowsでCodex app-serverが起動しない:エラー文別の直し方」、接続が切れて再接続を繰り返す場合は「CodexがReconnectingを繰り返すときの安全な復旧手順」、起動時に設定の読み込みが時間切れになる場合は「Codexがcloud config bundleを15秒で読み込めない・Failed to loadの切り分け」が該当します。
再起動・再インストール・ブランチの選び直しで直らない理由
issueに寄せられた報告では、次の操作はどれも効果がありませんでした。
- アプリの再起動、完全に終了してからの再起動(報告)
- macOSアプリの再インストール(報告)
- 開始ブランチの選び直し(報告)
- 保存されたプロジェクト設定の修復(報告)
- メッセージの書き換え。短いテキストだけでも失敗します
再インストールした人のアプリはコード署名の検証を通過しており、インストールの破損ではありません。
失敗している場所は、ユーザーが共有したログでかなり絞り込まれています。デスクトップアプリのログには[Composer] submit failed、errorName=TypeError、mode=worktreeが記録され、エラーはワークツリー作成の依頼(managedWorktrees.pending.create)をアプリ内部で送る前の段階で起きています(ログの報告)。ワークツリーはまだ作られておらず、リポジトリ自体には問題がありません。git worktree listも正常に動きます。同じ環境のLocalなら送信できることからも、ネットワークやGitの設定を変えても結果は変わらないと考えられます。

「シリアライズ」は、アプリが入力内容などを内部でやり取りできる形にまとめる処理のことです。2人のユーザーが実行中のアプリにデバッガを付けて調べたところ、拒否されていたのはopeningPromptForHistory.document.attrsという値でした(Windowsでの調査、macOSでの調査)。入力欄の文書データから作られる、プロトタイプを持たない特殊なオブジェクトです。アプリのシリアライザは通常のオブジェクトしか受け付けず、エラーメッセージを作るためにその値を文字列にする処理まで失敗します。そのため、問題のある値の名前ではなく(couldn't stringify value)とだけ表示されます。
この値を通常のオブジェクトに直す一時的なパッチを実行中のアプリに当てたところ、Worktreeチャットが開始できたという報告もあり、原因の裏付けになっています。ただし、これはコミュニティの診断で、OpenAIは確認していません。パッチはメモリ上だけのもので再起動すると消えますし、署名されたアプリの中身を書き換えたりデバッガでコードを差し込んだりするのは、普段の作業で使う方法ではありません。修正版を待つ間は、次の回避策を使ってください。
分離を保ったまま作業する方法:検証の度合いとOSで選ぶ
Localで送る方法は確実ですが、作業フォルダを直接触られたくない、複数のタスクを並行させたいという場合はワークツリーが必要です。2026年10月22日時点で報告されている方法を、分離の度合いと検証の度合いで並べると次のとおりです。
| 方法 | 作業の分離 | この不具合での検証 | 報告のあるOS | 主な注意点 |
|---|---|---|---|---|
| Localで送る | なし(手元のチェックアウトを直接編集) | 多数のユーザーが確認 | macOS・Windows・Linux | 作業中の変更と混ざる |
| Localで始めてHand offでWorktreeへ移す | あり | 1件 | macOS | .gitignore対象のファイルは原則として移らない |
| LocalのチャットからCodexに管理ワークツリーを作らせる | ファイルは分離、チャットは元の場所 | 複数件 | macOS・Windows | 以後はワークツリーのパスを指定して作業させる |
| Codexに新しいWorktreeチャットを作らせる | あり(新しいチャットごと) | 2件 | macOS(1件はリモートLinuxのプロジェクト) | WindowsとLinuxでの報告はない |
| カスタムプロンプトを付けてWorktreeのまま送る | あり | 1件 | macOS(リモートMacのプロジェクト) | 2026年1月22日に非推奨になった機能に頼る |
| 永続ワークツリー(permanent worktree) | あり | 報告なし(未検証) | — | 効くかどうか分からない |
自分でgit worktree addする | あり | 手動作成の成功は報告あり | Windowsから接続したリモートLinux | .envなどは自分でコピーする |
選び方の目安は次のとおりです。macOSでチャットごとワークツリーで動かしたいなら、Codexに新しいWorktreeチャットを作らせる方法(2件)か、Hand off(1件)。Windowsでは、Codexに管理ワークツリーを作らせる方法に成功例があります。いつもどおりWorktreeを選んで送りたいだけならカスタムプロンプトも使えますが、非推奨の機能に頼る一時しのぎです。アプリの機能に頼らず確実にワークツリーを用意したいなら、自分でgit worktree addします。

Localで始めてHand offでWorktreeへ移す
- Localモードで新しいチャットを開始し、最初のメッセージを送る。
- チャットのヘッダーにあるHand offを使い、チャットをWorktreeへ移す。
macOSでこの手順を試した報告では、ワークツリーの作成、変更の移動、チャットの切り替えがすべて成功し、それまでのやり取りも残っていました(検証の報告)。失敗するのはWorktreeで新しいチャットを直接開始する経路だけで、ワークツリーの作成やHand offそのものは動いている、ということです。WindowsとLinuxでの報告はまだありません。
公式ドキュメントでは、Hand offはチャットとコードを一緒に移す操作です(Worktreesのドキュメント)。手元に未コミットの変更がある状態で実行する前に、何を移したいのかを確認しておくと安全です。また、.gitignoreの対象になっているファイルは、.worktreeincludeでコピーを指定していない限り、移動先のワークツリーには入りません。
LocalのチャットからCodexに管理ワークツリーを作らせる
Localで動いているチャットの中で、Codexに次のように頼みます。
Create and attach a managed worktree for this task, then do all work in that checkout.日本語で「このタスク用に管理ワークツリーを作成してアタッチし、以後の作業はすべてそのチェックアウトで行って」と頼んでも意図は同じです。報告では、Codexが組み込みのワークツリー作成機能を呼び出し、管理ワークツリー(Codex-managed worktree)が作成されてチャットにアタッチされました。macOSとWindowsで成功例があります(macOSでの検証、Windowsでの検証、別のmacOSでの報告)。
注意点が1つあります。チャット自体は元のチェックアウトに残ったままです。以後は、Codexが返したワークツリーのパスを明示して、そこで作業するよう指示する必要があります。チャットごとワークツリーで動かしたい場合は、次の「新しいWorktreeチャットを作らせる」方法が向いています。依存関係のインストールや開発用サービスの起動も行われないので、必要なら自分で準備します。
管理ワークツリーは、既定で$CODEX_HOME/worktreesの下に作られます(場所はSettings > Worktrees > Worktree rootで変更できます)。ブランチではなくdetached HEADの状態で始まり、アプリは既定で直近15個の管理ワークツリーを保持します。
Codexに新しいWorktreeチャットを作らせる
動いているチャット(Localで構いません)の中で、Codexに普通の言葉で頼みます。たとえば「このプロジェクトで、ワークツリーを使う新しいチャットを開始して。そのチャットで〇〇をして」のように、依頼内容も一緒に伝えます。
報告では、Codexがアプリの組み込み機能で新しい管理ワークツリーを作り、新しいチャットがその中で始まって最初の応答まで完了しました。pwdやgit statusでも、作業場所が変更のないdetached HEADのワークツリーであることが確認されています(macOSでの検証、macOSからリモートLinuxのプロジェクトでの検証)。入力欄から直接Worktreeで開始する経路を通らないため、不具合を避けられると説明されています。
前の方法との違いは、新しいチャットそのものがワークツリーで動くことです。パスを毎回指定する必要はありません。成功例は2026年10月22日時点でmacOSの2件だけで、WindowsとLinuxでの報告はありません。Codexが内部でどの機能を使うかは依頼の受け取り方に左右されるので、新しいチャットが一覧に現れ、その作業場所がワークツリーになっているかを確かめてから作業を任せてください。
カスタムプロンプトを付けてWorktreeのまま送る(一時しのぎ)
普段どおりWorktreeを選んで送る形を保ちたい場合の方法です。ただし、使うのは非推奨になった機能です。
- アプリを動かしているマシンに
~/.codex/prompts/worktree-start.mdを作り、次の1行を書く。
Work in the isolated worktree created for this chat. Follow the request below.- アプリのウィンドウを再読み込みして、プロンプトを読み込ませる。
- Worktreeを選んだまま、
/prompts:worktree-startの後ろに依頼内容を続けて送る(例:/prompts:worktree-start テストを追加して)。
macOSからリモートのMacにあるプロジェクトを使っていたユーザーが、この方法でWorktreeチャットが開始できたことを確認しています(報告)。報告者の調査では、カスタムプロンプトが展開されると入力のテキストが変わり、問題の文書データが送信内容に含まれなくなるため、と説明されています。
注意点として、カスタムプロンプトは2026年1月22日に非推奨となり、代わりにスキルを使うよう案内されています(changelog)。26.1016ではまだ動いた報告がありますが、いつ使えなくなってもおかしくありません。成功報告も1件だけです。修正版が届くまでの一時しのぎとして使ってください。
永続ワークツリー(permanent worktree)はこの不具合では未検証
サイドバーのプロジェクトの三点メニューから、永続ワークツリーを作成できます。独立したプロジェクトとして表示され、自動では削除されず、複数のチャットを置けます。管理ワークツリーとは別の仕組みです。
2026年10月22日時点で、この不具合の回避に永続ワークツリーを試した報告はありません。試す場合は、作成された永続ワークツリーのプロジェクトで、WorktreeではなくLocalを選んでチャットを始めてください。不具合はWorktreeで新しいチャットを開始する経路にあるため、Localなら避けられる見込みがありますが、これは推定です。
自分でgit worktree addし、そのフォルダでLocalのチャットを使う
アプリに頼らず、Gitでワークツリーを作る方法です。リポジトリのルートで次を実行します。
# 隣のフォルダに、新しいブランチfix/xのワークツリーを作る
git worktree add ../app-fix -b fix/x
# Gitが追跡していない設定ファイルは自分でコピーする(例:.env)
cp .env ../app-fix/作成した../app-fixをアプリにプロジェクトとして追加し、そのプロジェクトでLocalのチャットを始めます。影響を受けている環境でも、Gitによるワークツリーの手動作成は成功しています(リモートLinuxでの報告)。そのフォルダでLocalのチャットが使えるのは、Localモードが正常に動くことからの推定です。
気をつける点は3つです。
- .worktreeincludeはアプリが作る管理ワークツリーにしか効かないため、コマンドラインで作ったワークツリーには.envなどがコピーされません。
- Gitでは、同じブランチを複数のワークツリーで同時にチェックアウトできません(git-worktreeのドキュメント)。元のチェックアウトで使っているブランチは指定できません。
- 作業が終わったら
git worktree remove ../app-fixでワークツリーを消し、不要ならブランチもgit branch -d fix/xで削除します。
Localで作業する間、Codexが書き込める範囲や承認の扱いを見直したい場合は「Codex サンドボックスと config.toml:承認・書き込み・ネットワーク」が参考になります。
修正状況(2026年10月22日時点):issue #55744は未解決、修正版の告知なし
2026年10月22日時点(日本時間10時20分ごろ)の状況は次のとおりです。
- issue #55744は未解決(open)のままで、bug・app・sessionのラベルが付き、コメントは63件、リアクションは145件です。スレッド内にOpenAIのメンバーからの返信はありません。
- Linuxで報告された#55823、Windowsで報告された#55827も未解決です。
- 公式のchangelogで最新のCodexアプリの項目は10月8日の26.1007で、26.1016もこの不具合の修正も載っていません。
修正がいつ届くかを示す公開情報はありません。
旧バージョンへのダウングレードは勧めません。26.1013.40934に戻すつもりだと書いた人はいますが、実際に戻して直ったという報告はありません(該当の報告)。公式に旧バージョンを入手する方法や戻し方も公開情報には見当たらないため、解決策としては扱えません。
ほかの入口については単独の報告が1件ずつあります。同じMacに接続したiPhoneのChatGPTアプリからWorktreeチャットを開始すると成功し(報告)、codex-cliは普段どおり動くとのことです(報告)。CLIにはデスクトップアプリの入力欄がないので、失敗する経路を通らないと考えられます。
修正が届いたら:Worktreeチャットを1つ試してから元の手順に戻す
アプリが更新されたら、すぐに元の作業をWorktreeで再開するより、次の順で確かめるほうが手戻りがありません(推奨の手順で、公式の案内ではありません)。
- バージョン情報で、26.1016.51333から番号が変わったことを確認する。
- 試し用にWorktreeで新しいチャットを1つ開始し、短いメッセージを送る。
- エラーが出ずにチャットが始まれば、普段のWorktreeの使い方に戻す。まだ失敗するなら、上の回避策を続ける。
OpenAIに伝わるフィードバックの送り方
issueに「+1」とだけ書くより、診断に使える情報をそろえて送るほうが役に立ちます。issueでは、次の形で報告しているユーザーがいます(例1、例2)。
- アプリ内のFeedback、またはチャット欄の
/feedbackからフィードバックを送り、表示されたIDを控える。 - そのIDと、アプリのバージョン、OS、チャットのモード(WorktreeかLocalか)をissue #55744に書く。
ログやスクリーンショットを貼る場合は、リポジトリ名、個人のパス、プロンプトの中身など、公開したくない情報を消してからにしてください。
Codexの「Cannot serialize value」についてのよくある質問
メッセージの内容や添付ファイルを変えれば送れますか?
送れません。添付やメンションのないhelloだけのメッセージでも失敗します。メッセージの中身ではなく、Worktreeで開始するときにアプリが送る内部データで失敗しているためです。
旧バージョンに戻せば直りますか?
2026年10月22日時点で、戻して直ったという報告はなく、公式の旧バージョンの入手方法も見当たりません。ダウングレードより、Localで送るか、ワークツリーを別の方法で用意するほうが確実です。
iPhoneのChatGPTアプリやcodex-cliならWorktreeを使えますか?
それぞれ1件ずつ、使えたという報告があります。iPhoneのChatGPTアプリから、接続中のMacにWorktreeチャットを開始すると成功し、codex-cliも動いたとのことです。どちらも単独の報告なので、手元の環境で確かめてください。
VS CodeのCodex拡張でもこの不具合は起きますか?
VS Code拡張で起きるという報告は、このissueにはありません。VS Codeで似たシリアライズのエラーが出ている場合は、別の問題として切り分けてください。



