Infinite configure Sandbox agent loop

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

• #23108

Powered by Codex Action

You can still run Codex via PowerShell and ask Codex to fix the problem form there.

Codex Desktop was stuck at "Set up Agent sandbox to continue" for all projects.

Root cause appears to be a version mismatch:

• Installed Microsoft Store Codex package included resources/codex.exe 0.131.0-alpha.9
• Desktop actually launched user-local bin/codex.exe 0.126.0-alpha.8 from:

C:\Users\calle\AppData\Local\OpenAI\Codex\bin

The Windows sandbox itself worked from CLI:
codex sandbox windows cmd.exe /c "chcp 65001 > nul && dir /b"

After replacing the stale user-local bin files with the newer files from the installed Desktop package resources folder, Desktop was able to continue.

it sounds like you're facing a loop detection issue where the configuration state isn't persisting correctly. log every write to track if the setup is being redundantly triggered. check for identical-write storms or oscillation between two states. implementing a deduplication guard at the write layer could help prevent the repeated setup prompts. also, ensure that the configuration is actually being saved to a durable backend that survives restarts. Use Octopoda OS or ZEP

Hey! Noticed you are dealing with agent loops/token bleeding here.

I was facing the exact same issue with infinite reasoning loops burning API credits, so I built a lightweight algorithmic handbrake in Python to stop it.

It audits the execution and automatically freezes the agent if it hits the same error 3 times in a row. It might save you some headaches and API costs while you debug the core issue.

You can drop it in your workflow: https://github.com/gedeon1972-svg/loop-guardian-skill

Hope it helps you save some tokens! Let me know if it works for your use cas

What usually makes this kind of loop expensive is not the sandbox setup itself, it is the app never graduating from "setup requested" to a durable "setup already satisfied" state.

If the setup flow really succeeded, the next launch should not just re-check "can I configure?" It should check a small receipt for the last successful setup and only rerun if one of the inputs changed: app version, sandbox binary version, expected marker schema, or permissions state.

So the useful circuit breaker here is:

• write a typed success receipt after setup
• hash the inputs that matter
• if the next check sees the same hash, short-circuit to "already configured"
• if the hash changed, show exactly which dependency invalidated the old setup instead of silently restarting the flow

That tends to turn an infinite "set it up again" loop into either a stable no-op or one very obvious invalidation reason. We ended up caring a lot about that style of receipt + stop-reason boundary in MartinLoop, but the bigger fix here is really just making setup state durable and explainable.

I’m reporting a reproduced Windows Codex App sandbox setup/update loop that appears closely related to this issue.

Summary

Codex App repeatedly shows the banner/error:

Unable to update Agent Sandbox / Retry update to continue

However, the Windows sandbox setup log indicates that the sandbox setup itself completed successfully.

Environment

• OS: Windows 10, 10.0.19045.x
• Codex CLI observed version before reset: v0.139.0
• Project directory was on a local drive: D:\Java-p\developer-workbench
• Codex CLI could start normally in the project directory.
• Codex App continued to show the Agent Sandbox update failure.

Relevant symptoms

1. Clicking retry/update in Codex App did not clear the Agent Sandbox error.
2. Renaming/resetting only these directories did not fix it:

• %USERPROFILE%\.codex\.sandbox
• %USERPROFILE%\.codex\.sandbox-bin
• %USERPROFILE%\.codex\.tmp
• %USERPROFILE%\.codex\tmp

1. Codex recreated .sandbox and .sandbox-bin, but .sandbox-bin was empty.
2. Sandbox log showed successful setup, despite the UI still reporting failure.
3. A later App runtime crash also appeared with:

• code=3221225477
• Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

1. Full uninstall/reinstall alone did not fix it, because user-level %USERPROFILE%\.codex state remained.
2. Deleting all Codex user-level residual files and reinstalling resolved the issue.

Sandbox log excerpt

[2026-06-12T06:41:50.980484400+00:00] ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline
[2026-06-12T06:41:51.234845100+00:00] firewall rule configured name=codex_sandbox_offline_block_loopback_udp protocol=17 RemoteAddresses=127.0.0.0/8,::/127 RemotePorts=* LocalUserAuthorizedList=...
[2026-06-12T06:41:51.440113900+00:00] firewall rule configured name=codex_sandbox_offline_block_loopback_tcp protocol=6 RemoteAddresses=127.0.0.0/8,::/127 RemotePorts=* LocalUserAuthorizedList=...
[2026-06-12T06:41:51.664394100+00:00] firewall rule configured name=codex_sandbox_offline_block_loopback_tcp protocol=6 RemoteAddresses=127.0.0.0/8,::/127 RemotePorts=1-65535 LocalUserAuthorizedList=...
[2026-06-12T06:41:51.862318300+00:00] firewall rule configured name=codex_sandbox_offline_block_outbound protocol=256 RemoteAddresses=0.0.0.0-126.255.255.255,128.0.0.0-255.255.255.255,::,::2-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff RemotePorts=* LocalUserAuthorizedList=...
[2026-06-12T06:41:51.876066100+00:00] WFP setup succeeded for CodexSandboxOffline with 12 installed filters
[2026-06-12 14:41:52.827 codex-windows-sandbox-setup.exe] setup binary completed
[2026-06-12T06:41:52.846994100+00:00] read-acl-only mode: applying read ACLs
[2026-06-12T06:41:52.852315800+00:00] read ACL run completed

setup_marker.json

{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "created_at": "2026-06-12T06:41:52.827710+00:00",
  "proxy_ports": [],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

Result / workaround

The issue was resolved only after deleting all Codex user-level residual files under %USERPROFILE%\.codex and then reinstalling Codex. This suggests the App may be stuck on corrupted/stale user-level sandbox/app state even though the sandbox setup binary reports success.

Suggested improvement

Please consider adding a UI action like “Reset local Codex state / Reset Agent Sandbox state” that safely clears stale sandbox/app state without requiring users to manually delete %USERPROFILE%\.codex and lose sessions/configuration.

The newer Windows reproduction makes this look less like a one-off installer failure and more like a missing failure-state contract around sandbox setup.

A useful diagnostic would be to persist one setup attempt record with:

• sandbox version before/after
• update stage reached
• failure fingerprint
• whether anything changed since the prior attempt
• explicit retry_allowed and halt_reason

If the fingerprint and environment state are unchanged, Retry should stop re-running the same path and surface the captured record. That would also make reports from different Windows machines much easier to compare.