Sandboxed shell commands fail on Windows with `CreateProcessWithLogonW failed: 1326` / `1909`

Open 💬 7 comments Opened Apr 20, 2026 by TenofHearts

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.415.40636

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Shell commands fail when run inside the Codex workspace sandbox on Windows. The commands do not appear to reach PowerShell at all. Instead, process creation fails with CreateProcessWithLogonW errors.

Running the same harmless commands outside the sandbox with escalation works correctly, and file edits inside the workspace still work.

What steps can reproduce the bug?

Start a Codex session on Windows with filesystem sandboxing enabled.
Run a harmless sandboxed shell command from the workspace, for example:

``powershell Get-Location``

Run another harmless sandboxed command, for example:

``powershell Get-Content -LiteralPath .\sandbox-check.txt``

What is the expected behavior?

Sandboxed shell commands should start successfully inside the configured workspace sandbox and execute normally, subject to the workspace-write restrictions.

For example, Get-Location should return the current workspace path.

Additional information

Running the same harmless command outside the sandbox with escalation succeeds:

Get-Location

returns:

C:\Users\ASUS\Documents\Codex\2026-04-20-check-if-the-sandbox-works

A directory listing also succeeds outside the sandbox:

Get-ChildItem -Force

File edits inside the workspace using the patch/edit mechanism also succeed. For example, creating and deleting a temporary file in the workspace worked as expected.

This suggests the workspace path and normal PowerShell execution are valid. The failure appears specific to the Windows sandbox process-launch path.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#18451
#17094
#16780
#18465

Powered by Codex Action

akitooono-eng · 1 month ago

I’m seeing what appears to be the same Windows elevated sandbox failure, with a few additional observations.

Environment

OS: Windows 10 Home
OS build: 26200
Codex app package path includes: OpenAI.Codex_26.519.11010.0_x64
App-bundled CLI: codex-cli 0.133.0
npm Codex also present on PATH: codex-cli 0.130.0
Sandbox mode: Windows elevated sandbox
User account type: Unconfirmed
Secrets/auth files are not included.

Current blocking error

windows sandbox: CreateProcessWithLogonW failed: 1326

The command appears to fail before the requested PowerShell command runs.

Timeline

Earlier in the investigation I saw:

CreateProcessWithLogonW failed: 1909

At that time, CodexSandboxOffline appeared to be locked. After waiting for the lockout cooldown, both sandbox users became active and no longer showed locked status.

Later, I also saw:

os error 740

during setup refresh attempts. This looked related to elevation. After launching Codex with an elevated/admin context, later sandbox logs showed setup refresh success-like entries.

The current persistent failure is now:

CreateProcessWithLogonW failed: 1326

Current sandbox user state

Both sandbox users appear active and not locked:

CodexSandboxOffline: active, not locked
CodexSandboxOnline: active, not locked

State file observations

Metadata only:

CODEX_HOME\.sandbox-secrets\sandbox_users.json
- Size: 828 bytes
- LastWriteTime: 2026-04-24 21:55:03

CODEX_HOME\.sandbox\setup_marker.json
- Size: 255 bytes
- LastWriteTime: 2026-04-24 21:55:03

CODEX_HOME\.sandbox\setup_error.json
- Size: 73 bytes
- LastWriteTime: 2026-05-23 20:32:49
- Masked content:
  {
    "code": "helper_unknown_error",
    "message": "apply deny-read ACLs"
  }

setup_marker.json only appeared to contain setup metadata such as:

version
offline_username
online_username
created_at
proxy_ports
allow_local_binding
read_roots
write_roots

No secrets were included in the inspected masked output.

Relevant masked sandbox.log excerpts

The full log is not attached. Representative masked excerpts:

setup refresh: processed 2 write roots (read roots delegated); errors=[]
setup binary completed
helper launch resolution: using copied command-runner path C:\Users\[USER]\.codex\.sandbox-bin\codex-command-runner-0.133.0.exe
read ACL run completed

A previous elevation-related example:

setup refresh: failed to spawn C:\Users\[USER]\AppData\Local\OpenAI\Codex\bin\...\codex-windows-sandbox-setup.exe:
要求された操作には管理者特権が必要です。 (os error 740)

Recovery attempts

I tried the following carefully and rolled back after failed regeneration attempts:

Waited for the previous 1909 lockout state to clear.
Verified CodexSandboxOffline and CodexSandboxOnline were active and not locked.
Used the app-bundled codex-cli 0.133.0 for later checks.
Temporarily renamed .sandbox-secrets to test whether Codex would regenerate sandbox credentials.

Result: .sandbox-secrets was not regenerated.
Rollback completed successfully.

Temporarily renamed both .sandbox-secrets and .sandbox\setup_marker.json to test whether Codex would regenerate both setup marker and sandbox credentials.

Result: neither file was regenerated.
Rollback completed successfully.

Actions intentionally not performed

Did not inspect auth.json contents.
Did not inspect .sandbox-secrets contents.
Did not inspect sandbox_users.json contents.
Did not change CodexSandboxOffline or CodexSandboxOnline passwords.
Did not delete or recreate sandbox users.
Did not edit config.toml.
Did not switch to unelevated fallback.
Did not reinstall or update Codex yet.

Question

Is there a supported way to reset or regenerate the Windows elevated sandbox credentials / account state after 1909, 740, and persistent 1326?

In particular:

Is there an official command or UI action to reset elevated Windows sandbox credentials under CODEX_HOME?
If sandbox users are active and not locked, but CreateProcessWithLogonW still returns 1326, what is the recommended recovery sequence?
Is manually renaming .sandbox-secrets or setup_marker.json unsupported?
Should the next supported step be Codex app update/reinstall, and if so, which CODEX_HOME files should be preserved or removed?

Additional update after reinstall and explicit admin launch:

I reinstalled the Store version of Codex, then fully closed all Codex-related processes.

After confirming there were no running Codex processes, I launched Codex from the Start menu using:

Right click Codex
→ Run as administrator
→ UAC approved

However, checking the actual running Codex processes shows that they are still not elevated:

Codex.exe  -> TokenElevation=False
codex.exe  -> TokenElevation=False

Representative paths:

C:\Program Files\WindowsApps\OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0\app\Codex.exe
C:\Program Files\WindowsApps\OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

This was after reinstalling and launching from Start menu with “Run as administrator” plus UAC approval.

I did not proceed to run sandbox whoami, because the elevation precondition appears not to be satisfied. This may explain why the elevated sandbox setup/helper previously hit os error 740, and why the sandbox remains stuck at:

windows sandbox: CreateProcessWithLogonW failed: 1326

Question:
Is this expected for the Windows Store/MSIX Codex app? If “Run as administrator” is approved via UAC, should Codex.exe / codex.exe show TokenElevation=True, or is there a different supported way to launch the Codex app with an elevated token for Windows elevated sandbox setup?

Correction / clarification on OS version:

My environment is Windows 11 Home, version 25H2, OS build 26200.8524.

Some tooling / issue context reports the platform as:

Microsoft Windows NT 10.0.26200.0 x64

martinsohn · 1 month ago

I hit a similar elevated Windows sandbox failure, but with a different CreateProcessWithLogonW code: 1907.

Codex managed to solve it.

Environment:

Native Windows
Codex CLI/App via VS Code extension
codex-cli 0.133.0-alpha.1
[windows] sandbox = "elevated"

Initial symptom:

Any normal sandboxed shell command failed before PowerShell started:

CreateProcessWithLogonW failed: 1907

Escalated/outside-sandbox commands worked.
Switching to windows.sandbox = "unelevated" worked around it.

Additional diagnostics:

Local users CodexSandboxOffline and CodexSandboxOnline existed and were enabled.
ADSI showed both sandbox accounts had PasswordExpired = 1.
Attempts to repair/reset the account state with normal local-user management commands failed due to local device policy.
After uninstalling Codex app (+ deleting ~/.codex and the local CodexSandboxOffline and CodexSandboxOnline users) and IDE extension, rebooting, and reinstalling & setting up new sandbox, the sandbox accounts were recreated with PasswordExpired = 0 and the 1907 failure disappeared.

So this may be another variant of the elevated sandbox account/logon failure class: the sandbox local users can enter a password-expired/must-change state, and on some managed Windows configurations normal account repair paths may be blocked by policy.

akitooono-eng · 1 month ago

いくつか追加の観察事項があるものの、Windowsの管理者権限でのサンドボックスの失敗と思われる現象を確認しています。 ## 環境 OS: Windows 10 Home OSビルド:26200 Codexアプリのパッケージパスには以下が含まれます。OpenAI.Codex_26.519.11010.0_x64 アプリバンドル型CLI：codex-cli 0.133.0 npm Codex も PATH に存在します。codex-cli 0.130.0 サンドボックスモード: Windows 管理者権限のサンドボックス ユーザーアカウントの種類：未確認 シークレットファイルや認証ファイルは含まれていません。 ## 現在のブロックエラー `` windows sandbox: CreateProcessWithLogonW failed: 1326 ` 要求されたPowerShellコマンドが実行される前に、コマンドが失敗しているようです。 ## タイムライン調査の初期段階で、私は以下のことを知りました。 ` CreateProcessWithLogonW failed: 1909 ` その時、CodexSandboxOfflineロックされているように見えました。ロックアウトのクールダウンが経過した後、両方のサンドボックスユーザーがアクティブになり、ロック状態は表示されなくなりました。その後、私は以下のものも目にしました。 ` os error 740 ` セットアップ更新試行中に発生しました。これは権限昇格に関連しているようでした。管理者権限でCodexを起動した後、サンドボックスのログにセットアップ更新成功のようなエントリが表示されました。現在発生している継続的な障害は以下のとおりです。 ` CreateProcessWithLogonW failed: 1326 ` ## 現在のサンドボックスユーザーの状態両方のサンドボックスユーザーはアクティブで、ロックされていないようです。 ` CodexSandboxOffline: active, not locked CodexSandboxOnline: active, not locked ` ## 状態ファイル観測メタデータのみ: ` CODEX_HOME\.sandbox-secrets\sandbox_users.json - Size: 828 bytes - LastWriteTime: 2026-04-24 21:55:03 CODEX_HOME\.sandbox\setup_marker.json - Size: 255 bytes - LastWriteTime: 2026-04-24 21:55:03 CODEX_HOME\.sandbox\setup_error.json - Size: 73 bytes - LastWriteTime: 2026-05-23 20:32:49 - Masked content: { "code": "helper_unknown_error", "message": "apply deny-read ACLs" } ` setup_marker.json以下のようなセットアップメタデータのみが含まれているように見えました。 ` version offline_username online_username created_at proxy_ports allow_local_binding read_roots write_roots ` 検査されたマスク処理済み出力には、機密情報は含まれていませんでした。 ## 関連するマスクされたsandbox.logの抜粋完全なログは添付されていません。代表的なマスク処理済みの抜粋を以下に示します。 ` setup refresh: processed 2 write roots (read roots delegated); errors=[] setup binary completed helper launch resolution: using copied command-runner path C:\Users\[USER]\.codex\.sandbox-bin\codex-command-runner-0.133.0.exe read ACL run completed ` 標高に関連した以前の例： ` setup refresh: failed to spawn C:\Users\[USER]\AppData\Local\OpenAI\Codex\bin\...\codex-windows-sandbox-setup.exe: 要求された操作には管理者特権が必要です。 (os error 740) ` ## 回復の試み私は以下の手順を慎重に試しましたが、再生が失敗した場合はロールバックしました。 1. 以前の1909ロックアウト状態が解除されるまで待機しました。 2. 確認済みCodexSandboxOfflineで、CodexSandboxOnline有効であり、ロックされていませんでした。 3. 後々のチェックのために、アプリにバンドルされていたものを使用しましたcodex-cli 0.133.0。 4. Codexがサンドボックスの認証情報を再生成するかどうかをテストするために、一時的に名前を変更しました.sandbox-secrets。 * 結果：.sandbox-secrets再生されませんでした。 * ロールバックが正常に完了しました。 5. .sandbox-secretsCodex がセットアップマーカーとサンドボックス認証情報の両方を再生成するかどうかをテストするために、一時的に両方の名前を変更しました.sandbox\setup_marker.json。 * 結果：どちらのファイルも再生成されませんでした。 * ロールバックが正常に完了しました。 ## 意図的に実行されなかった行為 * 内容物は確認していませんauth.json。 * 内容物は確認していません.sandbox-secrets。 * 内容物は確認していませんsandbox_users.json。 * CodexSandboxOfflineパスワードは変更していませんCodexSandboxOnline。 * サンドボックスユーザーは削除も再作成もされませんでした。 * 編集していませんconfig.toml。 * 非昇格フォールバックには切り替えませんでした。 * Codexの再インストールやアップデートはまだ行っていません。 ## 質問 1909、、740および永続化の後に、Windows の昇格されたサンドボックスの資格情報/アカウントの状態をリセットまたは再生成するためのサポートされている方法はありますか1326？特に： 1. Windowsサンドボックスの管理者権限をリセットするための公式コマンドまたはUI操作はありますかCODEX_HOME？ 2. サンドボックスユーザーがアクティブでロックされていないにもかかわらず、CreateProcessWithLogonWエラーが返される場合1326、推奨される復旧手順は何ですか？ 3. 手動での名前変更はサポートされていません.sandbox-secretsかsetup_marker.json？ 4. 次にサポートすべき手順はCodexアプリのアップデート/再インストールでしょうか？もしそうであれば、どのCODEX_HOMEファイルを保存し、どのファイルを削除すべきでしょうか？再インストール後および管理者権限での起動後の追加アップデート： Codexのストア版を再インストールした後、Codex関連のプロセスをすべて完全に終了しました。 Codexのプロセスが実行されていないことを確認した後、スタートメニューからCodexを起動しました。 ` Right click Codex → Run as administrator → UAC approved ` しかし、実際に実行されているCodexプロセスを確認すると、それらのプロセスはまだ昇格されていないことがわかります。 ` Codex.exe -> TokenElevation=False codex.exe -> TokenElevation=False ` 代表的な経路： ` C:\Program Files\WindowsApps\OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0\app\Codex.exe C:\Program Files\WindowsApps\OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0\app\resources\codex.exe ` これは、再インストール後、スタートメニューから「管理者として実行」を選択し、UACの承認を得てから起動した後のことです。 whoami昇格の前提条件が満たされていないため、サンドボックスの実行は行いませんでした。これが、昇格されたサンドボックスのセットアップ/ヘルパーが以前にエラーになった理由os error 740、およびサンドボックスが次の状態で停止したままになっている理由かもしれません。 ` windows sandbox: CreateProcessWithLogonW failed: 1326 ` 質問：これはWindowsストア/MSIX Codexアプリで想定される動作でしょうか？UACで「管理者として実行」が承認された場合、Codex.exe/codex.exeが表示されるべきでしょうTokenElevation=Trueか、それともWindowsの管理者権限を持つサンドボックス設定で管理者権限を持つトークンを使用してCodexアプリを起動する別のサポートされている方法があるのでしょうか？ OSバージョンに関する訂正／補足：私の環境はWindows 11 Home、バージョン25H2、OSビルド26200.8524です。一部のツール／問題コンテキストでは、プラットフォームが次のように報告されています。 ` Microsoft Windows NT 10.0.26200.0 x64 ``

Additional update: doctor reports 0.135.0 is available, but app-bundled CLI update cannot detect the installation method.

After removing the duplicate npm-installed Codex CLI from PATH, I tested the app-bundled CLI directly from an elevated PowerShell.

Current state:

npm global @openai/codex: removed
where codex: no codex found on PATH
Store app still installed: OpenAI.Codex_26.519.11010.0_x64
App-bundled CLI path used:
C:\Users\[USER]\AppData\Local\OpenAI\Codex\bin\958d608b5e0546a5\codex.exe

codex --version:

codex-cli 0.133.0

codex doctor --summary --no-color --ascii reports:

Codex Doctor v0.133.0 · windows-x86_64

Notes
   [up] updates      0.135.0 available (current 0.133.0)
   [!!] search       search command could not be verified - Install ripgrep or repair the bundled Codex package.

Environment
  [ok] runtime      other
  [ok] install      consistent
  [!!] search       search command could not be verified - Install ripgrep or repair the bundled Codex package.
  [ok] terminal     unknown
  [ok] state        databases healthy

Configuration
  [ok] config       loaded
  [ok] auth         auth is configured
  [ok] mcp          2 server (2 stdio) · 0 disabled
  [ok] sandbox      restricted fs + restricted network · approval OnRequest

Connectivity
  [ok] websocket    connected
  [ok] reachability active provider endpoints are reachable over HTTP

Background Server
  [--] app-server   not running (ephemeral mode)

12 ok | 1 idle | 2 notes | 1 warn | 0 fail degraded

However, running update from the same app-bundled CLI:

C:\Users\[USER]\AppData\Local\OpenAI\Codex\bin\958d608b5e0546a5\codex.exe update

returns:

Error: Could not detect the Codex installation method. Please update manually: https://developers.openai.com/codex/cli/

After that, codex --version still reports:

codex-cli 0.133.0

Also, Microsoft Store reports no update available for the Codex app.

So the current situation is:

Store app: installed and no Store update available
App-bundled CLI: 0.133.0
Doctor: sees 0.135.0 available
codex update: cannot detect installation method
Sandbox: still blocked by CreateProcessWithLogonW failed: 1326

I did not run:

sandbox whoami
setupStart
setup.exe directly
config.toml edits
sandbox user deletion
sandbox user password changes

Question:
Is codex update expected to work from the app-bundled CLI on Windows Store/MSIX installations, or should Store/MSIX users wait for the Store app update instead?

Also, could the search command could not be verified warning indicate a broken bundled package that is related to the Windows sandbox failure, or is it unrelated?

akitooono-eng · 1 month ago

> いくつか追加の観察事項があるもの、Windowsの管理者権限でのサンドボックスの失敗と思われる現象を確認しています。 > ## 環境 > > OS: Windows 10 Home > OSビルド：26200 > Codexアプリのパッケージパスには以下が含まれます。OpenAI.Codex_26.519.11010.0_x64 > アプリバンドル型CLI：codex-cli 0.133.0 > npm Codex も PATH に存在します。codex-cli 0.130.0 > サンドボックスモード: Windows 管理者権限のサンドボックス > ユーザーアカウントの種類：未確認 > シークレットファイルや認証ファイルは含まれていません。 > > ## 現在のブロックエラー > `` > windows sandbox: CreateProcessWithLogonW failed: 1326 > ` > > > > > > > > > > > > 要求されたPowerShellコマンドが実行される前に、コマンドが失敗しているようです。 > ## タイムライン > 調査の初期段階で、私は以下のことを知りました。 > ` > CreateProcessWithLogonW failed: 1909 > ` > > > > > > > > > > > > その時、CodexSandboxOfflineロックされているように見えました。ロックアウトのクールダウンが経過した後、両方のサンドボックスユーザーがアクティブになり、ロック状態は表示されなくなりました。 > その後、私は以下のものも目にしました。 > ` > os error 740 > ` > > > > > > > > > > > > セットアップ更新試行中に発生しました。これは権限付与に関連しているようでした。管理者権限でCodexを起動した後、サンドボックスのログにセットアップ更新成功のようなエントリが表示されました。 > 現在発生している継続的な障害は以下のとおりです。 > ` > CreateProcessWithLogonW failed: 1326 > ` > > > > > > > > > > > > ## 現在のサンドボックスユーザーの状態 > 両方のサンドボックスユーザーはアクティブで、ロックされていません。 > ` > CodexSandboxOffline: active, not locked > CodexSandboxOnline: active, not locked > ` > > > > > > > > > > > > ## 状態ファイル観測 > メタデータのみ: > ` > CODEX_HOME\.sandbox-secrets\sandbox_users.json > - Size: 828 bytes > - LastWriteTime: 2026-04-24 21:55:03 > > CODEX_HOME\.sandbox\setup_marker.json > - Size: 255 bytes > - LastWriteTime: 2026-04-24 21:55:03 > > CODEX_HOME\.sandbox\setup_error.json > - Size: 73 bytes > - LastWriteTime: 2026-05-23 20:32:49 > - Masked content: > { > "code": "helper_unknown_error", > "message": "apply deny-read ACLs" > } > ` > > > > > > > > > > > > setup_marker.json以下のようなセットアップメタデータのみが含まれているように見えました。 > ` > version > offline_username > online_username > created_at > proxy_ports > allow_local_binding > read_roots > write_roots > ` > > > > > > > > > > > > 検査されたマスク処理済み出力には、機密情報は含まれていませんでした。 > ## 関連するマスクされたsandbox.logのこと > 完全なログは添付されていません。代表的なマスク処理済みの先にを以下に示します。 > ` > setup refresh: processed 2 write roots (read roots delegated); errors=[] > setup binary completed > helper launch resolution: using copied command-runner path C:\Users\[USER]\.codex\.sandbox-bin\codex-command-runner-0.133.0.exe > read ACL run completed > ` > > > > > > > > > > > > 標高に関連した以前の例： > ` > setup refresh: failed to spawn C:\Users\[USER]\AppData\Local\OpenAI\Codex\bin\...\codex-windows-sandbox-setup.exe: > 要求された操作には管理者特権が必要です。 (os error 740) > ` > > > > > > > > > > > > ## 回復の試み > 私は以下の手順を慎重に試しましたが、再生が失敗した場合はロールバックしました。 > > 1. 以前の1909ロックアウト状態が解除されるまで待機しました。 > 2. 確認済みでCodexSandboxOffline、CodexSandboxOnline有効であり、ロックされていませんでした。 > 3. 後日のチェックのために、アプリにバンドルされていたものを使用しましたcodex-cli 0.133.0。 > 4. Codexがサンドボックスの認証情報を再生成するかどうかをテストするために、一時的に名前を変更しました.sandbox-secrets。 > > * 結果：.sandbox-secrets再生されませんでした。 > * ロールバックが正常に完了しました。 > 5. .sandbox-secretsCodex がセットアップマーカーとサンドボックス認証情報の両方を再生成するかどうかをテストするために、一時的に両方の名前を変更しました.sandbox\setup_marker.json。 > > * 結果：どちらのファイルも再生成されませんでした。 > * ロールバックが正常に完了しました。 > > ## 意図的に実行されなかった行為 > > * 内容は確認していませんauth.json。 > * 内容は確認していません.sandbox-secrets。 > * 内容は確認していませんsandbox_users.json。 > * CodexSandboxOfflineパスワードは変更していませんCodexSandboxOnline。 > * サンドボックスユーザーは削除も再作成もされませんでした。 > * 編集していませんconfig.toml。 > * 非昇格フォールバックには切り替えませんでした。 > * Codex の再インストールやアップデートはまだ行っていません。 > > ## 質問 > 1909、、740および永続化の後に、Windows の昇格されたサンドボックスの資格情報/アカウントの状態をまたは再生成するためのリセットサポートされている方法はありますか1326？ > 特に： > > 1. Windowsサンドボックスの管理者権限をリセットするための公式コマンドまたはUI操作はありますかCODEX_HOME？ > 2. サンドボックスユーザーがアクティブでロックされていない場合、CreateProcessWithLogonWエラーが返される場合1326、推奨される復旧手順は何ですか? > 3. 手動での名前変更はサポートされていません.sandbox-secretsかsetup_marker.json？ > 4. 次にサポートすべき手順はCodexアプリのアップデート/再インストールでお願いしますか？もしそうであれば、どのCODEX_HOMEファイルを保存し、どのファイルを削除すべきですか？ > > 再インストール後および管理者権限での起動後の追加アップデート： > Codexのストア版を再インストールした後、Codex関連のプロセスをすべて完全に終了しました。 > Codexのプロセスが実行されていないことを確認した後、スタートメニューからCodexを起動しました。 > ` > Right click Codex > → Run as administrator > → UAC approved > ` > > > > > > > > > > > > しかし、実際に実行されているCodexプロセスを確認すると、それらのプロセスはまだ進行されていないことが分かります。 > ` > Codex.exe -> TokenElevation=False > codex.exe -> TokenElevation=False > ` > > > > > > > > > > > > 代表的な経路： > ` > C:\Program Files\WindowsApps\OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0\app\Codex.exe > C:\Program Files\WindowsApps\OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0\app\resources\codex.exe > ` > > > > > > > > > > > > これは、再インストール後、スタートメニューから「管理者として実行」を選択し、UACの承認を得てから起動した後のことです。 > whoamiこれが、昇格されたサンドボックスのセットアップ/ヘルパーが以前にエラーになった理由、os error 740およびサンドボックスが次の状態で停止したままになっている理由はおそらくありません。 > ` > windows sandbox: CreateProcessWithLogonW failed: 1326 > ` > > > > > > > > > > > > 質問：これはWindowsストア/MSIX Codexアプリで想定される動作でお願いしますか？UACで「管理者として実行」が承認された場合、Codex.exe/codex.exeが表示されるべきでありTokenElevation=True、場合によってはWindowsの管理者権限を持つサンドボックス設定で管理者権限を持つ権利を使用してCodexアプリを起動する別のサポートされている方法があるのでしょうか？ > OSバージョンに関する訂正／異議： > 私の環境はWindows 11 Home、バージョン25H2、OSビルド26200.8524です。 > 一部のツール／問題コンテキストでは、プラットフォームが次のように報告されています。 > ` > Microsoft Windows NT 10.0.26200.0 x64 > ` 追加情報：doctorレポートは0.135.0利用可能ですが、アプリにバンドルされたCLIアップデートではインストール方法を検出できません。 PATHから重複してnpmでインストールされたCodex CLIを削除した後、管理者権限で実行したPowerShellからアプリにバンドルされているCLIを直接テストしました。現在の状態: ` npm global @openai/codex: removed where codex: no codex found on PATH Store app still installed: OpenAI.Codex_26.519.11010.0_x64 App-bundled CLI path used: C:\Users\[USER]\AppData\Local\OpenAI\Codex\bin\958d608b5e0546a5\codex.exe ` codex --version: ` codex-cli 0.133.0 ` codex doctor --summary --no-color --ascii報告: ` Codex Doctor v0.133.0 · windows-x86_64 Notes [up] updates 0.135.0 available (current 0.133.0) [!!] search search command could not be verified - Install ripgrep or repair the bundled Codex package. Environment [ok] runtime other [ok] install consistent [!!] search search command could not be verified - Install ripgrep or repair the bundled Codex package. [ok] terminal unknown [ok] state databases healthy Configuration [ok] config loaded [ok] auth auth is configured [ok] mcp 2 server (2 stdio) · 0 disabled [ok] sandbox restricted fs + restricted network · approval OnRequest Connectivity [ok] websocket connected [ok] reachability active provider endpoints are reachable over HTTP Background Server [--] app-server not running (ephemeral mode) 12 ok | 1 idle | 2 notes | 1 warn | 0 fail degraded ` しかし、同じアプリバンドルCLIからアップデートを実行すると次のようになります。 ` C:\Users\[USER]\AppData\Local\OpenAI\Codex\bin\958d608b5e0546a5\codex.exe update ` 戻り値: ` Error: Could not detect the Codex installation method. Please update manually: https://developers.openai.com/codex/cli/ ` その後も、codex --version次のような報告が続いています。 ` codex-cli 0.133.0 ` また、Microsoft StoreではCodexアプリのアップデートは提供されていないと報告されています。現在の状況は以下のとおりです。 ` Store app: installed and no Store update available App-bundled CLI: 0.133.0 Doctor: sees 0.135.0 available codex update: cannot detect installation method Sandbox: still blocked by CreateProcessWithLogonW failed: 1326 ` 私は走らなかった： ` sandbox whoami setupStart setup.exe directly config.toml edits sandbox user deletion sandbox user password changes ` 質問：Windowsストア版/MSIX版のインストール時に、アプリにバンドルされているCLIから動作するはずですか？それとも、ストア版/MSIX版のユーザーはストアアプリのアップデートを待つべきでしょうか？codex update また、このsearch command could not be verified`警告は、Windowsサンドボックスの障害に関連する破損したバンドルパッケージを示しているのでしょうか、それとも無関係なのでしょうか？

Update: resolved the local 1326 state.

The key was that reprovision did not happen on app launch alone. It happened on first sandbox use after renaming the full sandbox state.

Steps that worked:

Fully exited Codex.
Renamed the full sandbox state under active CODEX_HOME:

.sandbox
.sandbox-secrets
.sandbox-bin

Ran exactly one sandbox command from elevated PowerShell with the app-bundled CLI and an explicit built-in permissions profile:

codex sandbox windows --permissions-profile ":read-only" --cd "%TEMP%" -- C:\Windows\System32\whoami.exe

HDickenson · 10 days ago

Additional data point (Windows 11, build 10.0.26200; codex-cli 0.139.0; [windows] sandbox = "elevated") that may help characterize the 1326 → 1909 progression:

Parallel codex exec turns an intermittent credential failure into a persistent lockout. Running ~6 codex exec instances concurrently, the per-command logons via CreateProcessWithLogonW fail, and the burst of failed logons trips Windows' account-lockout policy on the CodexSandboxUser. After the first parallel burst, every subsequent run — including single, serial ones — fails with 1909 (account locked out) rather than the initial 1326 (bad username/password). So once it's been hit under concurrency, elevated stays broken until the lockout window clears or the account is reset.

File-edit / patch operations keep working; only sandboxed shell execution fails (git, rg, Get-Content all return the logon error), which silently degrades an agent run to "reviewing blind" — the model proceeds from partial context and can hallucinate findings rather than erroring out.

Workaround that fully resolves it: set [windows] sandbox = "unelevated" in ~/.codex/config.toml. Unelevated uses a restricted token derived from the current user (no dedicated CodexSandboxUser, no CreateProcessWithLogonW), so it avoids both 1326 and 1909. Verified here: after the switch, an identical 6-way parallel run had 0 sandbox failures and executed commands normally.

Suggestions:

Elevated mode shouldn't keep retrying a locked-out sandbox account — the retries amplify the lockout, especially under concurrency.
Surface an actionable error (e.g. "sandbox account locked out — fall back to unelevated?") instead of a raw CreateProcessWithLogonW failed: 1909, and consider auto-falling back to unelevated when the elevated logon path is unavailable.

trithanhsg · 2 days ago

I have the same issue on Windows.

Codex version: [Settings → About Codex]
Windows version: [nhấn Win+R, nhập winver]
Error:
windows sandbox: helper_unknown_error: apply deny-read ACLs

Restarting Codex and reopening the workspace did not fix it.