Bug Report

Bug Report

I've been investigating the recurring apply_patch requires a non-empty string input (the patch content) issue when using a BYOK OpenAI-compatible endpoint with the Responses API.

After multiple rounds of testing, I found a pattern that seems reproducible.

Observed behavior

At the beginning of a conversation, apply_patch usually works correctly.

As the conversation becomes longer, apply_patch starts failing consistently with:

apply_patch requires a non-empty string input (the patch content)

Once this happens, it usually continues failing for the rest of that conversation.

However, one of the following immediately restores normal behavior:

Start a new conversation.
Switch the endpoint from the Responses API to the Completions API.

This makes me suspect the issue is related to conversation history handling or tool-call generation rather than the generated patch itself.

Additional observation

While inspecting the Responses API payloads, I noticed something interesting.

The generated apply_patch output does not appear as an isolated tool call.

Instead, it appears to be surrounded by a very large amount of conversational content.

The overall structure looks roughly like this:

Large amount of conversation history...

Large amount of conversation history...

--------------------------------
apply_patch

--------------------------------

Large amount of conversation history...

Large amount of conversation history...

In other words, the generated patch appears to be embedded inside a much larger conversational context, with substantial content both before and after the patch.

As the conversation becomes longer, the surrounding content also grows significantly.

When the conversation is still relatively short, everything works normally.

Once the conversation reaches a certain length, apply_patch begins failing consistently.

Comparison with the Completions API

I repeated the same workflow using the Completions API.

Under the same conditions, apply_patch immediately starts working again without any other changes.

This difference makes me think the issue may be specific to the Responses API conversation management or tool-call handling.

Hypothesis (not confirmed)

I don't know whether this is the root cause, but I wonder whether:

the Responses API implementation is replaying a very large amount (possibly the entire conversation) for each request;
the generated apply_patch content is embedded inside that large conversational context;
as the overall prompt or response becomes larger, the generated tool output may become truncated or more difficult for the tool parser to extract correctly.

I'm not claiming this is definitely what is happening, but the behavior seems highly correlated with conversation length and only appears when using the Responses API.

One observation that may help debugging

One thing that particularly caught my attention is that the generated apply_patch content is not located at the beginning or the end of the model output.

Instead, it appears to be sandwiched between large blocks of conversational content, with a considerable amount of text both before and after the generated patch.

I wonder whether this response structure could make the tool parser more fragile, especially when the overall response becomes very large.

Possible areas to investigate

Could you please check:

whether the Responses API implementation continually replays the full conversation history for each request;
whether long conversations can affect tool-call generation or tool-call parsing;
whether the generated apply_patch payload is ever truncated when the conversation becomes large;
whether the tool parser expects the patch to appear in isolation while the model output actually contains substantial conversational content surrounding it.
Additional note

I don't know whether this behavior is expected, but from a user's perspective it looks like the amount of surrounding conversational content keeps increasing during long sessions.

Since switching to the Completions API immediately resolves the problem without changing anything else, I thought this observation might help narrow down the root cause.

I'd be happy to provide additional logs or payload samples if that would help with debugging.

---
| Field | Value |
| --- | --- |
| App version | 1.1.1 |
| OS | Windows 10.0.26200 |
| Theme | GitHub |
| Path | /chat |
| Tenure | Day 1 |

No files or tests are named. Start by reproducing the long-conversation workflow with a BYOK OpenAI-compatible endpoint using the Responses API, then compare its payload and apply_patch output with the Completions API. Done means the cause of the empty patch content is identified and long Responses API conversations no longer cause apply_patch to fail.

Written by the indexing model from the issue text.