write_file (and bash-fallback writes) report success but produce 0-byte files on NFS-mounted volume

Prerequisites

• I searched open issues and discussions and did not find an existing report of this bug.
• This is not a security vulnerability. (Vulnerabilities go to GitHub Security Advisories — see SECURITY.md.)
• I am running the latest code from the dev branch (the default branch you get on clone, where fixes land first) and the bug still reproduces there. Please git pull the latest dev before filing.

Odysseus Revision

3b6c16916233 (2026-09-14)

Install Method

Docker (docker compose up)

Operating System

Linux

Steps to Reproduce

1. Start Odysseus with /vault (an in-container path) bind-mounted to a host directory that is itself an NFS mount (e.g. host mounts a remote NFS export at /mnt/nfs-vault, then docker-compose.yml bind-mounts that host path to /vault inside the container)
2. In Agent mode, set the workspace to a subdirectory under /vault (e.g. /workspace set /vault/some-folder)
3. Ask the model to save content via the write_file tool to a relative filename
4. Tool reports success (exit_code=0 in server logs). If the model retries or falls back to a bash command using cat << EOF > path, that also reports success (exit_code=0)
5. Check the resulting file on the host filesystem — it exists with the correct filename and timestamp, but is 0 bytes

Expected Behaviour

The file should contain the content that was passed to the write_file tool (or written via the bash fallback).

Actual Behaviour

The file is created on disk with the correct filename and timestamp, but is 0 bytes — despite the tool reporting success (exit_code=0). This occurred consistently across two separate save attempts on different days/sessions, and repeated retries within the same session (write_file called 3 times, then a bash fallback once, all against the same target path — all four attempts returned exit_code=0 yet none actually wrote content). This rules out a one-off race condition and suggests a systematic issue with how writes to this mount type are verified/flushed before the tool reports success.

A raw shell redirect via docker compose exec into the same path works correctly every time — this isolates the bug to the tool implementation's write path, not the mount/filesystem itself:

docker compose exec odysseus sh -c 'echo "test content" > /vault/file.md'

This correctly writes and persists content, confirming the NFS mount, bind mount, and underlying filesystem are all functioning normally.

Logs / Screenshots

Environment:
- Docker Compose on Ubuntu 24.04.4 (native host)
- /vault (in-container) is a bind mount of a host directory that is itself an NFS mount, sourced from a separate LAN host
- Model: Cookbook-served gemma-4-12B-it-qat-q4_0-gguf via llama.cpp/Vulkan; also reproduced with llama3.1:8b-instruct via remote Ollama

Server log excerpt (docker compose logs odysseus):

2026-09-17 02:18:04,611 - src.tool_execution - INFO - Tool executed: write_file: /vault/Cookbook/Recipes/whole-orange-olive-oil-cake.md -> exit_code=0
2026-09-17 02:18:27,709 - src.tool_execution - INFO - Tool executed: write_file: /vault/Cookbook/Recipes/whole-orange-olive-oil-cake.md -> exit_code=0
2026-09-17 02:18:41,605 - src.tool_execution - INFO - Tool executed: write_file: /vault/Cookbook/Recipes/whole-orange-olive-oil-cake.md -> exit_code=0
2026-09-17 02:18:56,143 - src.tool_execution - INFO - Tool executed: bash: -> exit_code=0

Resulting file on host:

-rw-r--r-- 1 thaw thaw 0 Sep 17 10:18 whole-orange-olive-oil-cake.md

Model / Backend (if relevant)

Cookbook-served gemma-4-12B-it-qat-q4_0-gguf via llama.cpp/Vulkan; also reproduced with llama3.1:8b-instruct via remote Ollama

Are you willing to submit a fix?

No — I am only filing the report

Additional Information

This is likely specific to NFS-mounted volumes rather than the default local Docker volume most users run — NFS has different write-caching/flush semantics than a local filesystem, which may explain why this hasn't surfaced more widely. Happy to provide further diagnostic info or test a patch if useful.