DEV Community

TerminalBlog
TerminalBlog

Posted on • Originally published at terminalblog.com

Your Hermes Agent Is Silently Dropping Files Over 8 KB — write_file Returns Success, Writes Nothing

#career #productivity #linux

You just spent twenty minutes iterating on a Python script with your agent. You see it call write_file, see it confirm "File written successfully," and move on to the next task. Forty minutes later, you realize the file on disk is empty — zero bytes. Every minute of that session is gone.

A P1 bug in Hermes Agent (#62948) reveals that write_file silently fails when content exceeds roughly 8 KB of serialized JSON. The tool reports success. The file lands as an empty 0-byte stub. Your agent has no idea it failed.

The Issue

When Hermes calls write_file with large content, the message sanitizer's streaming JSON repair system encounters truncated or structurally broken arguments. The multi-pass repair — designed to fix control characters, trailing commas, unclosed braces, and similar streaming artifacts — hits its limit on genuinely truncated JSON. Its last-resort fallback replaces the entire tool call with an empty {} object.

The tool receives empty arguments, writes nothing, and returns success. The model sees {} parsed as valid empty arguments and reports "File written successfully." Seven occurrences across three production sessions have been documented — all involving Python scripts over ~8 KB (a travel orchestrator, a parser, a vault health scanner, and test files).

The bug is tracked as P1 (highest priority) and marked as a duplicate of the canonical issue #35151 covering the same root cause in the message sanitizer.

Are You Affected?

Check your sessions for silent write failures:

# Scan for 0-byte files your agent recently wrote
find . -name "*.py" -size 0 -newer "$(date -d '1 day ago' '+%Y-%m-%d')" 2>/dev/null

# Check Hermes agent logs for the telltale warning
grep "Unrepairable tool_call arguments" ~/.hermes/logs/agent.log 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

You are affected if:

  • You use Hermes Agent (any profile: Builder, Infrastructure, Research, Prime)
  • Your agent writes files larger than ~8 KB
  • You have seen "File written successfully" but the file was empty later
  • You are on main as of 2026-07-12 or earlier

The Fix

Short-term workaround: Add a prompt-level instruction telling the agent to use cat with heredoc for files over ~7 KB instead of write_file:

For files larger than 7 KB, use terminal with heredoc syntax:
cat > path/to/file << 'EOF' ...content... EOF
Enter fullscreen mode Exit fullscreen mode

Long-term fix: Watch for the proposed upstream fix that replaces the silent {} fallback with a clear error object the model can detect and retry:

{"error": "write_file arguments could not be parsed — content may exceed the size limit. Use terminal with heredoc for large files."}
Enter fullscreen mode Exit fullscreen mode

Verify writes after the fix lands:

# After each write_file call, check the file has content
test -s path/to/file && echo "OK" || echo "EMPTY — write_file may have failed"
Enter fullscreen mode Exit fullscreen mode

Why It Happened

The root cause lives in agent/message_sanitization.py lines 272–279. When the model emits a write_file call with a large string argument, streaming JSON can arrive truncated — unclosed strings, missing braces. The sanitizer runs multiple repair passes, but genuinely fragmented JSON can not be reconstructed. The last-resort fallback returns "{}" so the session does not crash. The problem: {} is valid empty arguments, so the tool runs with no content and the model thinks nothing is wrong.

The intent of the fallback — prevent a malformed tool call from crashing the entire session — is correct. The failure is returning {} as a successful parse rather than an explicit error that the model can act on.

FAQ

Q: Which files are most at risk?
A: Any file over ~8 KB — typically Python scripts, configuration files, markdown documentation, SQL migrations, and similar text assets that agents commonly generate.

Q: How do I know if my data was lost?
A: Check ~/.hermes/logs/agent.log for "Unrepairable tool_call arguments for write_file". If present, the file was not written. Check the file on disk — if it is 0 bytes, your data is gone and the agent must re-generate it.

Q: Does this affect other tools besides write_file?
A: The sanitizer fallback covers all tool calls, but in practice write_file is the most affected because it commonly receives large string payloads. Other tools with large arguments could also be silently dropped.

Top comments (0)