[BUG] write_to_file API keeps on failing and it stuck there

[Rahulk55]

Problem (one or two sentences)

Task was to generate python script by analyzing C header file and when it started to generate python script. It keeps on write_to_file API

Context (who is affected and when)

User is affecting when new file is to be generated using roo code

Reproduction steps

Expected result

File to generated succesfully

Actual result

Date/time: 2026-02-28T10:26:19.865Z Extension version: 3.50.5 Provider: openai (proxy) Model: anthropic::2024-10-22::claude-opus-4-5-latest Roo tried to use write_to_file without value for required parameter 'content'. Retrying...

Variations tried (optional)

No response

App Version

v3.50.5

API Provider (optional)

OpenAI Compatible

Model Used (optional)

Claude opus 4.5 latest

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

Thanks for reporting this. I dug into the code to understand what is happening here.

Root cause analysis:

The error message "Roo tried to use write_to_file without value for required parameter 'content'. Retrying..." is generated when the model (Claude Opus 4.5 in your case, via an OpenAI-compatible proxy) calls write_to_file but does not include the content parameter. This typically happens when the model hits its output token limit while generating a large file -- the response gets truncated before the content field is fully emitted, so the parameter arrives as undefined.

When this happens, Roo increments a consecutiveMistakeCount and sends an error back to the model asking it to retry. There is already a consecutiveMistakeLimit (default: 3) that should eventually trigger a "mistake limit reached" prompt asking for your guidance. However, the retry message sent back to the model just says the parameter was missing -- it does not hint that the file may be too large for a single write, which means the model often just tries the exact same thing again and hits the same token limit.

What I think could be improved:

The error feedback sent to the model when content is missing on write_to_file could be more actionable. For example, it could suggest that the model break the file into smaller pieces, use apply_diff to build it incrementally, or reduce the output size. This would help the model recover instead of retrying the same failing approach.

That said, I want to make sure I understand your situation correctly before proposing a specific fix:

1. Were you generating a large Python file (e.g., hundreds of lines)? That would align with the output-token-limit theory.
2. Did the retries eventually stop (after ~3 attempts), or did it truly loop indefinitely? If it looped more than 3 times, that would suggest the mistake limit is not being hit properly and would be a separate bug.
3. Are you using a specific OpenAI-compatible proxy (e.g., LiteLLM, OpenRouter)? Some proxies truncate tool call arguments differently which could affect parameter parsing.

Please tag @roomote in your response and I will proceed with a fix based on your answers.

[Rahulk55]

@roomote - Thanks for quick response. I am new to roo code.

1. Were you generating a large Python file (e.g., hundreds of lines)? That would align with the output-token-limit theory.

It didn't generate any file at all. I assume it would be large file i.e more 100-200 lines of code

2. Yes, It stopped eventually after 3 attempts.
3. Yes, I am using specific proxy.

I am also using Cline but I never encountered such issue and configuration is same for both extensions

[roomote]

Thanks for the additional details @Rahulk55. The confirmation that it stopped after 3 attempts and that you are using a proxy helps narrow this down. I will explore a potential fix to make the error feedback more actionable so the model can recover gracefully instead of retrying the same failing approach. I'll open a PR to share progress.

[roomote]

Opened PR #11796 with my attempt at addressing this. The fix replaces the generic "missing parameter" error for write_to_file content with an actionable message that explains the likely cause (output token truncation) and suggests recovery strategies (create a smaller file first, use edit_file for targeted changes, split into multiple files). Feedback welcome!

[Rahulk55]

@roomote - Who is going to review and what is usual time to do it?

[roomote]

Hi @Rahulk55 -- thanks for following up. PR #11796 has been opened as a draft and all CI checks are passing. Review is handled by the Roo Code maintainers. Timelines can vary depending on their current workload and priorities, but draft PRs typically get looked at within a few days once marked as ready for review. I have gone ahead and marked it as ready for review to move things along. Appreciate your patience!