Codex Desktop 26.616.71553 on Windows: Unsupported content type, queue/task mixing, disappearing sessions, broken model picker, unstable sidebar

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop App: Version 26.616.71553 Released: Jun 23, 2026

What subscription do you have?

ChatGPT Pro / highest Pro plan

What platform is your computer?

Windows Microsoft Windows NT 10.0.26200.0 x64 Device: ASUS Zenbook 14 OLED UX3405 CPU: Intel Core Ultra 9 185H RAM: 32 GB

What issue are you seeing?

What version of the Codex App are you using?

Codex Desktop App: Version 26.616.71553
Released: Jun 23, 2026

Previous build note:
The most stable recent build for me was the one released on Saturday. After that, the newer builds started introducing serious regressions. It would be very helpful to have a Beta / Stable channel or a way to roll back to a known-good build, because current updates are repeatedly breaking production work.

What subscription do you have?

ChatGPT Pro / highest Pro plan.

What platform is your computer?

Windows
Microsoft Windows NT 10.0.26200.0 x64
Device: ASUS Zenbook 14 OLED UX3405
CPU: Intel Core Ultra 9 185H
RAM: 32 GB

The computer and Windows environment have not changed compared with the previous reports.

Which model were you using?

Mostly GPT-5.5 / GPT-5.5 XHigh / High / Fast depending on the available selector.

Important: in some old chats/sessions, the model selector is now unavailable, so I cannot always select or verify the intended model.

What issue are you seeing?

Codex Desktop 26.616.71553 introduced several serious regressions on Windows.

This is a production-blocking issue for a paid Pro user. I use Codex with long queues, many tasks, and project sessions. These regressions make the app unreliable and unsafe for real work.

1. Frequent {"detail":"Unsupported content type"} failures

After updating to Codex Desktop 26.616.71553, I started frequently seeing:

{"detail":"Unsupported content type"}

This did not happen before.

There are two patterns:

• Sometimes I paste or submit a command/task and it immediately fails with {"detail":"Unsupported content type"}.
• Sometimes the task starts normally, works for around 10 minutes, and then stops with {"detail":"Unsupported content type"}.

This is especially dangerous with long queues. If there are 20–50 queued tasks, Codex may fail a large portion of them with Unsupported content type, then continue to the next queued item. A user may not notice that 30–50% of the queue silently failed.

2. Queue/task context mixing

There is now a serious queue regression.

Sometimes the queue starts the next queued task, but Codex continues working on the previous task or applies the previous task context to the next queued item.

This is very harmful for real work because the task shown as active and the task being executed may not match.

Expected:
When the queue starts task N+1, Codex should execute task N+1 only.

Actual:
Codex sometimes appears to start the next queued task but continues the previous one or mixes context between queued tasks.

This can corrupt work, waste usage limits, and make the queue unreliable.

3. Left sidebar flickering for 1–3 minutes on startup

After launching Codex Desktop, the left sidebar/menu now flickers for 1–3 minutes.

The sidebar repeatedly appears and disappears.

A very short flicker used to happen before for maybe a millisecond, but now this is a visible and prolonged UI artifact. It looks like the app is repeatedly mounting/unmounting or rehydrating project/session state.

This makes the app feel unstable immediately after startup.

4. Chats/sessions created after the new build disappear automatically

The latest patch introduced automatic disappearing of chats/sessions inside projects.

This affects sessions created today after the new build was installed.

Interestingly, sessions created earlier, for example around Saturday Jun 20, appear to be less affected or not affected in the same way.

This suggests a regression in the current build’s session/project persistence, indexing, or hydration logic.

5. User has only around 5 seconds to pin a chat before it disappears

There is now a very painful workaround:

• Restart Codex Desktop.
• Immediately open the chat.
• You have around 5 seconds to pin it.
• If you do not pin it in time, the chat disappears again.
• Then you need to restart the app or even reboot the computer and try again.

This is not usable behavior.

Expected:
Chats/sessions should remain visible and accessible in their projects.

Actual:
Some newly created chats/sessions disappear unless they are pinned immediately during a short startup window.

6. Model behavior / quality became inconsistent and significantly worse

Model behavior has also become unstable.

Earlier in the month, GPT-5.5 / XHigh in Codex was much more useful and reliable.

Recently, the behavior became inconsistent:

• some requests still look reasonable;
• some requests behave like a much weaker model;
• the model often misses instructions;
• the model sometimes produces shallow or incorrect work;
• quality feels far below what GPT-5.5/XHigh provided earlier in the month.

This is especially frustrating because I am a loyal Pro user and rely on Codex for production work.

I understand that model behavior can be separate from the desktop app bugs, but from the user side the result is the same: Codex became unreliable.

What steps can reproduce the bug?

Reproduction path A: Unsupported content type

1. Open Codex Desktop 26.616.71553 on Windows.
2. Open an existing project.
3. Add multiple tasks to the queue.
4. Submit normal text commands/tasks.
5. Observe that some tasks immediately fail with:

{"detail":"Unsupported content type"}

1. In other cases, let a task run for around 10 minutes.
2. Observe that it stops with the same error:

{"detail":"Unsupported content type"}

1. The queue then continues to the next task, making the failure easy to miss.

Reproduction path B: queue/task context mixing

1. Open a project with a task queue.
2. Add several queued tasks.
3. Let the queue auto-continue.
4. Observe that when the next task starts, Codex may still act on the previous task or previous context.
5. The visible active queue item and the actual work being performed can diverge.

Reproduction path C: sidebar flicker / project hydration instability

1. Launch Codex Desktop 26.616.71553.
2. Watch the left sidebar/project menu.
3. For 1–3 minutes the sidebar repeatedly appears and disappears.
4. This did not happen at this duration/severity in earlier builds.

Reproduction path D: disappearing new chats/sessions

1. Open Codex Desktop 26.616.71553.
2. Create a new chat/session inside a project.
3. Close or restart Codex.
4. Reopen Codex.
5. The newly created chat/session may disappear from the project.
6. If you restart and quickly open/pin the chat within around 5 seconds, it may remain accessible.
7. If you miss that short window, it disappears again.

What is the expected behavior?

• Normal text commands should not fail with {"detail":"Unsupported content type"}.
• Long-running tasks should not stop after several minutes with Unsupported content type.
• Queue execution should be strictly aligned with the visible queued task.
• Queued tasks should not inherit or continue the previous task’s context unless explicitly requested.
• The left sidebar should not flicker for 1–3 minutes after startup.
• Newly created chats/sessions should not disappear from projects.
• Users should not need to restart Codex and pin a chat within 5 seconds to keep it visible.
• The model selector should remain available in old and new chats.
• GPT-5.5 / XHigh behavior should be consistent and should not randomly degrade to much weaker behavior.

What is the actual behavior?

• Many tasks fail with {"detail":"Unsupported content type"}.
• Some tasks fail immediately.
• Some tasks run for about 10 minutes and then fail with the same error.
• Queue continuation can hide these failures.
• Queue tasks can get mixed with previous task context.
• Sidebar/project menu flickers for 1–3 minutes on startup.
• New sessions/chats created under the current build can disappear.
• The user has a tiny window of around 5 seconds after restart to open and pin a chat before it disappears.
• Model selector is unavailable in some old chats.
• Model quality and instruction following became inconsistent and significantly worse.

Impact

This is production-blocking.

I am a ChatGPT Pro user on the highest plan and have been unable to use Codex reliably for serious work.

The current app behavior can silently lose work, corrupt queues, waste usage limits, and make long task queues unsafe.

This is especially damaging for users who rely on Codex as a working environment rather than a demo tool.

Regression information

This appears to be a regression introduced after the more stable Saturday build.

The Saturday build was significantly more stable for me. It would be reasonable to provide a Beta / Stable channel, or an official rollback option, so users are not forced into builds that break their work.

Request

Please escalate this to the Codex Desktop Windows team.

Please investigate:

1. Unsupported content type errors in normal queued text tasks.
2. Queue/task context mixing.
3. Sidebar flickering / project hydration instability.
4. New chat/session disappearance after restart.
5. The 5-second window where a chat must be pinned before disappearing.
6. Model selector unavailable in old chats.
7. Inconsistent GPT-5.5 / XHigh behavior in Codex.
8. Whether this is related to local project/session index, model catalog, app-server state, or queue persistence.
9. Whether a rollback / beta / stable channel can be provided.

Please also provide guidance on:

• which logs are safe to share;
• whether logs may include prompts, code, screenshots, project data, secrets, or private information;
• how to export or recover disappearing sessions;
• whether there is a safe local reindex/rebuild procedure for Codex Desktop project/session state.

Additional information

This follows previous instability in Codex Desktop on Windows, including severe memory growth and inaccessible project/session history in earlier builds.

The machine and Windows environment did not change. The regressions appeared after Codex Desktop updates.

I can provide screenshots, exact timestamps, logs, and screen recordings if needed.

Additional high-severity update: {"detail":"Unsupported content type"} kills running tasks and makes queues unsafe

I need to emphasize that {"detail":"Unsupported content type"} is not a minor error message.

It is a severe queue-breaking bug.

Today, at least 20 tasks were affected by {"detail":"Unsupported content type"}.

The failures happened in multiple stages:

1. At task start

• The task starts and immediately fails with {"detail":"Unsupported content type"}.

1. In the middle of a task

• The task works for several minutes, then suddenly stops with {"detail":"Unsupported content type"}.

1. At the final stage of a task

• The task appears to be close to completion, then fails with {"detail":"Unsupported content type"} and the useful work is lost or left unfinished.

This is especially damaging because Codex currently has no reliable “stop queue” / “pause queue” / “cancel all queued tasks” control.

So when this error starts happening inside a long queue, Codex continues to the next queued task automatically.

If a user has 20–50 queued tasks, like I often do, the app can silently burn through the queue while many tasks fail with {"detail":"Unsupported content type"}.

This creates several serious problems:

• running work is killed;
• partially completed tasks are lost or left in an unknown state;
• queued tasks continue after failure;
• the user may not notice the failures until many tasks are already damaged;
• usage limits are wasted;
• work output becomes unreliable;
• it is not safe to leave Codex running unattended;
• a long queue becomes dangerous instead of useful.

This is a production-blocking issue for anyone using Codex queues seriously.

Expected behavior:

• {"detail":"Unsupported content type"} should not happen for normal text tasks.
• If this error happens, Codex should stop the queue automatically or ask the user what to do.
• The user should have a clear “Pause queue” / “Stop queue” / “Cancel remaining queued tasks” control.
• The failing task should be marked clearly as failed.
• Codex should not automatically continue running the next queued tasks after repeated unsupported-content failures.
• Codex should preserve the failed task state and make it easy to retry.

Actual behavior:

• {"detail":"Unsupported content type"} can happen at the start, middle, or final stage of a task.
• It kills or interrupts running tasks.
• Codex continues with the queue.
• There is no reliable stop-queue control.
• Many queued tasks can be affected before the user notices.

Impact today:

• At least 20 tasks were affected by {"detail":"Unsupported content type"}.
• The failures happened both at task start and during active execution.
• Some tasks failed after substantial work had already been done.
• This made the queue unsafe to use.

Please prioritize this as a high-severity queue/runtime bug, not just a cosmetic error message.

<img width="1359" height="603" alt="Image" src="https://github.com/user-attachments/assets/136acf5f-4661-4bfc-b603-edd10acb7648" />

What steps can reproduce the bug?

Update after Codex Desktop 26.616.71553, Released Jun 23, 2026:

The new build introduced several serious regressions on Windows:

1. Frequent {"detail":"Unsupported content type"} failures.

• Sometimes immediately after submitting a task.
• Sometimes after ~10 minutes of work.
• With long queues, many failed tasks can be missed because Codex continues to the next queued item.

1. Queue/task context mixing.

• The queue starts the next task, but Codex continues working on the previous task or previous context.

1. Left sidebar/project menu flickers for 1–3 minutes after startup.

• Previously this was only a very short artifact; now it is prolonged and disruptive.

1. New chats/sessions created after this build disappear from projects.

• Sessions from the earlier Saturday build appear less affected.

1. The only workaround is to restart Codex and pin the chat within ~5 seconds before it disappears.

• If I miss the short window, I need to restart again.

1. Model selector is unavailable in some old chats/sessions.

1. GPT-5.5 / XHigh behavior became much less consistent and significantly worse than earlier this month.

This is production-blocking for a paid ChatGPT Pro user.

Please escalate to the Codex Desktop Windows team and investigate session/project persistence, queue persistence, local index/state hydration, model catalog, and the Unsupported content type failures.

What is the expected behavior?

_No response_

Additional information

_No response_