[BUG] write_to_file tool, if issue, creates shell scripts (not ideal)

[jordan-carson]

Problem (one or two sentences)

If the write_to_file Native tool fails, instead of using a diff + edit tool or another tool, it instead creates a shell script, asking for approval, to change the contents of a file. This behavior did not occur when XML tooling was used. This does seem problematic for rather large files as listing or reading the contents of the file appear to be larger than the constraints of the write_to_file tool.

Context (who is affected and when)

All developers when trying to write to large files 1500 lines or more.

Reproduction steps

Create a large file, and try to change the contents of that file, whether its a small change or larger changes, ensure the change you are making exists near the middle (beyond 1400 lines or so).

Expected result

write_to_file writes the change without any shell scripting involved.

Actual result

write_to_file writes the change without any shell scripting involved.

Variations tried (optional)

Asked roo to use a different tool than write to file, but the constraints were apparent in these other tools.

App Version

3.50.4

API Provider (optional)

Anthropic

Model Used (optional)

Claude Opus 4.6

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

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

Root cause: When write_to_file fails or seems unsuitable for large files, the model falls back to using execute_command to create shell scripts that modify file contents. This happens because the tool descriptions lack explicit guidance about what to do instead -- and importantly, lack a prohibition against using shell scripts as a file-writing workaround.

Current state:

• The write_to_file tool description (src/core/prompts/tools/native-tools/write_to_file.ts) says "prefer using other editing tools" and "cannot handle large files" but does not name specific alternative tools
• The execute_command tool description (src/core/prompts/tools/native-tools/execute_command.ts) says "Prefer to execute complex CLI commands over creating executable scripts" but does not explicitly prohibit using shell commands to write/modify file contents
• There is no guidance in the rules section (src/core/prompts/sections/rules.ts) about this scenario

Proposed changes:

1. Update write_to_file tool description (src/core/prompts/tools/native-tools/write_to_file.ts):

   • Add explicit guidance naming apply_diff and edit as the preferred alternatives for modifying existing files
   • Add a clear statement: "Never use execute_command to write shell scripts or run shell commands (like sed, echo, cat, printf, tee, etc.) as a workaround for modifying file contents. Always use the dedicated file editing tools instead."

2. Update execute_command tool description (src/core/prompts/tools/native-tools/execute_command.ts):

   • Add a prohibition: "Do not use this tool to modify file contents (e.g., via sed, echo, cat, printf, tee, or shell scripts). Use the dedicated file editing tools (apply_diff, edit, or write_to_file) instead."

3. Update snapshot tests to match the updated descriptions.

This approach addresses the issue at the prompt level, which is where the model gets its behavioral guidance for tool selection. The model resorts to shell scripts because nothing explicitly prevents it -- adding clear instructions in the tool descriptions will steer it toward the correct tools.

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

[jordan-carson]

@roomote i approve this plan. Please go ahead

[roomote-v0]

I've seen your approval and will proceed with the implementation now. I'll open a PR to share progress shortly.

[roomote-v0]

Opened PR #11863 with my attempt at addressing this. Feedback welcome!

#11863

[jordan-carson]

@roomote can you please confirm that the native tools are equipped and don't need any further modifications for a user who's requesting to edit a large file 3500 lines or more. If not do you think a large file edit tool will be worth having?

[roomote-v0]

Hey @jordan-carson, I have seen your comment and have done a thorough review of the native tool implementations. Here is my analysis:

Can the native tools handle large files (3500+ lines)?

Short answer: Yes -- the surgical/diff-based editing tools are already well-equipped for large file edits. There are no hard-coded file size limits in any of these tool implementations.

Tools that handle large files well (surgical edits)

These tools only need the changed portions of a file, not the entire contents, so file size is essentially irrelevant:

Tool	How it works	Large file support
apply_diff	SEARCH/REPLACE blocks with start line numbers	Only sends changed lines + context
edit	Exact old_string -> new_string replacement	Only sends matched text + replacement
edit_file	Like edit but with expected_replacements for multi-occurrence	Same as above
search_replace	Single-occurrence string replacement	Same as above
apply_patch	Codex-style unified patches with context lines	Only sends hunks with ~3 lines of context

The one tool that struggles with large files

write_to_file does not handle large files well. Its description explicitly warns:

"You should prefer using other editing tools over write_to_file when making changes to existing files, since write_to_file is slower and cannot handle large files."

This is because write_to_file requires the model to output the complete file content. For a 3500+ line file, this hits LLM output token limits and the model tends to truncate or use placeholders like // rest of code unchanged, which breaks the file. This is the root cause of the issue described in this bug report -- when write_to_file fails or produces garbage, the resulting content can look like shell scripts or other unintended output.

Is a dedicated large file edit tool needed?

Based on my analysis, no -- the surgical tools (apply_diff, edit, edit_file, search_replace, apply_patch) already handle large files without any size-related limitations. The bottleneck is not in the tooling itself but in:

1. Model tool selection -- whether the model correctly chooses a surgical tool over write_to_file for existing large files
2. Model output token limits -- write_to_file requires full file content which exceeds token limits for large files

The existing tool descriptions already guide models toward surgical tools, but the core issue in this bug report (creating shell scripts) likely stems from the model falling back to write_to_file when it should be using apply_diff or edit instead.

Hope this helps clarify things. Happy to dig deeper if there are specific edge cases you are hitting with large files.