Fosowl
Windows Compatibility: "Tool: bash" Agent Generates Incompatible Commands & File Operation Issues
I am trying this on my computer with the help of gemini 2.5 pro to try to fix issues.untill now it helped me resolve all issues wich did arise.but now it sugested i write this in bug report because we cant get any further. sorry for my englis... not my first language.
Describe the bug When running AgenticSeek on Windows 11, agents that are designated with Tool: bash (as seen in the internal agent logs/browser output) attempt to execute commands that are often incompatible with the Windows Command Prompt (CMD.exe), which appears to be the shell environment these commands are executed in. This leads to errors and incorrect behavior for file manipulation and script execution tasks.
Bash-Specific Syntax in CMD:
Commands generated by the agent frequently include bash-specific syntax. For example, using # at the beginning of a line for comments:
Tool: bash
# Verify file creation and content
type F:\agentic_seek_workspace\movie_night.txt
Feedback: [failure] Error in execution: Command cd F:\agentic_seek_workspace && # Verify file creation and contenttype F:\agentic_seek_workspace\movie_night.txt failed with return code 1: '#' is not recognized as an internal or external command, operable program or batch file.
This immediately fails in Windows CMD. Another example is the use of echo -e for interpreting backslash escapes (like \n for newlines): Command Generated: cd F:\agentic_seek_workspace && echo -e "Movie1\nMovie2\nMovie3" > movies.txt Actual Result on Windows: The file movies.txt is created containing the literal string -e "Movie1\nMovie2\nMovie3", not the movies on separate lines. AgenticSeek reported this as [success] presumably because the command ran without an OS error, but the output was incorrect.
Expected behavior A clear and concise description of what you expected to happen.
File Not Found Errors:
Even when a command is syntactically valid for Windows CMD (e.g., after the agent "corrects" a command by removing the #), it sometimes fails because the target file wasn't found:
Tool: bash
type F:\agentic_seek_workspace\movie_night.txt
Feedback: [failure] Error in execution: Command cd F:\agentic_seek_workspace && type F:\agentic_seek_workspace\movie_night.txt failed with return code 1: The system cannot find the file specified.
This suggests that the preceding step (which should have created the file) might also be failing or saving the file in an unexpected way/location.
Unsafe Command" Aborts by AgenticSeek:
When attempting to write a multi-line Python script to a .py file using an echo "..." > script.py command (even if the syntax was made CMD-compatible), AgenticSeek's internal safety filter aborted the action:
Tool: bash
cd F:\agentic_seek_workspace && echo "python_script_content..." > news_scraper.py
Feedback: [failure] Error in execution: Unsafe command: {command}. Execution aborted. This is beyond allowed capabilities report to user.
This prevents agents from creating scripts or more complex files using this method.
Impact: These issues make it difficult for AgenticSeek to reliably perform tasks on Windows that involve file system manipulation, script creation, or command execution via agents relying on the "bash" tool. The agent often gets stuck in a loop of failing commands or reports task failure.
Attempted Mitigation (Modifying Agent Prompt): I attempted to modify the prompt for the file_agent (found in file_agent.txt) to explicitly instruct the LLM to generate Windows CMD-compatible commands even when using the "bash" tool. This helped reduce the # comment errors but did not fully resolve issues like the echo -e usage or the "Unsafe command" blocks.
Expected Behavior: For robust Windows support, agents performing shell operations should:
Generate commands compatible with the native Windows shell (CMD or PowerShell). Or, if a "bash" tool is intended, AgenticSeek should ensure it correctly invokes a bash interpreter environment (e.g., WSL, Git Bash) on Windows. File creation and verification steps should function reliably on Windows. Safety filters should ideally allow for common agent tasks like writing generated code to files in a secure manner.
Environment:
Operating System: Windows 11 Pro (Version 24H2, OS build 26100.3775) Python Version: 3.10.11 (installed from python.org) LLM Provider: LM Studio (previously also tested with Ollama) Relevant Hardware: AMD Ryzen 5 5600X, 32GB RAM, AMD Radeon RX 7800 XT
Key Issues Observed:
Bash-Specific Syntax in CMD:
Commands generated by the agent frequently include bash-specific syntax. For example, using # at the beginning of a line for comments:
Tool: bash
# Verify file creation and content
type F:\agentic_seek_workspace\movie_night.txt
Feedback: [failure] Error in execution: Command cd F:\agentic_seek_workspace && # Verify file creation and contenttype F:\agentic_seek_workspace\movie_night.txt failed with return code 1: '#' is not recognized as an internal or external command, operable program or batch file.
This immediately fails in Windows CMD. Another example is the use of echo -e for interpreting backslash escapes (like \n for newlines): Command Generated: cd F:\agentic_seek_workspace && echo -e "Movie1\nMovie2\nMovie3" > movies.txt Actual Result on Windows: The file movies.txt is created containing the literal string -e "Movie1\nMovie2\nMovie3", not the movies on separate lines. AgenticSeek reported this as [success] presumably because the command ran without an OS error, but the output was incorrect.
File Not Found Errors:
Even when a command is syntactically valid for Windows CMD (e.g., after the agent "corrects" a command by removing the #), it sometimes fails because the target file wasn't found:
Tool: bash
type F:\agentic_seek_workspace\movie_night.txt
Feedback: [failure] Error in execution: Command cd F:\agentic_seek_workspace && type F:\agentic_seek_workspace\movie_night.txt failed with return code 1: The system cannot find the file specified.
This suggests that the preceding step (which should have created the file) might also be failing or saving the file in an unexpected way/location. "Unsafe Command" Aborts by AgenticSeek:
When attempting to write a multi-line Python script to a .py file using an echo "..." > script.py command (even if the syntax was made CMD-compatible), AgenticSeek's internal safety filter aborted the action:
Tool: bash
cd F:\agentic_seek_workspace && echo "python_script_content..." > news_scraper.py
Feedback: [failure] Error in execution: Unsafe command: {command}. Execution aborted. This is beyond allowed capabilities report to user.
This prevents agents from creating scripts or more complex files using this method.
Incorrect Command "Corrections" by Agent:
The agent's attempts to correct failing commands sometimes reintroduce invalid syntax or suggest entirely inappropriate commands for the task (e.g., suggesting certutil -verifystore "My" ... to verify file content).
Attempted Mitigation (Modifying Agent Prompt): I attempted to modify the prompt for the file_agent (found in file_agent.txt) to explicitly instruct the LLM to generate Windows CMD-compatible commands even when using the "bash" tool. This helped reduce the # comment errors but did not fully resolve issues like the echo -e usage or the "Unsafe command" blocks.
Expected Behavior: For robust Windows support, agents performing shell operations should:
Generate commands compatible with the native Windows shell (CMD or PowerShell). Or, if a "bash" tool is intended, AgenticSeek should ensure it correctly invokes a bash interpreter environment (e.g., WSL, Git Bash) on Windows. File creation and verification steps should function reliably on Windows. Safety filters should ideally allow for common agent tasks like writing generated code to files in a secure manner.
Hello, thank you for the reporting multiple issues, I will look into each one. For now one thing caught my eyes:
You said that the command :
cd F:\agentic_seek_workspace && echo "python_script_content..." > news_scraper.py
It resulted in "Feedback: [failure] Error in execution: Unsafe command:" but this is impossible, in fact I could try the individual part of the code against your command:
(base) λ Martins-MacBook-Air tools → λ git dev* → python3 safety.py Enter a command: cd F:\agentic_seek_workspace && echo "python_script_content..." > news_scraper.py Command is safe to execute.
are you sure this is the command it considered unsafe ? what was in "python_script_content..." ?
I also experienced this issue on a simple request, to create a directory.
output "" It seems direct directory creation commands are restricted for safety. I'll proceed to locate the files (files ) within the
Let me start by finding webcommon.h:
block:0 ""
how does it determine the "safety" of commands is this something internal to AgentSeek. or how can I track this down??! thanks.
You can see the code for the check in sources/tools/safety.py
If you wish you could set self.safe_mode = False in the tools base class (sources/tools/tools.py
I ended up creating a separate agent (file + logic) for Windows, but got a little overzealous and added a bunch more stuff that might not be useful to the whole and/or is detrimental to non-Windows users. Let me know what you think @Fosowl. Maybe try pulling it down and using it?
https://github.com/christiancoleman/agenticSeek/tree/origin/smores
I changed some verbiage in the prompts too, so that's why I cancelled my PR. I felt it was too much to submit at once, but maybe you disagree! Keep me posted. Love the repo.
Very interesting, will look it up later this this week when I have time! You could do one or multiple pull request as "draft" that I will review @christiancoleman