Bug Report: Hermes File Operations Are Inconsistent and Unpredictable Summary

The Hermes agent's file operations produce inconsistent and apparently random results. The same command run against the same path can succeed or fail with no observable difference in inputs. Some writes appear in the Files panel, others don't. Some folders are visible, others created the same way are not. Deletes seem to work reliably; creates do not. This nondeterminism makes the agent unusable for any workflow that depends on producing persistent, user-visible artifacts.

Core Problem: Inconsistency

This is not a "writes don't work" bug. CRUD operations sometimes work. The problem is that:

The same mkdir/write_file/touch command against the same path produces different visible outcomes on different invocations within the same session. Some agent-created folders appear in the Files panel; others created identically do not. Deletes have been observed to succeed reliably when given correct paths. Creates have been observed to succeed at the filesystem level (visible to the agent's terminal) but fail to render in the UI, even after hard browser reload and confirmation via the backend API. There is no pattern the user or agent can detect to predict which operations will be visible and which will not. Concrete examples from a single session:

Agent created /home/workspace/workspace/SDLC/01-planning/requirements via mkdir -p. Folder visible to agent terminal, returned by API, NOT visible in Files panel after refresh. Agent created /home/workspace/workspace/UITEST_12345 via docker exec into the container. NOT visible in Files panel. User created a folder ZZZTEST via the UI's "+" button. Visible immediately. Agent then found it at /home/workspace/workspace/ZZZTEST (the same path the failed creates used). Agent created EDLC subfolders 01-06 at the same path. Eventually visible in Files panel — but other creates against the same path in the same session were not. Delete operations against confirmed-visible files have worked reliably the same session. Why Inconsistency Is Critical

A predictable failure is workable. The user can route around it. Silent nondeterminism is not workable:

The user cannot trust any reported success. Verifying every operation manually defeats the purpose of using an agent. The agent itself has no reliable way to detect which of its operations actually became visible. Sessions become troubleshooting sessions instead of productive ones. Impact

The agent cannot reliably deliver artifacts (documents, folder structures, reports) to the user. No download button + no rich viewers in the Files panel + inconsistent writes = users cannot retrieve or view what the agent produces. Entire sessions can be consumed without producing a single usable deliverable. The core value proposition of an artifact-producing agent is broken. Environment

Hostinger VPS (Ubuntu 24.04 LTS), srv1660382 Hermes running in Docker container, agent terminal executes as root Hermes UI process runs as user hermes (uid 10000) workspace_context tag reports: path="/home/workspace/workspace" Diagnostic Findings

The following were confirmed during a debugging session and rule out the obvious "wrong path" or "permission" explanations:

Path is correct. A folder created via the UI's "+" button (ZZZTEST) landed at /home/workspace/workspace/ZZZTEST — the path workspace_context reports. Agent writes target the same path. Filesystem is correct. ls -la from inside the container confirms agent-created folders exist with correct names, ownership, and permissions. Ownership is correct. After chown -R 10000:10000, agent-created folders match UI-created folders byte-for-byte in metadata. API returns correct data. A direct HTTP call to the Hermes Files API returns the full nested folder tree exactly as it exists on disk, including agent-created entries that the UI does not display. UI still does not render some entries. Even with 1–4 correct, the Files panel inconsistently displays agent-created folders. Phase subfolders, cross-cutting folders (governance, security, compliance), and test marker folders all failed to appear despite being on disk and returned by the API. UI icon mismatch. A folder created via the UI's "+" button (ZZZTEST) displays with a file/note icon, not a folder icon — indicating additional rendering bugs. Root Cause Hypothesis

The most likely candidates, in priority order:

Frontend rendering bug: the Files panel does not consistently display entries returned by the backend API. Some race condition, caching layer, or filtering logic drops entries silently and nondeterministically. UI state management bug: the panel caches its view of the tree and does not invalidate when the underlying filesystem changes outside its own actions, but invalidation happens inconsistently. Possibly multiple processes or workers serving the Files API and one of them is reading from a stale snapshot. Filesystem and API correctness are confirmed. The bug is upstream of disk and downstream of the API — i.e. in the UI itself.

Compounding UI Gaps

These worsen the impact and should be addressed alongside the rendering bug:

No download button for any file in the Files panel. No rich viewers — .docx and .html display as raw bytes (wingdings); .md displays as raw markdown source. No refresh button on the Files panel; users have to reload the entire browser. Folder-vs-file icon detection is unreliable. Requested Fixes

Priority order:

Make Files panel rendering deterministic: every entry the backend API returns must be displayed; refreshes must reflect actual disk state. Add a download button. Add a refresh button on the Files panel. Inline rendering for .md and .html; automatic download for .docx and other binary formats. Fix folder-vs-file icon detection. Workarounds Tried That Did Not Work

Writing to /home/workspace/workspace from agent terminal Writing via docker exec into hermes-app chown -R 10000:10000 to match UI-created file ownership Hard browser refresh, empty-cache reload, fresh incognito window Verifying via direct API call that the backend returns correct data (it does) Creating uniquely-named test markers to detect which path the UI reads (markers never appeared even though they existed on disk and in the API response) Severity

Critical. Silent nondeterminism in basic CRUD makes every higher-level workflow unreliable. The agent cannot be trusted to deliver artifacts. Until fixed, Hermes is not fit for any task that produces persistent user-visible output.