# Codex “Error Submitting Message”: Fix It by the Second Line

> “Error submitting message” is a Codex client banner, not a server code: the line under it names the cause. Check the chat before Retry, then apply that fix.

- URL: https://blog.laozhang.ai/en/posts/codex-error-submitting-message
- Published: 2026-10-16
- Updated: 2026-10-16
- Author: LaoZhang AI Team (https://blog.laozhang.ai/en/about)
- Topic: Troubleshooting
- Tags: Codex, Error Submitting Message, ChatGPT Desktop App, VS Code, Troubleshooting

---
"Error submitting message" is the Codex client telling you that a send failed. It is not an error code from OpenAI's servers. The real cause is the text printed on the line under it, such as `Timeout`, `Queued follow-up changed before dispatch` or `invalid turn/start params: AbsolutePathBuf deserialized without a base path`. Each of those has a different fix, and some have none yet.

What this guide is based on: the client code inside the ChatGPT desktop app 26.1013.31256 (the app that now hosts Codex, formerly the Codex app) and an older Codex IDE extension build, the open-source Codex app-server on GitHub, two weeks of desktop logs from the Mac this guide was written on, 34 issue threads in the openai/codex GitHub repository (May 20 to October 16, 2026), and threads on the OpenAI Developer Community forum. None of the errors below were triggered on purpose to test the fixes. A "fix" here means affected users reported it worked for them. It is not an OpenAI fix unless the text says so. Facts are as of October 16, 2026, and Codex builds change weekly.

Do this first, in order:

1. Copy the text you were trying to send.
2. Look in the chat for your message and any new activity after it. If it is there, do not press Retry.
3. Read the second line under the banner and find it in the table below.
4. If there is no second line, or it just says `Timeout`, wait one to five minutes and send once more.

## What "Error submitting message" means in Codex

In the ChatGPT desktop app the banner is a two-line toast. The first line is the fixed heading "Error submitting message". The second line is the error text the client received when the send failed. The app shows the same heading for a follow-up in a local Codex chat and for a cloud task. The related headings "Error creating task" and "Error creating chat" carry the same second lines. They usually appear when a new chat or task fails to start.

Inside the chat, the failed turn shows that second-line text again as an error item. When the failure came with no text at all, the item falls back to the bare words "Error submitting message". So a banner with nothing under it means the client got no explanation. In the reports, that usually goes with a timeout or a dropped connection to the local app-server.

![Five common second lines under Error submitting message, each mapped to the fix to try first](https://blog.laozhang.ai/posts/en/codex-error-submitting-message/img/second-line-fix-map.webp)

The Codex IDE extension for VS Code and Cursor works the same way. It sends your message to the Codex app-server running on your machine as a `turn/start` request. In an older extension build the client waits 30,000 ms (30 seconds) for an answer. Desktop logs posted in GitHub issues show the same 30-second wait (`mcp_request_timeout method=turn/start … timeoutMs=30000`). Any failure in that step, a timeout or a rejection from the app-server, ends in this banner.

If your app is set to another language, the heading is translated but the second line usually stays in English. In Chinese, for example, the heading reads 提交消息时出错.

## Did my message go through? Check before you press Retry

Sometimes it did. A "failed" send can still reach Codex, so Retry can post the message twice and start the same work twice.

Both outcomes are documented:

- **It went through anyway.** In GitHub issue 44781 one user found that the message had already been saved and its turn had started when the error appeared. In issue 52012 (Windows), messages reached the agent while the app marked them failed, and Retry duplicated both the messages and the responses.
- **It never arrived.** In issues 23644, 35949 and 45019 the failed message never reached `turn/start` or the saved session, so sending it again was safe.

The desktop logs from the Mac this guide was written on show how the first case happens. From October 2 to 16, 2026, the app logged 156 answered `turn/start` requests. Half came back within 63 ms, 95% within about 1.2 seconds, and the slowest took 9 seconds. Two more requests timed out. One of them, at 18:54 UTC on October 3, came from a scheduled automation. The app marked the run as failed, and moments later the app-server's answer arrived anyway, logged as `response_orphaned` because the client had stopped waiting. That is one machine and a small sample, not a general rate.

How to check:

1. Scroll to the bottom of the chat. If your message appears and Codex is working on it, wait.
2. In a local chat, you can also open the newest file in `~/.codex/sessions` and search for a phrase from your message.
3. If the message is nowhere, send it once. If the composer is empty, press the Up arrow in the composer. OpenAI documents this for getting back a prompt after a canceled run; it may not bring back every failed send.

![A failed Codex send that still arrived versus one that never did, followed by copy, check the chat and resend once](https://blog.laozhang.ai/posts/en/codex-error-submitting-message/img/check-before-retry.webp)

## Second line under the banner: what it means and what to try

Find the text under the banner in the left column. Wording can vary slightly between builds.

| Second line (or part of it) | Where it shows up | What to try first |
| --- | --- | --- |
| (nothing), `Timeout`, `App server request expired while queued` | Desktop app, VS Code | Check the chat, wait 1–5 minutes, resend once; then a fresh chat or a full restart |
| `Queued follow-up changed before dispatch` | Current desktop builds, VS Code | Send follow-ups one at a time; wait for the turn, then send fresh |
| `App-server queued follow-up no longer exists` | Desktop and VS Code builds from September 2026 | Switch to another chat and back, or stop the turn and send fresh |
| `AbsolutePathBuf deserialized without a base path` | Windows, tasks created by a dot | Change the permission control from Custom to Approve for me |
| `agent loop died unexpectedly` | Desktop app, Windows and macOS | Quit the app fully and reopen it; continue in another chat |
| `Cannot steer conversation … without an active turn id` | VS Code extension | Run Developer: Restart Extension Host |
| `thread not found` | Desktop app | Restart the app or open the chat in a new window |
| `failed to resolve rollout path … file does not exist` | Windows desktop app | Restore the missing session file; never hand-delete sessions |
| `Unable to determine project root for task`, `a managed thread must retain its original environment` | Codex Web and cloud tasks | No known fix; do not reset the environment |
| `EPERM: operation not permitted, rename` | Windows desktop app | No known fix; check the chat before every resend |
| `ENOENT: no such file or directory, mkdir` | Windows, chats outside a project | Point `projectlessWorkspaceRoot` at a folder that exists |
| `no client found` | Remote SSH, several windows | Close the extra window (unconfirmed) |
| `decoded message length too large` | Desktop app with browser annotations | Send fewer annotations at a time (unconfirmed) |
| `Input exceeds the maximum length of 1048576 characters.` | Any surface | Split the text into smaller messages |

The sections below explain each row, with the conditions that change the fix.

## "Timeout" or no second line: the app-server did not answer in time

This is a stall in the Codex app-server on your machine, not a problem with your message. The client waited about 30 seconds for the app-server to accept the turn and gave up.

The reported causes are local:

- The app had been running for days (about 3.5 days in one report).
- The chat was huge. One rollout file, the saved history of a chat, was 154 MB.
- `~/.codex/logs_2.sqlite` had grown to 1.4–2.2 GB, with several Codex processes using it at once.
- A `codex_chronicle` process left over from an earlier launch was still running.
- Other programs were keeping the CPU busy.
- One old chat was slow while a fresh chat in the same project answered quickly.

The stall often affects more than message sending. In the logs from the Mac this guide was written on, timeouts came in clusters across several app-server requests at once: starting chats, listing chats, resuming chats, loading the model list and reading the config. If the sidebar or the model picker also hangs, the app-server is the bottleneck.

What users reported worked, from least to most disruptive:

1. **Wait and resend.** Sending again after one to five minutes worked for two reporters in issue 27395. Check the chat first, because a late answer may already be on its way.
2. **Start a fresh chat.** If one long chat keeps timing out while a new one works, continue in the new chat with a short summary of where you were. Running context compaction on the old chat did not help the reporter who measured this.
3. **End a stale `codex_chronicle` process (macOS).** List it with `ps -axo pid,lstart,etime,command | grep codex_chronicle`. If its start time is from before your current app launch, end it with `kill` and its PID. One reporter's submit failures went from four to zero after doing this.
4. **Free up the CPU.** Ending unrelated processes that were using a lot of CPU helped one reporter.
5. **Quit the app fully and reopen it.** This helped several reporters, but only for a while.

Two things nobody in these reports advised: deleting `logs_2.sqlite`, and deleting files from `~/.codex/sessions`. On Windows, see [which Codex background processes are safe to end on Windows](https://blog.laozhang.ai/en/posts/codex-windows-background-processes) before ending anything. If the whole desktop app is slow there, the [Codex app slow on Windows CLI vs desktop check](https://blog.laozhang.ai/en/posts/codex-app-slow-cli-vs-desktop) helps you tell whether the app or the machine is the cause.

Restarting did not lose chats in these reports. One reporter wrote that "this was not data loss". That is a report, not a guarantee, so copy unsent text before you quit.

## Queued follow-up errors: wait for the turn, then send fresh

Both queued follow-up errors come from the same place. You send a follow-up while Codex is still working, the app queues it, and the queued item changes or disappears before it is sent. Which text you see depends on your build.

### "App-server queued follow-up no longer exists"

This was the large September 2026 cluster: seven GitHub issues from September 11 to October 1, on Windows, macOS, Linux and the VS Code extension. The usual trigger was clicking Edit on a queued follow-up (or withdrawing it) and then submitting it again. Some users hit it with ordinary follow-ups or after automatic context compaction. Once it happened, later sends in the same chat failed too.

What users confirmed:

- **Switch to another chat and come back**, then send. About eight reporters said this worked. One reporter said the switch cleared the other queued messages in that chat, so copy them first.
- **Let the turn finish, or stop it**, then send the text as a new message. Several reporters confirmed this; one said it worked only sometimes.

Deleting the message and repeatedly restarting or updating the app did not help.

On September 13, 2026, OpenAI's etraut-openai wrote on issue 44781: "The problem is understood. We have a fix in place, and it will be included in the next release." No version number was given, and reports continued on some builds until about September 21. In the ChatGPT desktop app 26.1013.31256, this text no longer exists in the app code. That suggests current builds should not show it. If you still see it, update the app or the extension.

### "Queued follow-up changed before dispatch"

This is the text current builds use for the same kind of race. The desktop app 26.1013.31256 raises it when a queued item changed before it went out, or when the window is not the one driving the chat.

In VS Code (issue 50914, October 4–14, extensions 26.930 and 26.1007), it appeared after sending five to seven follow-ups in quick succession with `chatgpt.followUpQueueMode` set to `queue`. What helped:

- Retrying eventually sent the message for the reporter. Check the chat first, because a replayed send could post twice.
- Interrupt mode avoided the error, but it stops the response that is running.

Restarting, signing in again, clearing the cache and switching to Steer mode did not help. Community patches that modify the installed extension are posted in that issue. They are not from OpenAI, and editing the installed extension is not advisable.

The safe habit: queue one follow-up, wait until it shows as queued, and avoid editing it. If you need to change it, stop the turn and send a fresh message instead.

## "AbsolutePathBuf deserialized without a base path" on Windows dot tasks

This error hits tasks that a dot created on a connected Windows computer, the ones marked "Cloud / Runs on your computer when available". When you reply to such a task from the desktop composer, the app rejects it with `invalid turn/start params: AbsolutePathBuf deserialized without a base path`. It has been the busiest cluster since late September. Issue 50428 alone collected about 30 comments from October 2 to 15, on Windows desktop builds from 26.909 to 26.1007 and from ChatGPT on the web on Windows.

The task history stays readable, and the dot's own messages to the task still go through. Only your direct replies fail.

What reporters confirmed, per task:

1. **Change the permission control below the composer from Custom to Approve for me**, then send. Four to five reporters confirmed it. Approve for me hands approval requests to automatic review, so the task runs with different approval behavior than Custom. One reporter saw later sends to the same task fail again because the setting reverted.
2. **Full Access** also worked for two reporters. Reporters stressed that it widens what Codex can do on your computer, so treat it as a last resort.
3. **Continue in a fresh local task**, or in Codex CLI inside WSL, by handing the work over. One reporter checked every file in the worktree before moving on.

Restarting, rebooting, updating, reinstalling, archiving the task, pressing Retry and creating a fresh task with an explicit Windows folder all failed. As of October 16, 2026, no OpenAI staff member has replied on the three GitHub issues or to the posts about it on X.

## "Agent loop died unexpectedly": restart the app and use another chat

The full text is `failed to start turn: internal error; agent loop died unexpectedly`, or `failed to submit turn input: …` with the same ending. The agent process behind that one chat has stopped, so every send to it fails.

It was reported after:

- Leaving an interactive prompt unanswered and coming back later.
- Hitting a usage limit while approving an action. One Plus user hit the 5-hour limit, and the chat stayed dead after the limit reset. When you are near a limit, [find when your Codex weekly limit resets](https://blog.laozhang.ai/en/posts/openai-codex-usage-limits).
- Asking subagents to close.
- Working in very long-lived chats with many compactions.

Fully quitting and reopening the app brought the chat back for about six reporters, but only for a while. One reporter said an app update fixed it without losing the chat. Other chats kept working, so the quickest way to keep going is a new chat with a summary. In one report the failed messages were never saved to the session, so resending them did not create duplicates. Check the chat anyway before you resend.

## "Cannot steer conversation … without an active turn id" in VS Code

This is a VS Code extension state mix-up. The turn has already finished on the backend, but the extension still shows it as running. Your follow-up then goes in as a steer message for a turn that no longer exists. After that, further sends time out.

In a detailed October 12 report on the OpenAI forum (extension 26.1007.21434 on Ubuntu), the turn was recorded as complete at 08:18:03. The follow-up was rejected 33 seconds later, and three more attempts over the next five minutes timed out. The only thing that restored the chat was running **Developer: Restart Extension Host** from the VS Code Command Palette. It restarts every extension, not just Codex, and it interrupts running Codex sessions.

A less disruptive idea, still untested: open a new Codex agent panel and reopen the conversation from its history. Try that first if you have long jobs running in other chats. The desktop app has a similar message, ending in "because its active turn already ended".

## "Thread not found" and "failed to resolve rollout path"

Both mean the app cannot find the chat it is trying to continue.

### Thread not found

`thread not found` followed by an ID appears when you send right after opening an older chat that the app has not loaded yet. It also appears when the window still holds an out-of-date view of the chat. Restarting the desktop app, or opening the chat in a new window, fixed it in the reports. Forking the chat did not. The latest report is from October 15, 2026, on Windows.

### Failed to resolve rollout path

`failed to resolve rollout path … file does not exist`, often together with "Codex app-server is not available", appeared on Windows after session files had been deleted by hand. Every new chat then failed while the CLI kept working.

One reporter fixed it by recreating the missing session file (a copy of a new chat's file with the ID swapped). They then archived and deleted the chat inside the app. Reinstalling and starting with a fresh `.codex` folder did not help.

The lesson is to remove chats only with Archive and Delete in the app, and never by deleting files in `~/.codex/sessions`. Back up the `.codex` folder before any clean-profile test.

## Codex Web: "Unable to determine project root" and managed environments

These two second lines come from cloud tasks, and as of October 16, 2026 neither has a working workaround.

- `Unable to determine project root for task` (reported September 30 to October 4, Plus users in the browser). Hard refresh, republishing the environment and recreating it did not help. A fresh environment suggested by OpenAI Support hung for 24 minutes for one user.
- `a managed thread must retain its original environment` (October 12 to 16, on desktop, the web and Android). Nothing has worked for reporters so far.

Do not reset or delete the environment to get past these errors before your work is saved somewhere else. Reporters asked others not to for exactly that reason. In one project-root report, the dot could still pass messages into the session. Add your case to the GitHub issues with the steps in the last section.

## Windows file errors: EPERM and the projectless folder

### EPERM on .codex-global-state.json

The full text looks like `EPERM: operation not permitted, rename '…\.codex-global-state.json.tmp-…' -> '…\.codex-global-state.json'`. The log adds "Failed to persist queued submission outcome". Windows refused to let the app replace its state file, and the log line suggests the app then could not record whether your message went out.

That is why this error is the riskiest for duplicates. In issue 52012, messages reached the agent while the app showed them as failed, and Retry duplicated both messages and responses. Recreating the state files, a full restart and stopping Windows Search did not help. Until there is a fix, check the chat before every resend.

### ENOENT and "Unable to resolve projectless chat folder"

`ENOENT: no such file or directory, mkdir '\\?'` in a chat outside a project means the `[desktop] projectlessWorkspaceRoot` setting in `~/.codex/config.toml` points to a folder that no longer exists. The reporter fixed it by pointing the setting at an existing folder and restarting the app.

"Unable to resolve projectless chat folder" over Windows Remote Control is a different bug. Creating the chat on the host computer itself, or from a phone, worked for reporters.

## Rare second lines: no client found, size limits, image URLs

- **`no client found`**: seen with Remote SSH and several windows, when another window took over the chat. Reopening the chat did not help. Closing the secondary window was suggested but not confirmed.
- **`decoded message length too large: found 8255971 bytes, the limit is: 4194304 bytes`**: one user sent many browser annotations at once and went past a 4 MiB message limit. Sending them in smaller batches was suggested but not confirmed.
- **`Input exceeds the maximum length of 1048576 characters.`**: the app-server accepts at most 1,048,576 characters of text in one message. Split the paste into several messages.
- **`remote image URLs are not supported; use an inline data URL instead`**: attach the image itself instead of a link to it.
- **`Server is draining; retry after reconnecting`**: the app-server was shutting down. The message itself says to reconnect and retry; restarting the app reconnects it.

The last three come from the open-source app-server code. They have not shown up in the user reports, and the desktop app may bundle an older app-server.

## Is there a problem with Codex right now, or just this chat?

Most of the errors above stay inside one chat, one task type or one computer. Other chats in the same app kept working in the agent-loop and timeout reports, and the Windows dot-task error hits only replies to those tasks. So test locally before assuming an outage:

- **A new chat with a short prompt works**: the old chat is stuck. Use the section that matches its second line, or carry on in the new chat.
- **New chats fail too, in the same app**: the app-server on your machine is stuck. Quit the app fully and reopen it.
- **Codex fails in the desktop app, the IDE extension and the web**: check OpenAI's status page, then wait.

OpenAI's own troubleshooting page for the ChatGPT desktop app gives similar checks for a stuck chat: see whether Codex is waiting for an approval, run a basic terminal command such as `git status`, and start a new chat with a smaller prompt.

Some lookalike errors are different problems with their own fixes. If the line says the selected model is at capacity, read [Codex "Selected Model Is at Capacity"](https://blog.laozhang.ai/en/posts/codex-selected-model-at-capacity). Retry-limit, 429, 401 and stream disconnects are in [Fix Codex Exceeded Retry Limit 429, 401, and Stream Disconnected](https://blog.laozhang.ai/en/posts/codex-exceeded-retry-limit-429). If the extension never starts, see [Codex Could Not Start in VS Code](https://blog.laozhang.ai/en/posts/codex-could-not-start-vscode). For a model-not-found error on GPT-5.5, see [ChatGPT & Codex GPT-5.5 Model Not Found](https://blog.laozhang.ai/en/posts/codex-gpt-5-5-model-not-found).

## What OpenAI has said, and what to send in a report

As of October 16, 2026, the only OpenAI staff comment on these errors is the September 13 note on issue 44781 about queued follow-ups. OpenAI's [troubleshooting page for the ChatGPT desktop app](https://learn.chatgpt.com/docs/reference/troubleshooting) does not mention "Error submitting message". No changelog or help article names a cause or a fixed build, and the Codex team's accounts on X have not posted about it. That covers OpenAI's public channels. Silence there does not mean OpenAI is unaware of the bugs.

If your case has no fix above, a useful report includes:

1. **The exact second line**, copied as text or in a screenshot.
2. **Versions.** Note the desktop app or extension version. On a Mac, `codex --version` gives the CLI version, and `/Applications/Codex.app/Contents/Resources/codex --version` gives the Codex version bundled with the ChatGPT desktop app. The two can differ.
3. **A feedback ID.** Type `/` in the composer and choose feedback. You can include the current session, and you get a session ID to share with OpenAI.
4. **Logs.** On macOS they are in `~/Library/Logs/com.openai.codex/` by date, and sessions are in `~/.codex/sessions`. Read them before sharing, because they can contain code, paths and secrets.
5. **The matching GitHub issue.** Add your details to the issue for your second line on [the openai/codex GitHub issue tracker](https://github.com/openai/codex/issues): 44781 (queued follow-up), 50428 (AbsolutePathBuf), 27395 (timeouts), 35949 (agent loop died), 50914 (queued follow-up changed), 52012 (EPERM), 54395 (managed environment).

## FAQ

### Will restarting the Codex app lose my chat?

Not in the reports collected here. Users who fully quit and reopened the app after timeouts or a dead agent loop got their chats back, and one said an app update did not lose the "dead" session. Copy any unsent or queued text before you quit, since queued items are not guaranteed to survive.

### Why does Codex say "Error creating task" or "Error creating chat" instead?

Those headings usually appear when a new chat or task fails to start. The second line under them means the same thing as under "Error submitting message", so use the same table.

### Is it safe to delete Codex files to fix "Error submitting message"?

No. Deleting session files by hand caused the rollout-path error on Windows, and nobody in these reports recommended deleting `~/.codex/logs_2.sqlite`, even at 2 GB. Remove chats with Archive and Delete in the app, and back up `.codex` before any clean-profile test.

### Why is Codex not sending messages on my Mac?

On macOS the reports mostly point to app-server timeouts: days of uptime, a very large chat, a huge `logs_2.sqlite` or a leftover `codex_chronicle` process. Start with the timeout section above. If the second line says something else, that line decides the fix.

## Sources

External pages this guide links to, in the order they appear. Last updated 2026-10-16.

- [troubleshooting page for the ChatGPT desktop app](https://learn.chatgpt.com/docs/reference/troubleshooting) (learn.chatgpt.com)
- [the openai/codex GitHub issue tracker](https://github.com/openai/codex/issues) (github.com)