[BUG] Intermittent failure: write_to_file called without required content parameter

[rockey5520]

Problem (one or two sentences)

Roo intermittently fails during execution by attempting to call write_to_file without the required content parameter, triggering retries and unstable behavior.

Context (who is affected and when)

This is affecting a large engineering team (~150 engineers) using Roo Code in daily workflows.
The issue appears during normal coding tasks and happens intermittently, making it hard to predict but noticeable at scale.

Reproduction steps

Environment/setup
VS Code: latest version
Roo Code extension: v3.51.1
Provider: Vertex
Model: claude-sonnet-4-6
Exact actions
Start a normal Roo Code task (e.g., generating or modifying code)
Let the agent proceed with file operations
Observed behavior

At some point during execution, Roo logs:

Roo tried to use write_to_file without value for required parameter 'content'. Retrying...
Task may retry or behave inconsistently afterward

Expected result

write_to_file should always be invoked with all required parameters, including content, and execute reliably without retries.

Actual result

Roo attempts to call write_to_file without the required content parameter, causing retries and intermittent instability.

Variations tried (optional)

Occurs across multiple users and machines
Seen with the same provider (Vertex) and model (claude-sonnet-4-6)
Not tied to a specific prompt or repository (so far)
Intermittent → no deterministic repro yet

App Version

v3.51.1

API Provider (optional)

Google Vertex AI

Model Used (optional)

claude-sonnet-4-6

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

Date/time: 2026-04-08T11:57:55.852Z
Extension version: 3.51.1
Provider: vertex
Model: claude-sonnet-4-6

Roo tried to use write_to_file without value for required parameter 'content'. Retrying...

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause

The bug is in NativeToolCallParser.parseToolCall(). When the model sends a write_to_file call with a missing content parameter, the finalization logic requires both path AND content to be present before setting nativeArgs:

case "write_to_file":
    if (args.path !== undefined && args.content !== undefined) {
        nativeArgs = { path: args.path, content: args.content }
    }
    break

When content is missing, nativeArgs stays undefined, which triggers a throw at line 999-1004 ("Invalid arguments for tool 'write_to_file'"). The parseToolCall method then catches this and returns null.

This means the downstream code in WriteToFileTool.execute() (which has user-friendly per-parameter validation producing "Roo tried to use write_to_file without value for required parameter 'content'. Retrying...") is never reached.

Instead, one of two things happens:

1. Non-streaming path: The tool call is silently dropped (null return)
2. Streaming path: The fallback in Task.ts:2963-2980 marks the partial ToolUse as complete but without nativeArgs, causing BaseTool.handle() to throw a generic "Tool call is missing native arguments" error

Neither path produces the clean retry behavior that WriteToFileTool.execute() is designed to provide.

Proposed Fix

File: src/core/assistant-message/NativeToolCallParser.ts

Change the write_to_file case in parseToolCall() (line 905-912) to use an OR condition instead of AND, matching the pattern already used for partial args (line 467-474):

case "write_to_file":
    if (args.path !== undefined || args.content !== undefined) {
        nativeArgs = {
            path: args.path,
            content: args.content,
        } as NativeArgsFor<TName>
    }
    break

This allows nativeArgs to be set even when one parameter is missing, so that WriteToFileTool.execute() can properly detect the missing param and produce the user-friendly "Retrying..." error message that gets sent back to the model.

The same pattern issue exists for several other tools (apply_diff, generate_image, search_files, switch_mode, ask_followup_question, new_task) but since the issue only reports write_to_file, I'll scope the fix there. If desired, I can apply the same fix to the other tools in the same PR.

Test Plan

• Add a test in NativeToolCallParser.spec.ts for write_to_file with missing content
• Add a test in writeToFileTool.spec.ts to verify the retry error flows correctly
• Run existing test suites to ensure no regressions

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[rockey5520]

@roomote can you check if others reported the same issue, if they are closed and how they resolved this. I wonder if this is something we need to change any Roo settings or GCP vertex AI setting before changing Roo code

[roomote-v0]

Hey @roomote-agent, I looked into whether others have reported the same "missing required parameter" issue and whether there are any Roo settings or GCP Vertex AI settings that could help. Here is what I found:

Similar issues reported by others

This is not unique to your setup. Several other users have reported the same pattern across different providers and models:

• [BUG] write_to_file API keeps on failing and it stuck there #11795 (Open) - write_to_file without content, using OpenAI-compatible proxy + Claude Opus 4.5. Same exact error message. The root cause analysis there pointed to output token truncation -- the model response gets cut off before the content field is fully emitted, so it arrives as undefined.
• [BUG] write_to_file tool, issue with large file and context cutoff by LLM responses #11861 (Open) - write_to_file failing on large files (1500+ lines) with Anthropic direct + Claude Opus 4.6. Same underlying issue. A Cline PR (fix: smarter retry for write_to_file missing content parameter cline/cline#9276) was referenced that adds progressive tiered error messages to break the retry loop, and PR fix: progressive error for write_to_file missing content to break retry loops #11909 was opened to adapt that approach for Roo.
• [BUG] Roo tried to use list_files without value for required parameter 'path'. Retrying... #10150 (Closed) - Same pattern but with list_files missing path, using Qwen3-Coder. Closed with a suggestion to retest on newer versions.
• Getting a lot of "Roo tried to use apply_diff without value for required parameter 'path'." with qwen3-coder #7406 (Closed) - apply_diff and write_to_file missing path, using Qwen3-Coder via LM Studio. Closed as a model-side issue.
• [BUG] Qwen3-Coder-480B-A35B-Instruct tool-calling failure: Missing value for required parameter 'args' #10464 (Closed) - Missing args parameter with Qwen3-Coder. Different root cause (XML format mismatch).

None of these closed issues have a definitive resolution merged into Roo Code yet. PRs #11796, #11847, and #11909 were opened to improve error handling but appear to still be in review.

Is this a settings issue or a code issue?

Short answer: It is primarily a code-side issue in Roo, not a Vertex AI or Roo settings problem.

The root cause is in NativeToolCallParser.parseToolCall(). When the model's response gets truncated (which happens intermittently when generating large file content), the content parameter arrives as undefined. The finalization logic at line 905-906 requires both path AND content to be present:

case "write_to_file":
    if (args.path !== undefined && args.content !== undefined) {
        nativeArgs = { path: args.path, content: args.content }
    }

When content is missing, nativeArgs stays undefined, and the tool call either gets silently dropped or throws a generic error -- bypassing the user-friendly retry logic in WriteToFileTool.execute() that is specifically designed to handle this case.

Interestingly, the streaming/partial version of this same parser (line 467-468) already uses an OR condition (partialArgs.path || partialArgs.content), which correctly allows partial args through. The finalization path just needs the same treatment.

What you can try in the meantime

Since this is intermittent and tied to output token limits, there are no Roo settings or GCP Vertex AI settings that will fully prevent it. However, you can reduce the frequency by:

1. Prompt the model to write smaller files - break large file writes into multiple smaller operations
2. Use edit or apply_diff instead of write_to_file for modifications to existing files (these tools only send the changed portions, so they are much less likely to hit token limits)
3. Increase maxTokens in your Vertex AI configuration if it is set below the model maximum -- this gives the model more room to complete large responses

The real fix needs to happen in Roo Code itself, and the plan outlined in the first comment on this issue (changing the AND to OR in NativeToolCallParser.parseToolCall()) looks correct to me.

[rockey5520]

@roomote fix this then on Roocode and help prioritise with your engineering team and this is affecting 150 engineers at our workplace frequently

[roomote-v0]

Hey @rockey5520, I've seen your comment and understand the urgency -- this affecting 150 engineers is significant. I'm going to implement the fix now and open a PR. The root cause has been identified in NativeToolCallParser.parseToolCall() where it requires both path AND content to be present before forwarding to the retry-capable WriteToFileTool.execute(). When the model's response gets truncated, content arrives as undefined and the tool call gets silently dropped instead of producing the clean retry. I'll have a PR up shortly.

[roomote-v0]

Opened PR #12080 with my attempt at addressing this. The fix aligns the finalization path in NativeToolCallParser.parseToolCall() with the streaming path by using OR conditions instead of AND, so that partially-constructed args (e.g., write_to_file with missing content due to response truncation) flow through to the tool's own retry logic instead of being silently dropped. Feedback welcome!

[rockey5520]

@roomote what are next steps here to get this code released?

[roomote-v0]

Hey @rockey5520, I have seen your comment. Here is where things stand:

PR #12080 has been open since earlier today with the fix. All CI checks (unit tests on Ubuntu and Windows, compilation, CodeQL, knip, translations) have passed and the PR is marked as mergeable. It currently has no reviews.

Next steps from here are:

1. Maintainer review -- a Roo Code maintainer needs to review and approve the PR
2. Merge -- once approved, the PR gets merged into main
3. Release -- the fix would ship in the next Roo Code extension release after merge

I do not have the ability to merge or cut releases, so this is now waiting on the maintainer team. If this is urgent for your 150-engineer team, tagging a maintainer directly on the PR may help move things along.