Codex App Stuck Loading While Tasks Run? Recover Safely

If the Codex desktop app suddenly returns to its loading screen but active tasks keep running, do not force-quit the whole app first. On macOS, choose File > New Window. A fresh window can reconnect to the live task while the original window remains stuck. Verify the task and its latest output in the new window before you close anything, rerun a command, or reopen browser work.

This is a partial recovery for a failed desktop window, not a universal fix for every startup problem. It applies when the app was already working, one window becomes unusable, and the task backend appears to remain alive.

Confirm This Is the Same Failure

Use the new-window recovery only when the symptoms match:

• The desktop app was open and usable before the failure.

• The primary window is now blank or stuck on the initial loading screen.

• A task was running when the window failed.

• The application itself has not fully exited.

• There is reason to believe the task is still progressing, such as continuing notifications, system activity, or output visible from another connected surface.

Fresh reports show this split between the window and the task process on both macOS and Windows. In the macOS report, File > New Window opened a working window and showed that the in-progress task had continued. The original window did not recover, and its browser tabs were not restored. A Windows report describes the same high-level boundary after a renderer reload: the loading screen remained while background agent work continued.

Do not use this guide for a first-launch sign-in failure, a machine-wide network outage, an IDE extension webview error, or a task that has actually stopped. Those symptoms have different causes.

Why Force Quit Is the Wrong First Test

The desktop app contains more than the visible window. The window can fail while the process managing active tasks remains healthy enough to keep working.

A force quit tests too much at once. It can terminate the stuck window, the task process, and every other active thread. It also removes the evidence that distinguishes a window failure from a full application failure.

Avoid these first-response steps while a task may still be running:

• ending the entire application process tree;

• deleting app caches, rollout files, or conversation data;

• reinstalling the app;

• resending the last instruction from another task;

• reopening a browser flow and repeating a write without checking its state.

The goal is to regain a view into the existing task, not start a second copy of it.

If a second surface says the thread already has an active writer, use the separate one-owner handoff guide instead of forcing two clients to resume it.

Step 1: Open a Second Window on macOS

Leave the stuck window alone and use the macOS menu bar:

1. Select File.

2. Select New Window.

3. Wait for the new window to finish loading.

4. Open the same Codex project and task.

The August 8 macOS report confirms this sequence on desktop build 26.803.41515. Treat it as a recovery observation, not an upstream fix. The original window may remain stuck.

If the menu command is unavailable or the second window also stalls, stop. Do not escalate directly to deleting local state. If you already configured Codex Remote, use that existing connection to check the task. OpenAI documents that supported desktop Codex chats can be accessed from the Remote tab in the ChatGPT mobile app. Do not set up a new remote path in the middle of an uncertain write solely to test this incident.

Step 2: Verify the Task Before You Interact

Finding the task in the new window is not enough. Confirm that it is the same execution and determine whether it is still running.

Check these fields in order:

1. Project or workspace name.

2. Task title and recent conversation context.

3. The last user instruction.

4. The latest visible command, tool result, or assistant output.

5. Current state: running, waiting for approval, completed, failed, or interrupted.

Then choose the matching response:

For repository work, ask the recovered task to run read-only checks before any new edit:

Show the current task state, the latest completed action, git status --short, and the last five commits. Do not modify files, rerun commands, reset Git state, or resume external writes.

This canary helps distinguish a completed change from an instruction that never ran.

Step 3: Treat Browser State as Lost Until Proven Otherwise

The recovered macOS window restored the task but not the original in-app browser tabs or navigation history. That matters when the task was working in an admin console, deployment dashboard, checkout, CMS, or any page with a non-idempotent submit button.

Do not reconstruct the browser session by repeating the last click. First ask:

• Did the provider receive the request?

• Was an item, deployment, post, payment, or job ID returned?

• Can the destination be checked with a read-only status request?

• Would a second submission create a duplicate?

Use the provider's read-only inventory or status surface before repeating a write. If the state cannot be verified, report the uncertainty and wait for a human decision.

Step 4: Preserve Work, Then Restart Normally

Once every active task has reached a safe checkpoint:

1. Save or copy the important result from the recovered window.

2. Confirm repository changes and external job state.

3. Close the unusable window if the app permits it.

4. Finish or pause other active tasks.

5. Quit the desktop app normally.

6. Install an available supported update.

7. Reopen the app and verify the affected task before resuming work.

Do not delete local task data as routine cleanup. A renderer or window failure does not prove that the underlying conversation is corrupt.

If Large Image-Heavy Tasks Trigger the Failure

The exact macOS new-window report did not prove an out-of-memory cause. A separate Windows report did capture renderer replacement after several multi-gigabyte, image-heavy task histories were active, and an older macOS report describes UI freezing while background tasks continued after large chat references.

If your incident follows that pattern, reduce pressure without destroying history:

• wait for active tasks to finish before reopening several large threads;

• create a concise handoff file instead of referencing an entire large conversation;

• use explicit local file paths instead of repeatedly embedding the same screenshots;

• avoid forking a task that already contains extensive inline image history;

• run fewer simultaneous image-heavy or browser-heavy tasks until the regression is resolved.

These are containment steps. They do not establish the root cause of every loading-screen failure.

For sustained process-wide growth without a failed window, use the Codex app high-memory diagnostic to measure the process boundary before changing task data.

Report the Failure Without Exposing Private Data

After recovery, collect enough evidence for a useful bug report:

• desktop app version and operating system build;

• whether the app was already running normally;

• number and type of active tasks;

• whether File > New Window recovered the task;

• whether browser tabs or other window-local state were lost;

• whether the original window recovered;

• approximate failure time and any feedback ID;

• whether a normal restart worked after tasks reached a checkpoint.

Do not upload raw task histories, screenshots, logs, or rollout files without reviewing them. They can contain repository paths, credentials, prompts, customer data, and private browser content.

Reusable Recovery Prompt

After the new window loads, give Codex this bounded request:

The original desktop window is stuck on the loading screen, but this new window can see the task. Verify that this is the same project and task. Report the current task state, latest completed action, pending approval if any, repository status, and any external job IDs already returned. Use read-only checks only. Do not repeat the last instruction, resume a write, delete local state, clear caches, or restart the app.

Success is measurable: the recovered window shows the original task, the latest output is preserved, no instruction runs twice, repository and external state are checked read-only, and the app is restarted only after active work reaches a safe checkpoint.

Start with the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then ask Aident Loadout to check whether the upstream reports have changed:

Check Aident Loadout authentication and Vault status. Discover the current read-only GitHub issue Action, inspect its schema, and preflight requests for openai/codex issues 37550, 37541, and 34555. If the requests are valid and free, execute them. Return only each issue's state, updated time, labels, title, and canonical URL. Do not comment, react, edit, close, or create anything.

Set up Aident Loadout and verify the current recovery evidence.

Sources

• macOS primary window stuck while tasks continue, issue 37550

• Windows renderer reload leaves tasks running, issue 37541

• Large chat references freeze the renderer while tasks continue, issue 34555

• Moving to the new ChatGPT desktop app

• ChatGPT release notes: Codex remote access

Refresh this guide when issues 37550, 37541, or 34555 change state, when OpenAI documents a supported window-only reload, or when a desktop release restores browser state after renderer recovery.