›_ Codex Issues
Codex Issues / #35353

Windows Codex Workspace fails with helper_unknown_error: setup refresh had errors

Open 💬 2 comments Opened Jul 25, 2026 by alexpmtk-afk
💡 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.721.41059

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows 10 Pro; version 10.0.19045; build 19045; x64

What issue are you seeing?

Codex Workspace cannot start the local execution process on Windows.

Actual result:
Every task that tries to run even a minimal PowerShell command fails with:

helper_unknown_error: setup refresh had errors

Expected result:
Codex should start the local execution process and be able to verify or read files in the selected project.

Environment:

  • Codex App version: 26.721.41059
  • Codex Workspace version shown in Settings: 26.723.12215
  • Subscription: ChatGPT Plus
  • OS: Microsoft Windows 10 Pro, version 10.0.19045, build 19045, x64
  • Project is stored on a Google Drive-mounted X: drive
  • Project is marked as trusted
  • Windows sandbox setting is currently restored to "elevated"

Checks already performed:

  • Manual PowerShell starts normally
  • The project directory exists
  • Project files exist and can be read with UTF-8
  • winget works: v1.29.280
  • Restarting Windows did not help
  • Creating a new Codex task/thread did not help
  • Reinstalling Codex Workspace dependencies fails
  • sandbox = "elevated" fails
  • sandbox = "unelevated" also fails
  • No project files were changed by the failed tasks

The failure occurs before Codex can execute a command or verify file existence.

Feedback with current-session logs was already submitted from the app.

Feedback ID:
019f9953-bbc9-7261-8e90-f8dea342eaf0

What steps can reproduce the bug?

Feedback ID: 019f9953-bbc9-7261-8e90-f8dea342eaf0

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35181

Powered by Codex Action

bbingz · 1 month ago

Analysis (community)

Residual analysis for #35353 (helper_unknown_error: setup refresh had errors on Windows Workspace) under docs/contributing.md — invitation-only. No unsolicited PR. Related: #35349 (Setup Incomplete loop) shares the setup binary surface.

Root-cause hypothesis (two OSS levers, one symptom)

Windows sandbox setup has a hard bail on any non-empty refresh error list ("setup refresh had errors"), and untyped/anyhow failures are folded into HelperUnknownError, which wires as the non-actionable string helper_unknown_error. Users therefore see a single opaque code even when logs know more.

Verified at HEAD 4c43465133 under codex-rs/windows-sandbox-rs (Apache OSS path):

1. Refresh hard-fail (AD).
codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs — when refresh_only && !refresh_errors.is_empty():

  • logs setup refresh completed with errors: {refresh_errors:?}
  • then anyhow::bail!("setup refresh had errors")

Partial refresh problems become a full non-zero setup exit. The bail string itself is generic; detail lives in the log line immediately above, not in the typed failure code path unless something re-maps it.

2. Unknown-error fold (AF).
Same file, setup error handling:

let failure = extract_setup_failure(err)
  .map(...)
  .unwrap_or_else(|| SetupFailure::new(SetupErrorCode::HelperUnknownError, err.to_string()));

Any error without a typed SetupFailure becomes HelperUnknownError. Wire map in setup_error.rs: HelperUnknownError => "helper_unknown_error".

So a refresh bail (or other untyped chain) that does not carry a structured SetupFailure collapses to the exact symptom string in this issue title.

3. What is / is not OSS.

  • Error codes, setup binary, refresh spawn/logging (setup.rs “setup refresh: spawning…” region) — OSS.
  • Desktop “Setup Incomplete” chrome may be Electron/closed; treat UX copy as PARTIAL and keep the OSS residual focused on helper codes + refresh policy.

4. Distinct from #17459 / SEC_E_NO_CREDENTIALS-class token issues.
Different subsystem (windows-sandbox setup helper vs credential/token restricted flags).

Ranked fix outline (all OSS):

  1. Map refresh failures to a specific SetupErrorCode (e.g. HelperSetupRefreshFailed) instead of Unknown — include aggregated refresh_errors in SetupErrorReport.message.
  2. Soften policy: do not hard-fail the entire setup on non-critical refresh roots when CLI exec is still viable (or classify critical vs non-critical refresh errors).
  3. Always surface log path + first concrete root error string in the report message (today the useful list is log-only).
  4. Preserve typed extract_setup_failure for known ACL/firewall/user-provision paths so they never fall through to Unknown.

Fail-first tests: (1) non-empty refresh_errors in refresh_only mode → typed code ≠ helper_unknown_error (or message contains the logged errors); (2) known SetupFailure still round-trips its code; (3) untyped anyhow still produces a message that includes err.to_string(), not an empty unknown.

Happy to help draft the error-code + message tests. No unsolicited PR.