Gemini is not showing goose is working on it and needs to be prodded to continue

[zanesq]

Describe the bug

Using gemini model there is no goose is working on it and needs to be prodded to continue

To Reproduce Steps to reproduce the behavior:

1. Choose gemini model
2. Chat
3. Nothing comes back no goose is working on it
4. Needs to be chatted with again to get a response

Expected behavior Goose should show working on it and respond with results without needing to be prodded

Screenshots

Please provide following information:

• OS & Arch: Mac M3
• Interface: UI
• Version: 1.1.3
• Extensions enabled:
• Provider & Model:

Additional context User tried a new session with same model same result, switched to claude and it started working again.

[taniandjerry]

Oh no! Linking Discord thread with other community members with similar issue: https://discord.com/channels/1287729918100246654/1397747633652498573

[zanesq]

Also users are reporting that its stopping when accessing local filesystem/tools might be the same problem but should look into that while we fix this.

[LordMelkor]

I'm encountering this issue as well. It seems to not be making tool calls.

[zanesq]

User reported it also happened with o3

[cbruyndoncx]

v1.7.0 tested with gemini 2.5 flash and openai o3, it shows consistently [spinner] goose is thinking

@taniashiba i think this has been resolved and can be closed.

[angelahning]

Has been fixed https://github.com/block/goose/pull/3898

[zanesq]

Reopening, someone reported it today internally. Tagged @angelahning in the thread

[DOsinga]

can we reproduce this?

[cbruyndoncx]

I got similar issue with openai yesterday, but then i found a long list of processes when i was debugging my recipes in the crontab. Basically i had a ton of mcp entries lingering in the background which only went away after a reboot. (WSL, i was running for 4 days). I even had MCP entries which i did not remember starting at all , specifically a custom mcp server for task management. Since reboot, and thus process cleanup yesterday afternoon, running fine with v1.9.0

$ systemctl status cron ● cron.service - Regular background program processing daemon Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled) Active: active (running) since Mon 2025-10-06 13:57:29 CEST; 24h ago Docs: man:cron(8) Main PID: 448 (cron) Tasks: 1 (limit: 38274) Memory: 844.0K () CGroup: /system.slice/cron.service └─448 /usr/sbin/cron -f -P

I did not capture the output at that time, but it was about 2 screens full. I suspect the enable of mcp servers with platform might have caused it when i did not have the necessary mcp enabled for the prompt i passed in the run.

[DOsinga]

I think you looked at this before @angelahning ?

[zanesq]

Hi @angelahning checking if this is still in progress?

[cbruyndoncx]

For what it's worth, i have not seen anything unusual anymore, but i am still running v1.9.3 because of subrecipe session issues.

[angelahning]

I saw goose was rate-limited by the google provider. For example, it can reply please retry in 56.803374332s and goose will wait however long the provider tells us to. This retry interaction is not apparent to user and it will come off hanging, but it will eventually finish with enough patience.

The above is a separate issue from goose just flopping, which we also saw with gemini... I still need to investigate deeper for that.

[zanesq]

Pretty sure the issue still exists, just tried creating a tamagotchi game from the new chat with Gemini on v1.12.1 and it needed to be prodded

[DOsinga]

can you share the diagnostics for that, @zanesq

[zanesq]

diagnostics_20251031_18.zip

[angelahning]

Handed off to @amed-xyz cuz I am OOO next week.

[amed-xyz]

This seems to be Gemini-specific. From a very simple request:

{
  "role": "user",
  "content": "develop a super minimal, lightweight tic-tac-toe game"
}

Gemini returns a planning/announcement message instead of taking action. The model had access to file creation tools but chose to respond conversationally, with zero tool requests:

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "I will start by creating a Python file named `tictactoe.py` for the game logic."
    }
  ]
}

Thus, closing the agent loop.

Perhaps we can tweak our prompts for Gemini specifically?

Note: I experienced exactly the same issue using Gemini's CLI, this bug is not directly related to Goose.

[zanesq]

Yeah I've seen gemini stop like this outside of goose but not as often so there must be something we can do.

[DOsinga]

I'm downgrading this to a p2. as noted, it doesn't seem to be really a goose specific issue; in fact there's a long running discussion at Google's about this: https://discuss.ai.google.dev/t/gemini-2-5-pro-ending-the-turn-when-it-tries-calling-a-tool/78876/31

we could possibly do something where we have provider specific additions to the prompt and see if we can get gemini to continue that way?

if you run into this problem, can you change your AGENTS.md and add some instructions like, make sure to always do the toolcall and not just end with a statement saying you will call the tool. if that helps we could add it to the system prompt for gemini

[michaelneale]

with gemini 3 as a step forward, I think we can close this. I also think a more general solution is required - where we have (another) loop evaluate if the task was completed, and coach it forward if not cc @DOsinga