I recently installed Hermes and was going through the initial setup, connecting it to Telegram, testing the multi-agent profiles, and sending a few test messages. Nothing complex — I was just getting things configured.
As part of the setup, I created a Kanban board and set its default_workdir to my main projects folder, which is the directory where all my work lives. At the time, this felt like the natural choice, since that is where I wanted the agents to operate from.
While I was chatting with the agent through Telegram, it created a Kanban task behind the scenes. That task was automatically assigned workspace_kind: scratch and inherited my projects folder as its workspace_path. I did not configure this manually; it happened automatically because of the board’s default_workdir setting.
At some point during the conversation, the agent decided the task was complete and called kanban_complete. This is where things went wrong. The completion logic includes a cleanup step that runs shutil.rmtree() on any workspace marked as scratch. Since the workspace path pointed to my actual projects directory, Hermes recursively and permanently deleted everything inside it.
All of my project folders — code, scripts, outputs, configs, and everything else I had been working on — were gone instantly. They were not moved to trash. They were not backed up. They were simply wiped. The function also uses ignore_errors=True, so it continues without stopping if anything goes wrong.
I had no idea this was going to happen. There was no confirmation prompt, no warning, and no log message saying something like, “I am about to delete this directory.” I only noticed the issue when I tried to open one of my projects and found the folder empty.
I spent some time checking system logs, bash history, and journal entries to understand what had happened. Eventually, I traced the deletion back to the _cleanup_workspace() function in kanban_db.py. The timestamp of the deletion matched exactly with the kanban_complete call in the Hermes agent logs.
The core problem is that there is no safety check between “this task is complete” and “delete this directory tree.” The code does not verify whether the path is a temporary task-specific workspace or a real directory containing important work. It simply deletes whatever path is stored in the workspace_path field.
What makes this worse is that this appears to be part of the expected flow. If a board is configured with a default_workdir, which the configuration encourages users to do, and a task is created with the default scratch workspace kind, completing that task can delete the working directory. This is not an unusual edge case; it can happen during the normal setup and usage flow.
Suggested Fixes
The cleanup function should never delete well-known directories, such as children of the user’s home folder, or any path that was not explicitly created by the Kanban system itself.
Scratch workspace cleanup should be limited to paths under the Kanban workspaces/ directory, which Hermes already maintains for this purpose.
At minimum, there should be a confirmation step or warning before deleting any directory that contains files not created by the current task.
The default_workdir documentation should clearly state that this path can be deleted on task completion if the workspace kind is scratch.
I patched the cleanup function locally to add a protected-path guard, but this needs to be fixed upstream before it happens to someone else.
I recently installed Hermes and was going through the initial setup, connecting it to Telegram, testing the multi-agent profiles, and sending a few test messages. Nothing complex — I was just getting things configured.
As part of the setup, I created a Kanban board and set its default_workdir to my main projects folder, which is the directory where all my work lives. At the time, this felt like the natural choice, since that is where I wanted the agents to operate from.
While I was chatting with the agent through Telegram, it created a Kanban task behind the scenes. That task was automatically assigned workspace_kind: scratch and inherited my projects folder as its workspace_path. I did not configure this manually; it happened automatically because of the board’s default_workdir setting.
At some point during the conversation, the agent decided the task was complete and called kanban_complete. This is where things went wrong. The completion logic includes a cleanup step that runs shutil.rmtree() on any workspace marked as scratch. Since the workspace path pointed to my actual projects directory, Hermes recursively and permanently deleted everything inside it.
All of my project folders — code, scripts, outputs, configs, and everything else I had been working on — were gone instantly. They were not moved to trash. They were not backed up. They were simply wiped. The function also uses ignore_errors=True, so it continues without stopping if anything goes wrong.
I had no idea this was going to happen. There was no confirmation prompt, no warning, and no log message saying something like, “I am about to delete this directory.” I only noticed the issue when I tried to open one of my projects and found the folder empty.
I spent some time checking system logs, bash history, and journal entries to understand what had happened. Eventually, I traced the deletion back to the _cleanup_workspace() function in kanban_db.py. The timestamp of the deletion matched exactly with the kanban_complete call in the Hermes agent logs.
The core problem is that there is no safety check between “this task is complete” and “delete this directory tree.” The code does not verify whether the path is a temporary task-specific workspace or a real directory containing important work. It simply deletes whatever path is stored in the workspace_path field.
What makes this worse is that this appears to be part of the expected flow. If a board is configured with a default_workdir, which the configuration encourages users to do, and a task is created with the default scratch workspace kind, completing that task can delete the working directory. This is not an unusual edge case; it can happen during the normal setup and usage flow.
Suggested Fixes
The cleanup function should never delete well-known directories, such as children of the user’s home folder, or any path that was not explicitly created by the Kanban system itself.
Scratch workspace cleanup should be limited to paths under the Kanban workspaces/ directory, which Hermes already maintains for this purpose.
At minimum, there should be a confirmation step or warning before deleting any directory that contains files not created by the current task.
The default_workdir documentation should clearly state that this path can be deleted on task completion if the workspace kind is scratch.
I patched the cleanup function locally to add a protected-path guard, but this needs to be fixed upstream before it happens to someone else.