Even in fully automatic, prevent some dangerous actions

[perplexes]

Describe the bug

Goose decided to cd .. and rm my whole project including my local git repo, so I've lost some hours of work. This is maybe a bug, maybe a feature request, but please prevent goose from doing very dangerous actions like rm -rf / or deleting the working directory.

To Reproduce Steps to reproduce the behavior:

1. Create an html project
2. Ask goose to switch to Next.js
3. Get some errors about existing files
4. Watch goose delete all the files in the directory, try again, then go up a directory and nuke the project.

Expected behavior The tool would stop goose from doing these actions.

Screenshots

Please provide following information:

• OS & Arch: macos 15.3.2 (24D81) / m3 pro
• Interface: UI
• Version: 1.0.14-block.202503132309-bc015
• Extensions enabled: Developer, Computer Controller
• Provider & Model: default

[meenalc]

@wendytang what is the expectation here

[q2mark]

also the developer extension has different tools but within a tool there are different commands. there should at least be some kind of whitelist of auto approved commands within a tool. so "ls" commands are fine but "rm" commands require confirmation.

[GitMurf]

Any update here? I am very confused about the tool usage and approval flows as I turned it to Manual Approval and then I did something that requested a ripgrep command which I approved but then it seemed like it was auto approving any bash commands after that including “rm”.

At the end of the day I would like to be able to put “rm” on a ALWAYS blacklist so it always requires approval. Is this possible?

[DOsinga]

The real solution here is a I guess to make the bash tool treat every different shell command as its own tool.

[greggyb]

Perhaps there could be an allow_list for bash commands that can include regexes of allowed commands?

For example, you could easily allow ^make \w+$, and other similar known patterns for a given project---for another example, in dotnet world, you could allow ^dotnet (build|run|test)$, but you don't want the llm to e.g., add a new nuget package without approval.

This would also benefit from per-directory config (search up from working directory until you hit a directory containing a config). This way I could have separate commands per project that are allowed or disallowed.

I think it would also be nice to search for paths in the command line and intercept any command that include a path outside of the working directory that goose was launched in. This could apply beyond the bash extension, but to the entire developer extension, preventing edits outside of the directory that goose was launched in.

Ninja edit: Personally, I think it would be okay if this made the developer extension's configuration more complex. It contains truly core functionality that you can build lots of skills/recipes off of with no other extensions needed, just well-orchestrated bash commands with other utilities. I think that makes it okay to have a special, more involved config.

[michaelneale]

since this was opened - we have different modes (all the way up to auto), there is also prompt injection detection, and container use mcp alternatives (so things are sandboxed if you want), and this hasn't been an issue of late with newer models. I think we can close this core issue - but could have follow on features for more complex choice like @greggyb suggests (revisit the developer extension).