block
Goose can't write to file or call mcp servers even in autonomous mode
Describe the bug
We talked already in discord here but the gist of it is that for some reason my goose it's not doing any tool call, and it can't even write to files even if it's in autonomous mode.
To Reproduce Steps to reproduce the behaviour:
- Open goose
- Set autonomous mode
- Ask to call an MCP server or write a file
- See how the response is that it needs permissions
(I'm sure this doesn't happen to everybody, but unfortunately I have no idea what settings could have caused this)
Expected behaviour Goose should be able to call MCP tools or write files in autonomous mode
Screenshots
Please provide following information:
- OS & Arch: MacOS
- Interface: UI
- Version: 1.12.0
- Extensions enabled: Developer, Extension Manager, Todo, Svelte
- Provider & Model: claude-code
Additional context
If it could help, goose was not able to run the claude bin, so I had to set CLAUDE_COMMAND to the actual file /Users/paoloricciuti/.volta/bin/claude. I also had one moment when it was making tool calls but not on the svelte extension. I figured out it was a problem with our MCP server, but now the problem it's there even if the extension is not even installed any more.
note to try this with the svelte mcp server if you're looking to reproduce -- https://mcp.svelte.dev/mcp
note to try this with the svelte mcp server if you're looking to reproduce -- https://mcp.svelte.dev/mcp
Nope, my goose can't call extensions or write to file even if I don't have the svelte extension installed at all
I believe this is particular to the svelte tool. We've seen this before where goose thinks it does not have access to the svelte tool and then asks the user permission to use it even in autonomous mode. I wonder if it has to do with the naming here, there's a - in the name and there is some weird renaming in the code base going on
can you switch off the svelte extension and see if it works there?
I completely removed the extension and it can't call any tool or write files
for some reason in that screenshot you are missing the little bug icon that should allow you to produce a diagnostics report. can you shut down goose and restart and see if it shows then? it looks like this:
then reproduce the problem and immediately click that button and upload the report.
Here's with a session I also reproduced the issue with
@alexhancock Is this issue about auto-filtering which is like basically saying that goose cannot intervene in any tool/extension managed by the Claude CLI, and no goose tool can be used by it either?
I've not looked deeply, but I just tried the Claude Code integration today and found it can't access anything, and auth notifications don't propagate back to goose. So it could be really easy to get into a bind thinking something would work when it wouldn't. I may be mistaken on this.
Basically, at first I thought it was pass-through LLM (like convenience one-click api-key for anthropic LLMs via the Claude CLI). However, I think pass-through really means delegate all things and not use any goose tools, which if true could explain glitches like this.
I think @codefromthecrypt is right...it also happens with gemini btw but switching to an Anthropic api key did the trick
That is correct, any CLI Provider like claude code, gemini cli take over completely from goose. So the MCP you want to use, you need to setup in the CLI provider MCP settings. So using the CLI provider is a kind of convenience feature to save costs, but actual mileage varies depending on what you want to do as you can see, it means there is less integration with the goose ecosystem overall. Look at it like a cheaper frontend tunnel.
So there's no way to fix this? I think Claude allows you to "login with Claude code"
I have a significant work in progress local to use claude's not well documented approval mcp hook to dispatch approve/deny to goose UX (even if the tools and rules live in Claude still).
The jist is a bit inverted. Goose Claude provider initializes an ephemeral MCP server that complies with Claude's hooks. It then passes that to the CLI args so that when Claude runs into an approval gate it asks Goose. There are devil in details about blocking event loops etc but anyway thats the flow.
I ran into some holes trying to figure out how to elegantly test this. If I dont have a draft PR by Monday, nag me and I will at least raise an issue with the full design I am tinkering with between other tasks.
so are there 2 issues here - one with svelte and one with claude cli provider? or are they they same and things are being confused - any idea @codefromthecrypt ?
ah yes, claude cli, hence @codefromthecrypt work - lets sync up see if we can make it work, but at least currently there are no MCPs when using claude cli (tried to documebt that, but I guess it isn't in the app)
@paoloricciuti oh - not related directly, just @blackgirlbytes mentioned it, but no, that is unrelated. claude cli just passes things through from goose, there is no mcp from the goose side at all at the moment so that isn't relevant.
@michaelneale just so you don't chase a bug it's not there...there's no problem with the svelte MCP whatsoever. The discord discussion started because of that but I'm fully able to use it if I use a different provider.
@paoloricciuti gotcha! thanks.
Another thing - claude has a one shot cli, if you use that direct, can it write to files for you?
@paoloricciuti how about with https://www.eesel.ai/blog/claude-code-permissions like the dangerously skip permissions mentioned here ? Or a more granularly granted permission for the exact session ?
yeah I think goose can't solve that - if claude code itself can't write files (it should set that flag BTW - although the flag can change). thanks for trying @paoloricciuti
thanks all - https://github.com/block/goose/pull/5594 - will help with some of this - as it uses the new flag and maps to goose (and gives better feedback).
Follow on issue for general cli: https://github.com/block/goose/issues/5593