›_ Codex Issues
Codex Issues / #33288

[Windows Desktop] New local project cannot create first task: "Error creating task: Timeout" across Sol and Terra

Resolved 💬 5 comments Opened Jul 15, 2026 by JustinABG Closed Aug 5, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The Windows ChatGPT/Codex desktop app can continue an existing local-project conversation, but cannot create the first task/conversation for a newly added local project. The failure is model-independent in the current reproduction: it occurs with both GPT-5.6 Sol and GPT-5.6 Terra.

Environment

  • Surface: ChatGPT/Codex desktop app on Windows
  • App build: 26.707.72221 (“Powered by Codex & OWL”, released 2026-07-14)
  • Project target: Local
  • Permission mode: Full access
  • First observed: 2026-07-15, approximately 30 minutes before the initial report
  • Regression: the workflow had previously worked

Actual behavior

For a newly added local project, submitting the first prompt either:

  1. remains on “Thinking” indefinitely; or
  2. fails with a visible toast:
Error creating task
Timeout

After signing out and back in, the pending prompt disappears, indicating that the new task/turn was not persisted successfully.

The failure reproduces with both:

  • GPT-5.6 Sol, Extra High reasoning, Fast mode, using a longer project prompt; and
  • GPT-5.6 Terra, Light reasoning, using this minimal prompt:
Initialize this project conversation. Do not modify any files. Reply only READY.

Control case

In the same app session and network environment, an existing conversation under an older local project works normally with GPT-5.6 Terra Light: it replies and continues editing files.

Therefore, basic authentication, model access, filesystem access, and total network connectivity are functioning. The failing boundary appears to be creation/persistence of a new project task/conversation.

Project checks already performed

The new project was independently verified and re-added:

  • moved to a short ASCII path;
  • Git root resolves to the project directory;
  • repository has a valid initial commit / HEAD;
  • git status is clean;
  • app and computer were restarted;
  • account was signed out and back in.

These checks did not resolve the timeout.

Steps to reproduce

  1. Open ChatGPT/Codex desktop app on Windows.
  2. Add a new local project folder.
  3. Select Local target and Full access.
  4. Choose either GPT-5.6 Terra Light or GPT-5.6 Sol.
  5. Submit a minimal first prompt.
  6. Observe indefinite “Thinking” or Error creating task: Timeout.
  7. Sign out/in; the pending prompt may disappear.
  8. Open an existing project conversation and submit a Terra Light turn; it completes successfully.

Expected behavior

The first project task should be created and persisted, then begin normally. If creation fails, the app should expose the failing endpoint/state and offer a retry that does not leave empty placeholder tasks.

Relationship to existing reports

This may be adjacent to #32762, but the reproduction differs in two important ways:

  • the project/task is created manually in the desktop UI, not by another agent; and
  • the failure also reproduces with Terra Light and appears to occur during task creation/persistence, before any first-turn reasoning or tool execution.

Project prompt contents, local username, and private paths are intentionally omitted.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32861
  • #32578
  • #33046

Powered by Codex Action

JustinABG · 1 month ago

Update after reviewing the duplicate candidates and their diagnostics:

This still reproduces on Windows app version 26.707.72221, and it is model-independent (GPT-5.6 Sol / Extra High / Fast and GPT-5.6 Terra / Light both fail to create the first conversation for a newly added local project).

Several related reports now point to the same thread/start bottleneck:

  • #31762: an unhealthy or slow MCP server delayed MCP initialization until the Desktop request timed out.
  • #32799 (linked from #31762): Windows native traces showed thread/start -> create_thread -> session_init.mcp_manager_init, with remote MCP clients blocked on the OAuth secrets-store lock.
  • #32728: temporarily disabling the user-level config.toml restored new task creation for another user.

We are testing the reversible workaround of disabling all optional MCP servers (or temporarily moving the user-level config.toml) and fully relaunching the app.

Even if local MCP configuration is the trigger, an unavailable optional MCP should not block all new local conversations behind the Desktop timeout. Could a maintainer please confirm:

  1. whether there is a supported way to skip unhealthy optional MCP servers during thread/start;
  2. whether a patched Desktop build increases/removes this blocking startup dependency; and
  3. which redacted Windows logs/trace fields would be most useful if the workaround does not resolve it?
JustinABG · 1 month ago

Impact / severity clarification:

This is a work-stoppage blocker for the affected paid user, not a minor inconvenience. Every attempt to start a new local-project conversation in Codex Desktop fails, so new project work cannot begin at all. Existing conversations are not a viable substitute for starting unrelated projects, and ChatGPT Web does not provide the equivalent local-project/filesystem workflow.

The user is therefore paying for Codex but cannot use the core Desktop workflow needed for current work. Reinstall/reset is also not a reasonable first-line workaround because local task associations/history may be affected, and reinstalling the same build may preserve the triggering user configuration.

Please triage this as a blocker for affected Windows Desktop users and provide either a patched build or a supported one-step workaround.

JustinABG · 1 month ago

Resolved locally — root cause and workaround confirmed

New local-project task creation is working normally again on my Windows machine.

Root cause found

This was not caused by the project path, Git state, filesystem permissions, authentication, or model choice.

Local diagnostics showed that thread/start was blocked while Codex Desktop initialized the globally configured MCP servers. The request crossed the Desktop timeout boundary and the app-server restarted, leaving a half-initialized thread record whose rollout contained only session_meta and task_started, with no completed first user turn.

Two optional MCP entries were definitely unhealthy:

  1. unityMCP pointed to http://127.0.0.1:8080/mcp, where no server was listening, so the connection was refused and retried.
  2. aox pointed to an old hashed Codex-bundled Node runtime path that no longer existed after the Desktop runtime was updated.

There was also additional MCP OAuth-store contention during startup, which reduced the remaining margin before the Desktop timeout.

Fix used

I disabled only the two confirmed broken optional MCP servers in ~/.codex/config.toml:

[mcp_servers.unityMCP]
url = "http://127.0.0.1:8080/mcp"
enabled = false

[mcp_servers.aox]
enabled = false
# existing command/args retained for later repair

I then fully exited Codex/ChatGPT Desktop and relaunched it. I did not delete .codex, the SQLite state databases, rollouts, OAuth data, or existing task history.

Verification

  • Current installation: Codex Desktop 26.707.9981.0, codex-cli 0.144.2.
  • The same newly added local project can now create new tasks normally.
  • Two minimal first-task tests completed successfully and returned READY.
  • Other working MCP integrations remained enabled.

So this issue is resolved for me by disabling the unreachable/stale optional MCP entries and relaunching Desktop.

The underlying product behavior is still worth fixing: an unavailable optional MCP should not block thread/start long enough for Desktop to report Error creating task: Timeout or leave an orphaned/partial task. The result is consistent with the MCP startup/OAuth blocking path discussed in #32578 and addressed by #32825 / #32781.

ZaneJason · 1 month ago

I am experiencing the same issue on Windows.

Environment:

  • ChatGPT Desktop powered by Codex & OWL
  • Version: 26.707.72221
  • ChatGPT Plus
  • Windows 11 x64

Creating the first task in a new local project hangs and eventually reports:
Error creating task: Timeout

Feedback ID:
no-active-thread-019f68c1-7c6a-7e12-88cb-25c6733197ef

Additional symptom:
After clicking Send/Create Task, the ChatGPT Desktop client frequently freezes. In some cases, the entire Windows desktop becomes temporarily unresponsive.

Restarting the app does not resolve the issue, and it occurs across multiple attempts.