Codex error creating task: timeout — checks before you reset

Find the failure boundary

Keep a local copy of your prompt before closing the app. Then check the task list: a timeout can leave you uncertain whether your first attempt created anything. Avoid sending the same work repeatedly until you know.

What you observe	Next check	What it tells you
New tasks fail, but an existing task responds	Look for startup errors tied to the new task	Existing-task success narrows the problem; it does not verify all startup dependencies.
Both new and existing tasks fail	Compare the exact errors and their timestamps	A task-creation-only explanation may be too narrow.
The task exists but sending another prompt fails	Use the message-submission guide	The failing operation is different.
A task has already begun and stops producing output	Use the stuck-session guide	A slow or compacting turn needs different checks.

This page covers reported local desktop failures. A cloud task needs its own environment checks; editing a local configuration file does not establish that a cloud environment has changed.

Fixes, by branch

If only new tasks fail

1. Record the app build, operating system, project and whether this is the project’s first task.
2. If an existing conversation is idle and suitable for a harmless check, ask it for a short response without file changes. Do not interrupt unrelated work to run this comparison.
3. Try one new task in the affected project with a small request, such as asking for a one-word reply without using tools or changing files. This still uses the model and may consume usage.
4. Note whether the new task is absent, empty, or present but unable to accept a prompt.

If the old conversation works and the new one fails, investigate startup before assuming the account or project is unusable. A Windows report documented that difference. It does not prove every matching symptom has the same cause.

If the startup log names an optional MCP server

Look for a concrete failure associated with that server: a missing launcher, an unreachable local endpoint, or an initialization failure at the same time as task creation. Merely having MCP installed is not evidence against it.

If you have identified a broken optional server that you configured yourself:

1. Locate the configuration used by this desktop environment and back up the file before editing.
2. In that server’s existing table, set enabled = false. Keep its other settings; do not create a second table with the same name.
3. Save other work, fully exit the desktop app, and relaunch it.
4. Repeat the small new-task check in the same project.

The official configuration reference documents disabling a server without removing it. If the comparison changes nothing, restore its previous enabled setting. If task creation recovers, repair that integration before re-enabling it; the test narrowed the trigger, it did not repair the server.

A reporter follow-up describes this working after two broken optional integrations were disabled. That is evidence for a conditional check, not a reason to disable every integration. Required or administrator-managed integrations should be handled by whoever maintains them.

If there is no MCP error to follow

Preserve the exact message and the time it occurred. Compare the result in a new task with the result in an existing task, keeping the project and client unchanged. If you already use the CLI in the same environment, its startup output may offer a useful comparison; a CLI success does not mean the desktop problem is repaired.

After saving work and allowing other tasks to finish, one normal app restart is a reasonable isolation step. If the same failure returns, collect the evidence rather than cycling through reinstallations. Avoid changing the model, project path and permissions together: that makes any apparent recovery hard to explain.

How to tell it worked

The new task should retain your prompt and return a response. An empty task entry is not success. Confirm that your existing conversations remain available and record exactly which change preceded recovery.

If it still fails

Prepare a short report with the app build, OS, local execution mode, whether old tasks work, exact error, timestamp with time zone, and relevant startup messages. Include the result of any single-setting comparison. Remove credentials and private prompt or file contents before sharing logs.

The evidence reviewed here does not justify deleting account tokens, session databases or conversation history. No universal repair or guaranteed timeout duration is established by these reports.