Feature request: add a more flexible native file-edit tool for LLM tool-calling workflows

[dhaern]

I’d like to suggest a file-editing capability that sits between the current exact-match replacement endpoint and full shell-based editing.

Right now, for code-editing workflows, the tradeoff seems to be:

• replace_file_content: safe and structured, but very rigid because it depends on exact string matches
• run_command: much more flexible, but also much more opaque and heavier than necessary for routine code edits

This becomes especially noticeable in OWUI native tool-calling workflows, where the model may perform several chained edits in the same conversation. After a file has already been modified a few times, exact-match replacement becomes increasingly fragile because the expected block is no longer identical. When that happens, the model tends to fall back to run_command with shell/Python-based file rewrites, even though a structured file-edit tool would still be preferable.

So from the LLM-tooling perspective, there seems to be a missing middle layer: something more flexible than exact string replacement, but more structured and safer than shell-based rewriting.

A tool like this could be useful:

• contextual patch / hunk-style editing
• line-range based replacement with stronger anchoring
• insert / replace / delete operations that do not require a full exact block match
• anything designed specifically for iterative chained tool calls

I’m not proposing a specific implementation or PR here. The main point is that the current gap pushes models toward run_command for editing more often than ideal, because the existing native replacement primitive is often too strict for multi-step editing sessions.

I think a more flexible structured edit tool would improve both reliability and transparency for code-editing use cases.