dotからCodexのPC作業が起動しないときの切り分け｜Windowsのsetup refreshエラー

かがり

前のタスクは動くのに、新しいタスクだけsetup refresh had errors！？ 何を直せばいいのよぉ！

ロコ

急に止まると焦るよね。まず失敗したタスクの実行先とログを確かめよう。

setup refresh had errorsは、準備のどこで失敗したかを示しません。接続を一からやり直す前に、失敗したタスクがどこで動く予定だったかを確認しましょう。

接続したWindows PCで止まっているなら、sandboxログの対象ファイルとWindowsのエラー番号を調べます。os error 32は共有違反、5はアクセス拒否です。この記事では、この違いから次に調べる場所を選び、最後に失敗した入口と同じdot経由の新規タスクで復旧を確かめます。

失敗したタスクは、どのPCで動くはずだったか

失敗したタスクを開き、どの環境で動くはずだったかを見ます。dotのクラウド環境と、接続したWindows PCは別です。手元のPCの問題だと思って調べる前に、次の表で近い状態を探してください。

PCが未接続なら、そのPCのChatGPTアプリでdotのプロフィールを開き、Computers→Your computer→Allow accessへ進みます。表示される確認を読み、PCへのアクセスを許可する場合に接続します。作業中はPCをオンラインにして、ChatGPTアプリを開いておきます。CodexのPC接続やWork Syncとは別の設定なので、画面が合わなければ公式のコンピューター接続手順を確認してください。

PCへの接続はできているのに止まるなら、次はコマンドを起動する準備を見ます。以前から開いているタスクが使えていても、新規タスクの準備だけが失敗することがあります。既存タスクが動くから接続PC側に問題はない、と決めずにログへ進みましょう。

ブラウザーを扱う依頼でも、PCのログイン状態がそのままクラウドへ移るわけではありません。サイトの操作に向けて新しいローカルタスクが作られたら、そのタスクを開いて実行先を確認します。

失敗した時刻のsandboxログを開く

ここからは、接続したWindows PCでコマンドの起動前に失敗した場合です。WindowsのスタートメニューからPowerShellかWindows Terminalを開いてください。失敗中のCodexへ診断を頼んでも、同じ準備エラーで診断コマンドまで始まらない場合があるためです。

作業中の原稿やコードを保存し、アプリの版、CLIの版、Windowsのビルド、今のsandbox設定を控えます。設定を変える前の状態が残っていれば、対処後と比べられます。CLIは複数入っている場合もあるので、調べた実行ファイルの場所も記録しましょう。

まずは次の読み取りコマンドで、診断用ファイルの一覧を出します。CODEX_HOMEが設定されていればその場所、なければ標準の.codexを使う形です。

$CodexDir = if ($env:CODEX_HOME) { $env:CODEX_HOME } else { Join-Path $env:USERPROFILE '.codex' }
$SandboxDir = Join-Path $CodexDir '.sandbox'
Get-ChildItem -LiteralPath $SandboxDir -File |
  Where-Object Name -Match '^(sandbox.*\.log|setup_error.*\.json)$' |
  Select-Object Name, Length, LastWriteTime

一覧から、タスクが失敗した時刻のログを選びます。公式資料にはsandbox.logの例がありますが、日付入りの名前もあります。次の例のログ名を、自分の一覧にあるものへ替えてください。

$LogPath = Join-Path $SandboxDir 'sandbox.2026-10-09.log'
Select-String -LiteralPath $LogPath -Pattern 'runtime read/execute|os error|SetNamedSecurityInfoW|completed with errors' -Context 2,2

探すのは、失敗した処理、その対象になったファイルやフォルダー、os errorなどの番号です。setup_error.jsonが大まかな説明だけでも、同時刻のsandboxログに詳しい対象が残っていることがあります。前後の行まで読んでみましょう。

ログを問い合わせへ添えるなら、個人のフォルダー名やコマンド内容を見て、必要な箇所だけ抜き出します。認証情報や.sandbox-secretsの中身は共有しないでください。対象と番号が伝われば、ログ全体を渡さなくても切り分けを進められます。

エラー32とエラー5で、次の手を分ける

Microsoftの定義では、32がERROR_SHARING_VIOLATION、5がERROR_ACCESS_DENIEDです。番号だけで対処を決めず、対象と失敗した操作も合わせます。エラー5なら、先に所有者とアクセス権を読み取る手順へ進んでください。

エラー32なら、まずアプリの更新と公式の方式を確認

使用中のEXEやDLLでエラー32が出る場合、参考になるのがOpenAIのPR #51822です。2026年10月7日（UTC）に取り込まれ、最大限の権限を要求して開く際の共有違反を避ける修正が入っています。ACLの更新が必要な場合に、そのための権限で開く内容です。手元のDesktopへ含まれるかは配布版で変わるので、更新案内を見て、更新後の新規タスクで確かめます。

この先のMXC・elevated・unelevatedは、Codexのコマンドを隔離して動かす方式の名前です。設定の値だけを先に替えるのではなく、今のアプリが対応している方式から確認しましょう。

Windows sandboxの公式説明では、端末と管理方針が対応していればMXCを優先します。対応した消費者向けDesktopアプリでは自動で選ばれます。MXCを使えないときは従来方式のelevated、その準備も使えず管理方針が許すときにunelevatedが代替候補になります。

Windowsのビルド番号だけでは、使う方式を決められません。実際のアプリが対応するものを見てください。設定値が従来方式の代替を選ぶために使われる場合もあるので、値を書き替えたことと、実行方式が切り替わったことも分けて確かめます。

codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE

一時的にunelevatedを使うなら、戻すところまで準備する

2026年10月9日の一台の記録では、elevatedからunelevatedへ一時変更すると新規タスクで読み書きでき、元へ戻すとエラー32が再発しました。これは作業再開に使えた暫定回避の記録です。元の方式の不具合を直した結果として、同じ変更を無条件に勧めるものではありません。

unelevatedはelevatedよりネットワーク隔離が弱く、読み取り禁止パスにも対応しません。 この違いを許容できない場合や、管理方針で認められない場合は切り替えず、ログを管理担当者へ渡してください。以下は、利用中の版が対応し、必要な承認を得た場合に限る、変更前から復元までの確認手順です。

1. 元の設定を控え、該当項目だけを変える

変更を認められた場合は、ユーザー設定のconfig.tomlを開きます。標準の場所は次のとおりです。CODEX_HOMEを使っている場合は、そのフォルダー内を見てください。

%USERPROFILE%\.codex\config.toml

最初にファイルのコピーを残し、[windows]内のsandboxの元の値を控えます。この項目は、今後作るWindowsタスクにも影響する可能性があります。対象となる既存の項目だけを、次の値へ変更します。

[windows]
sandbox = "unelevated"

この二行で設定ファイル全体を置き換えないでください。既存の[windows]がある場合も、同じセクションを重ねず、その中の該当項目を使います。

2. dot経由で新しいタスクを作り、読み書きを試す

最初に失敗した入口と同じように、dot経由で新しいPC作業タスクを作ります。まずGet-Locationだけを頼み、場所と終了コード0が返るかを見ます。同時刻のログでも、準備エラーが再発していないか確かめましょう。

読み取りが通ったら、新しい使い捨てフォルダーで作成と編集を試します。次の例はTEMPへの書き込みが許可されている場合です。別の作業フォルダーだけが許可対象なら、保存先をその範囲へ合わせてください。

$ErrorActionPreference = 'Stop'
Get-Location
Get-Date -Format o
$ProbeDir = Join-Path $env:TEMP ('codex-dot-probe-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $ProbeDir | Out-Null
$ProbeFile = Join-Path $ProbeDir 'probe.txt'
Set-Content -LiteralPath $ProbeFile -Value 'created' -Encoding utf8
if ((Get-Content -LiteralPath $ProbeFile -Raw).Trim() -ne 'created') { throw 'create check failed' }
Set-Content -LiteralPath $ProbeFile -Value 'edited' -Encoding utf8
if ((Get-Content -LiteralPath $ProbeFile -Raw).Trim() -ne 'edited') { throw 'edit check failed' }
'DOT_NEW_TASK_READ_WRITE_OK'

DOT_NEW_TASK_READ_WRITE_OKと終了コード0が出れば、作成後と編集後の内容を読み戻すところまで通っています。保存先で権限拒否になった場合は、コマンド起動前のsetupエラーと分けて調べます。試験フォルダーは結果が分かるまで残し、片付ける際は今回作った一つの場所を特定してください。

3. 元の値へ戻し、別の新規タスクで比べる

結果を記録したら、変更したsandboxの項目を元の値へ戻します。元がelevatedだった場合は、次の状態です。

[windows]
sandbox = "elevated"

復元するのは今回変えた項目だけです。古いコピーでファイル全体を戻すと、試験中に加わった別の変更も失う場合があります。

元へ戻した後も、dot経由で別の新規タスクを作り、同じ読み取りを試します。再発したら、新しいログから対象と番号を控えましょう。暫定運用を続けるかは隔離の違いと管理方針で判断し、更新後に元の方式で試す予定も残します。

エラー5では所有者とアクセス権を読み取る

エラー5なら、ログが指した対象の所有者とアクセス権を読み取ります。たとえばプロジェクトの.gitで失敗していれば、次のパスを自分のプロジェクトへ置き換えて調べられます。

$ProjectDir = 'C:\path\to\project'
Get-Item -LiteralPath (Join-Path $ProjectDir '.git') |
  Select-Object FullName, PSIsContainer
Get-Acl -LiteralPath $ProjectDir | Select-Object Owner
Get-Acl -LiteralPath (Join-Path $ProjectDir '.git') |
  Select-Object Owner, AccessToString

Gitのworktreeでは、.gitがフォルダーではなく、参照先を書いたファイルになっている場合があります。この例で読めるのは、そのファイル自体のACLです。Gitの管理ディレクトリーまで調べる場合は、中のgitdir:が示す場所も確認対象になります。

Zennには、.gitの所有者とエラー5を調べ、所有権の変更で復旧した報告があります。ただし、所有者が違うだけでは変更が必要と決まりません。takeownや再帰的なicaclsを使う前に、失敗した処理に必要な権限、変更する範囲、戻し方を確認します。管理端末では、読み取った結果をIT担当者へ渡しましょう。

2026年10月9日の確認では、何が分かったか

exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors

runtime read/execute validation failed
target: <Codex runtime>\bin\node_repl.exe
open ACL target for root-only update
os error 32
setup refresh completed with errors

かがり

読み取りは通ったのに、保存は失敗したわ……。また最初のエラーなの？

ロコ

今回はコマンドが始まったんだね。保存先の権限と、起動前の準備エラーを分けて記録しよう。

結果を残すときは、次の形で一回の試験をまとめると、問い合わせる相手にも停止した場所が伝わります。これは記入用のひな形で、成功した結果ではありません。

試した時刻：
入口：dot経由の新規タスク
実行先PC：
sandbox方式（確認できた範囲）：
Get-Location：成功 / 起動後に失敗 / 起動前に失敗
使い捨てファイルの作成・読み戻し：
編集・再読み戻し：
同時刻のログにある対象と番号：
元設定への復元と、その後の新規タスクの結果：

起動前に止まったなら、実行していない読み書きまで「失敗」とまとめず、「未実行」と残します。読み取りだけ通った場合も、作成や編集の復旧はまだ確かめられていません。どこまで進んだかが分かれば、同じ接続のやり直しを繰り返すより、次に必要な調査を絞れます。

まだ止まる場合は、新しいログを添えて状況を伝える

対処後も止まるなら、新しいログの対象ファイルと番号を見ます。最初と同じエラーとは限りません。問い合わせにはアプリ・CLI・Windowsの版、dot経由の新規タスクであること、sandbox方式、個人情報を伏せたログ、試した操作と結果を添えると、調べた範囲が伝わります。

復旧したかは、最初に失敗したdot経由の新規タスクで、許可された範囲の読み書きが通るかで判断しましょう。作業へ戻るときは、保存した原稿の場所、完了したこと、残りの作業を短くまとめて渡すと、診断前の続きから始めやすくなります。