Problem
The bash MCP tool is technically capable of normal shell filesystem operations, but its schema description currently tells clients not to use bash to create or modify files and restricts it mainly to inspection/tests/builds.
This creates a practical capability gap in minimal mode: DevSpace exposes open_workspace, read, write, edit, and bash, but there is no dedicated delete, move, rename, copy, or mkdir tool. As a result, an agent following the schema cannot perform basic requested operations such as deleting a file, even though runShellTool() passes the command directly to createBashTool() and there is no runtime filter blocking commands like rm, mv, cp, or mkdir.
Reproduction
- Run DevSpace in the default/minimal tool mode.
- Ask an MCP client to create a file using
write.
- Ask it to delete that file.
- The client sees no delete tool, while the
bash description says not to use bash for file changes, so a compliant agent refuses to run rm.
Root cause
In dist/server.js, the bash tool description and its command input description contain instructions equivalent to:
- use bash only for tests/builds/git inspection/search/directory inspection
- do not use bash to create or modify files
- shell command must not create or modify project files
However, runShellTool() in dist/pi-tools.js simply executes the provided command through createBashTool(context.cwd). The restriction is therefore contractual/prompt-level rather than an enforced runtime security boundary.
Suggested behavior
Keep read, write, and edit preferred for precise file content operations, but explicitly allow bash for shell-native filesystem operations when required by the user task, including rm, mv, cp, and mkdir.
For example, the contract could say that bash may create, modify, move, rename, copy, or delete files/directories when required, while recommending the dedicated tools where they are a better fit.
This would make the advertised tool surface consistent with the actual execution capability and remove the dead end for filesystem operations that have no dedicated MCP tool.
Environment
Observed on @waishnav/devspace 1.0.8 in default/minimal tool mode.
Problem
The
bashMCP tool is technically capable of normal shell filesystem operations, but its schema description currently tells clients not to use bash to create or modify files and restricts it mainly to inspection/tests/builds.This creates a practical capability gap in minimal mode: DevSpace exposes
open_workspace,read,write,edit, andbash, but there is no dedicateddelete,move,rename,copy, ormkdirtool. As a result, an agent following the schema cannot perform basic requested operations such as deleting a file, even thoughrunShellTool()passes the command directly tocreateBashTool()and there is no runtime filter blocking commands likerm,mv,cp, ormkdir.Reproduction
write.bashdescription says not to use bash for file changes, so a compliant agent refuses to runrm.Root cause
In
dist/server.js, thebashtool description and itscommandinput description contain instructions equivalent to:However,
runShellTool()indist/pi-tools.jssimply executes the provided command throughcreateBashTool(context.cwd). The restriction is therefore contractual/prompt-level rather than an enforced runtime security boundary.Suggested behavior
Keep
read,write, andeditpreferred for precise file content operations, but explicitly allowbashfor shell-native filesystem operations when required by the user task, includingrm,mv,cp, andmkdir.For example, the contract could say that bash may create, modify, move, rename, copy, or delete files/directories when required, while recommending the dedicated tools where they are a better fit.
This would make the advertised tool surface consistent with the actual execution capability and remove the dead end for filesystem operations that have no dedicated MCP tool.
Environment
Observed on
@waishnav/devspace1.0.8 in default/minimal tool mode.