Windows Codex Workspace fails with helper_unknown_error: setup refresh had errors

[alexpmtk-afk]

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

[github-actions]

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

• Incident notice — Codex sandbox failure blocking DC-049 #35181

Powered by Codex Action

[bbingz]

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.