hermes - 💡(How to fix) Fix [Bug]: write_file tool rejects a complete call when content is sent as file_content (or path as file_path) [5 pull requests]

Bug Description

The standalone write_file tool requires path / content, but skill_manage(action="write_file") uses file_path / file_content for the same operation. Models routinely carry the file_* naming across to the write_file tool, so a fully-formed call like:

{"path": "/tmp/out.txt", "file_content": "hello"}

is rejected with write_file: missing required field 'content' — even though the content is present, just under the wrong key. The error even misdiagnoses it as a dropped-argument bug under context pressure, sending the model into a wasted retry loop.

This is the same class of footgun as #35736 (fixed for skill_manage by #35741), but on the standalone write_file tool (tools/file_tools.py::_handle_write_file), which #35736 / #35741 do not touch.

Steps to Reproduce

1. Have a model call write_file with {"path": "...", "file_content": "..."} (or {"file_path": "...", "content": "..."}).
2. The handler returns {"error": "write_file: missing required field 'content'. ... almost always a dropped-arg bug ..."} and nothing is written.

Observed in practice with a local model (Qwen3-Coder via a custom OpenAI-compatible endpoint): it passed file_content to write_file, was rejected, and burned a turn re-emitting the identical payload.

Expected Behavior

write_file should accept file_path / file_content as aliases for path / content (canonical names winning when both are present, and an empty-string content preserved), so a complete-but-misnamed call succeeds — symmetric with the skill_manage fix in #35741.

Environment

• Hermes: current main
• OS: macOS (Apple Silicon)
• Provider: custom / local (OpenAI-compatible endpoint)