CodexでCannot serialize valueが出るときは？新規チャットの確認手順

Codexの新規チャットでCannot serialize value: (couldn't stringify value)が出たら、まずインストール済みのバージョンを記録し、更新を確認します。続く場合は、同じプロジェクトで新しいLocalチャットとWorktreeチャットを比較してください。 最初から履歴を削除したり、APIキーを交換したり、リポジトリをリセットしたりする必要はありません。

このエラーは2026年10月のデスクトップ版で報告されました。報告スレッドは現在クローズされており、macOSとWindowsの特定ビルドで改善したという利用者の投稿があります。過去の障害がすべての環境で続いていると決めつけず、まずバージョンを確認する理由はここにあります。

この記事が扱うのは、特にWorktreeを選んだときの新規チャット送信時の失敗です。公開報告をもとに、既存の作業を保全しながら切り分ける手順を示します。Ofoxでは元の障害を条件を管理した環境で再現していません。以下は確認手順と条件付きの代替策であり、万能な修復方法でも、OfoxのAPIキーでCodexが直るという主張でもありません。

古い回避策を試す前にバージョンを確認する

以下は10月28日に確認したOpenAIのリポジトリのissue #55744の要約です。利用者の報告であり、各プラットフォームの対応状況を網羅する表ではありません。

macOSの改善報告とWindowsの改善報告は、それぞれ別の観測です。古いビルドで更新機能が「最新」と表示しても、それはその環境に現在提供される更新の状態を示すだけです。他のプラットフォームで報告された修正が入っている証拠にはなりません。

未送信のプロンプトを非公開の場所に保存し、進行中の作業を終えるか一時停止してから、アプリが対応する更新方法を使います。更新前後のバージョンを記録してください。更新機能が求めたら再起動し、同じプロジェクトを開き直して短いメッセージを1回送信します。非公式ミラーから古いアプリをダウンロードしたり、インストール済みのアプリファイルを書き換えたりしないでください。

同じ症状かどうかを切り分ける

シリアライズとは、値を転送や保存に適した形へ変換することです。エラー文だけでは、どの値が失敗したか、モデルへのリクエストが送信されたか、リポジトリが破損しているかは分かりません。

設定を変える前に、次の3点を記録します。

1. 段階： アプリを開けないのか、最初のメッセージを送れないのか、実行中のタスクが後から失敗したのか。
2. モード： 新規チャットはLocalかWorktreeか。Gitプロジェクトに関連付けられていたか。
3. 正確なエラー： 括弧内も含め、短いメッセージを全文コピーする。隣に出た別のエラーは分けて記録する。

実際の表示がcouldn’t load workspace settingsなら、ワークスペースの初期化を調べます。拡張機能にcouldn’t load its resourcesと出る場合は、リソース読み込みの手順を使ってください。入力欄にpermission mode is unavailableと出る場合は、その送信時チェックリストを参照します。起きるタイミングが似ていても、原因が同じとは限りません。

issueには、リッチテキスト文書の属性に関する仮説など、クライアント側のシリアライザーを調べた投稿もあります。問題が起きうる箇所を絞る材料にはなりますが、すべての利用者に句読点や中国語を削除させたり、リポジトリ内のJSONファイルを書き換えさせたりする根拠にはなりません。短いプレーンテキストは比較用として役立ちますが、必ず直る方法ではありません。

プロジェクトを変更せずLocalとWorktreeを比較する

本来のタスクではなく、確認専用のプロンプトを使います。

OKとだけ返答してください。ファイルの読み取りや変更、コマンドの実行、
依存関係のインストール、プロジェクトのタスク開始はしないでください。

アカウント、プロジェクト、バージョンをそろえます。まず新規Localチャット、次に同じプロンプトで新規Worktreeチャットを試します。Worktreeの作成時には、プロジェクトで設定されたセットアップが実行されることがあります。先に設定を確認し、副作用がある場合は安全なテスト用リポジトリを使ってください。事例を増やすためだけに、本番プロジェクトで繰り返さないようにします。

切り分けに役立つ差が分かったら、テストを止めます。送信を連打すると余分な記録が増え、最初の失敗を特定しづらくなります。Localでの返答は、その時点でその経路が動いた証拠にすぎません。作業環境の分離やWorktreeのセットアップを確認したことにはなりません。

Localが動く場合の一時的な進め方

Localは選択したチェックアウト上で動作します。別のworktreeには別の作業ディレクトリがあります。Localへの切り替えは、プロジェクト操作が行われる場所を変えるため、同じ分離性を保証するものではありません。

読み取り専用の相談なら、動作するLocalチャットを使い続けるだけで足りる場合があります。編集を許可する前にはチェックアウトを確認し、同じ場所を使う他の作業と調整してください。未コミットの変更と未追跡ファイルを保全します。git reset --hard、git clean、キャッシュ削除をシリアライズエラーの一般的な修復策として実行しないでください。

分離が必要なタスクについては、issueにLocalで開始してからアプリ管理のworktreeを作成した報告があります。これは条件付きの代替策です。インストール済みアプリでその機能が実際に利用できる場合に限って使い、編集前に返されたディレクトリを確認します。指示例は次のとおりです。

現在のチェックアウトは編集しないでください。まず、開始点として意図する
ブランチまたはコミットを特定し、解決されたコミットを報告してください。
アプリが対応する機能を利用できる場合は、それを使って別の管理対象worktreeを
作成してください。絶対パスとHEADを報告し、その後のプロジェクト操作は
すべてそのディレクトリで行ってください。作成や関連付けに失敗したら、
ファイルを編集する前に停止してエラーを報告してください。

開始リビジョンには実際のタスクで必要なものを指定し、無条件にmasterへ置き換えないでください。新規worktreeには、元のチェックアウトの未コミット変更は自動で引き継がれません。必要なら、変更を保全したうえで移行方法を明確に決めます。

続行する前に、返された場所を読み取り専用のGitコマンドで確認します。

git -C /absolute/path/to/worktree rev-parse --show-toplevel
git -C /absolute/path/to/worktree rev-parse HEAD
git -C /absolute/path/to/worktree status --short
git -C /absolute/path/to/worktree worktree list

実際のパスを使い、空白がある場合は引用符で囲みます。ディレクトリが別であること、コミットが合意した開始点と一致すること、初期変更の理由を把握していることを確認してください。ディレクトリができただけでは、アプリへの関連付けや、その後のコマンドがそこで動くことの証明にはなりません。アプリに対応機能がない場合は、読み取り専用にとどめるか、既に対応している開発経路を使います。単なるフォルダーコピーを管理対象worktreeと扱わないでください。

報告に役立つ診断情報を集める

アプリが対応するフィードバックや診断機能を使います。公開報告にはTypeError、入力欄からの送信失敗、mode=worktreeが含まれます。他人のスタックトレースをコピーせず、自分のテスト時刻の前後で対応するイベントを探してください。

関連イベントとその文脈だけを記録します。生ログにはプロンプト、ローカルパス、リポジトリ名、認証情報、セッション識別子が含まれる可能性があるため、共有前に伏せます。次は記入用テンプレートであり、実際に観測したログではありません。

OSとアーキテクチャ：
デスクトップアプリのバージョン／ビルド：
テスト時刻とタイムゾーン：
画面に出た正確なエラー：
新規チャットか既存チャットか：
プロジェクト種別：Git／非Git／なし
Localのテスト：成功／正確なエラー／未実施
Worktreeのテスト：成功／正確なエラー／未実施
提供された更新と適用結果：
worktreeディレクトリは作成されたか：
機密情報を除いた関連診断フィールド：
テスト間で変えたもの：

シリアライザーの仕組みに関する仮説を、自分の環境で確定した根本原因として記載しないでください。開発者にとって重要なのは、worktree作成前、セットアップ中、タスク開始後のどこで失敗したかです。非公開のソースコードをアップロードせず、その区別と最小限の再現手順を提供します。

復旧したかどうかを判断する

復旧とは、警告表示が消えることではなく、必要な操作が再び動くことです。直接Worktreeを作る際の障害なら、新規Worktreeチャットが短いプロンプトを受け付けること、アプリに意図したチェックアウトが表示されること、2つ目の新規チャットも開始できることを確認します。その後、確認済みディレクトリで小さな実タスクを再開し、変更を点検してください。

Localだけが動く場合は、一時的な代替経路あり。直接のWorktree作成は引き続き失敗と記録します。更新が提供されない場合は、バージョンと診断情報をサポート向けに保管します。エラーが変わった場合は、古いスレッドの対策を片端から試さず、Codexエラー索引で新しい症状を調べてください。

Ofoxは開発者向けにこのトラブルシューティング記事を公開しています。モデルの提供元の変更、APIクレジットの購入、モデル利用上限の引き上げが、デスクトップ側のシリアライズ障害を直す根拠にはなりません。