When you have been working on Codex for a long time, remote compact may be triggered. At that point, the following error can appear:

Error running remote compact task: {"detail":"Bad Request"}

This indicates that Codex’s context‑compression process did not complete successfully.

However, {"detail":"Bad Request"} is not a specific cause name. From just this display alone, you cannot tell whether the context was too large, there were too many images, the history entries were invalid, or it was a temporary server‑side issue.

What is remote compact?

When conversations with the coding agent become lengthy, it becomes difficult to continuously feed all past exchanges and tool‑execution results to the model in the same format.

Therefore, there is a process that compresses the previous conversation state while preserving the necessary information, allowing the same work to continue. The remote compact shown in Codex is the mechanism for that purpose.

OpenAI’s API documentation also explains that for processes involving long‑running tool executions, compaction is used: the compressed state is passed to the next request to keep the conversation going. The output of compaction is treated as an encrypted, opaque item. (documentation)

It cannot be determined from the displayed error alone whether the internal remote compact in Codex operates with exactly the same requests and limits as the public API’s compaction. Here we clarify the meaning of the errors that actually appear in Codex.

What the “Error running remote compact task” means

Error running remote compact task indicates that the task responsible for executing compaction itself failed.

This is not an error that occurs while generating a normal response; it is a failure in the processing meant to compress the now‑large context and move on to the next turn.

Consequently, the situation can be more troublesome than simply “the current response could not be generated,” because Codex may revert to a state where another compaction is required before it can produce the next response.

What {"detail":"Bad Request"} means

An HTTP 400 Bad Request indicates that the server could not accept the request that was sent.

However, the 400 status code alone does not pinpoint a single reason for the failure. The {"detail":"Bad Request"} displayed on Codex’s screen only tells us that the server returned no further details beyond that short string.

Possible causes include, for example:

  • The overall context is too large
  • The structure or size of the request body was unacceptable
  • Certain history items such as images or files could not be handled by the compaction process
  • Some part of the history is invalid or in an unusable state for the current processing
  • A temporary server‑side glitch or a failure along the network path

Which of these applies cannot be determined from Bad Request alone.

It is risky to jump to the conclusion that a 400 means “the context limit was exceeded” or “images are the cause.” To pinpoint the actual cause, you need to examine the error details, the history immediately preceding the error, whether images or files were present, and whether the issue can be reproduced under the same conditions.

Difference from context_length_exceeded

Errors such as context_length_exceeded explicitly indicate, in the error name, that the context length has exceeded the limit.

In contrast, the following display does not contain that information:

{"detail":"Bad Request"}

Even if it occurs when the context is large, seeing only Bad Request does not mean it is the same as context_length_exceeded.

Conversely, if the conversation has become long enough to reach the point where a compaction is required, the size of the context or history may be a factor. What matters here is distinguishing between a “possibility of relevance” and a “definitive cause” of the error.

Difference from 413 Payload Too Large

413 Payload Too Large is a status indicating that the server rejected the request because the HTTP payload was too large.

This is distinct from the 400 error discussed earlier, both in its display and its meaning.

400 Bad Request
  Request could not be accepted, but the reason is not apparent from the display alone

413 Payload Too Large
  Indicates that the request payload is too large

Even if many images are present, you cannot conclude that a 413 is the cause unless the server actually returns a 413 response. When the 400 error message is brief, an internal size‑related failure may still be reported only as a 400 to the user.

In other words, these three cases should be distinguished:

context_length_exceeded
  More specific error concerning the maximum context length

413 Payload Too Large
  Status regarding the payload size of an HTTP request

400 Bad Request
  A more general message indicating that the request was simply not accepted

When a specific reason is returned and when it is not

Even for Bad Request errors, the amount of detail provided is not always the same.

Depending on the server’s implementation and where the failure occurred, a 400 may be accompanied by additional information indicating problems with input fields or formatting. In such cases, it becomes easier to infer which items need to be corrected.

Conversely, Codex may sometimes display only the following on its screen:

Error running remote compact task: {"detail":"Bad Request"}

In this situation, the error code, the problematic history item, and any size limits are not disclosed. You cannot infer the missing information from the error message.

Why the next turn is also likely to fail

If a single request fails when compaction is not required, a simple retry can often restore normal operation.

However, when the context has already grown large enough to require compaction, the situation tends to fall into a loop like this:

Context remains large
        ↓
Compact is required before proceeding to the next turn
        ↓
Remote compact failed with a Bad Request error
        ↓
Context is not compressed
        ↓
Compact is required again

Because the compaction has not succeeded, a retry will send the same history, the same images, and the same format again. If the issue is a temporary server‑side problem, it may resolve after some time, but if a particular piece of data in the history is consistently problematic, the same error will repeat.

When this happens, you can still continue the work by moving to a new session, but it becomes difficult to maintain the original session’s decisions, goals, and context.

In my case, images were involved

In my situation, this error appeared while I was working on Omoikane development in Codex for an extended period.

That session contained images like the following:

40 PNG images
Image data, approximately 42 MB
Base64 data URL, approximately 56 MB

When I losslessly recompressed the PNG without altering its pixel data, the image itself shrank to about 277 KB. Trying a remote compact with the same session ID in that state succeeded.

From this result, I consider it highly likely that a very large inline PNG was the primary cause of the failure in my case.

However, this is a recovery result specific to my own session.

Bad Request = caused by PNG

It cannot be generalized. Even in sessions without images, the same display can occur due to issues with the history format or temporary server‑side problems.

The investigation details, the image A/B testing, and the recovery steps for the same session ID are summarized in “Recovered from a remote compact failure in a long‑running Codex session that contained many uncompressed PNGs.” (source)

Things to check when the same error occurs

First, determine whether the failure is temporary.

If a single successful attempt occurs after a restart or after waiting and retrying, it may have been a temporary issue on the server side or in the communication path.

If the failure repeats multiple times within the same session, examine the history immediately preceding the error.

  • Are you displaying a large number of images or files?
  • Did you add a large tool output just before the error?
  • Are you repeatedly reproducing the same pre‑compaction state instead of proceeding after compaction?
  • Does a shorter, separate session respond normally?

However, directly modifying Codex’s internal history or database is not a standard recovery method. Altering the format could render the session unreadable.

If you absolutely need to preserve the original session, you must create a full backup before changing any data and perform testing and verification on a copy. Detailed recovery procedures are documented in the example article linked above.

Summary

Error running remote compact task: {"detail":"Bad Request"} indicates that the remote compact operation, which Codex attempted to use to compress a long conversational context, did not complete.

Bad Request is not a specific cause name. Several possibilities remain, such as the size of the context, the size and format of the request, particular images or history entries, or temporary server‑side issues.

It must be distinguished from errors like context_length_exceeded or 413 Payload Too Large, which point to the cause more directly. A 400 error alone does not provide that level of detail.

If compaction fails when it is required, the context remains uncompressed and subsequent compaction attempts will keep repeating, making it difficult to maintain the session.

In my case, after losslessly recompressing 40 PNG files down to about 277 KB, the compact operation succeeded with the same session ID. However, this is just one recovery example and does not definitively conclude that PNG files are the underlying cause of Bad Request.

If you are investigating the meaning of this error, first understand it as a “compact operation failure,” and avoid assuming the cause solely based on Bad Request.