goose gets stuck even on non-blocking requests

[blackgirlbytes]

Describe the bug

goose seems to get stuck on simple tasks such as reading/accessing a file. Typically, this happens when goose runs a long-running task like npm run dev..then other operations get blocked, but it seems to be happening in other cases as well.

Community member: @/fabian_andgo had the following session where goose got stuck, but there was no long running task and the context window was fairly low. When asked why it was taking so long goose said, "yeah sorry about that"

Let me check the taskAnalyzer.ts file to see if there might be an issue with the implementation:


─── text_editor | developer ──────────────────────────
path: ~/D/a/0/t/s/services/taskAnalyzer.ts
command: view

Now let me check if there are any environment variables set up properly for the API key:


─── text_editor | developer ──────────────────────────
path: ~/Documents/ai_test/03_cli_task_splitter/task-splitter/.env
command: view

Let me check what's in the .gooseignore file:


─── shell | developer ──────────────────────────
command: cat .gooseignore
Let me check what's in the .env file:


Context: ●●○○○○○○○○ 19% (50833/262144 tokens)
( O)>

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
goose should continue to run on simple tasks like reading a file.

[taniacryptid]

Replying to this issue to say I just ran into this issue as well when asking goose to look at a local file within its directory, and started happening after the latest release! Also linking back to Discord thread with other community members reporting it in case: https://discord.com/channels/1287729918100246654/1413076002690699264/1413175010511683786

[ewann]

Replying to this issue to say I just ran into this issue as well when asking goose to look at a local file within its directory, and started happening after the latest release! Also linking back to Discord thread with other community members reporting it in case: https://discord.com/channels/1287729918100246654/1413076002690699264/1413175010511683786

I wonder if it's worth capturing provider & model info too, particularly is at risk of getting a fair amount of "me too". For example: I appear to experience this a lot with qwen3* models, but qwen2.5-coder not so much / not at all.

[alexhancock]

I have to say I haven't seen it at all recently with 1.7.0, but appears some people are.

I just merged this change which should give us some additional logging when this happens: #3888

We will include this in the next release, and then when it happens we can find the associated log and see if an LLM or tool interaction hung

[jmdaly]

I see this and similar behaviour from time to time. The last time I saw it (maybe two weeks ago), I was using GPT-4.1. Goose stopped with an error and returned me to the prompt. After it stopped, I asked it to continue, but then goose crashed with this error:

-32602: Could not interpret tool use parameters for id call_KvFCDJFq3qX4N2N3tpEuvByB: EOF while parsing an object at line 1 column 56. Raw arguments: '{"relative_path":"api/config.py","max_answer_chars":1500'
Context: ○○○○○○○○○○ 0% (0/1000000 tokens)
( O)> Yes please scan the repo for suspect code!
◐  Contemplating code conundrums...
thread 'main' panicked at crates/goose/src/token_counter.rs:149:69:
called `Result::unwrap()` on an `Err` value: ErrorData { code: ErrorCode(-32602), message: "Could not interpret tool use parameters for id call_KvFCDJFq3qX4N2N3tpEuvByB: EOF while parsing an object at line 1 column 56. Raw arguments: '{\"relative_path\":\"api/config.py\",\"max_answer_chars\":1500'", data: None }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I had a look at thetoken_counter.rs source, and it's calling .unwrap() on a Result without checking if there's an error. It looks like the LLM returned a JSON string without a closing }. I started working on a fix in a fork, but haven't had the chance to finish it. It's just a matter of checking for the Err and handling it though, at least in this particular case!

[alexhancock]

@jmdaly Interesting! Are you referring to this one?

goose/crates/goose/src/token_counter.rs

Line 149 in 72eaa20

let tool_call = tool_request.tool_call.as_ref().unwrap();

[jmdaly]

@jmdaly Interesting! Are you referring to this one?

Hi @alexhancock, yes that's the one!

[DOsinga]

should be fixed on main. thanks for the report

[hustcer]

I ran into this issue in goose 1.18.0 while using it to translate a very long document:

 -32602: Could not interpret tool use parameters for id call_00_P3MNat13mVUfcdktMOKwKpXa: EOF while parsing a string at line 1 column 12815