things to make goose 1.43 better and some 'bugs'

[f1-outsourcing]

These are my findings with using goose. I start to understand now why some many have unwanted deleted files, and breakouts. Everyone is coding clients/agents that can access everything. I have an environment where everything is closed and only things that I have opened, are available.

1. I am disabling extension: developer and extensions (auto manages extension use???). I use own tools on a remote server. All local tools fail. When these two both are disabled, goose automatically still enables developer, so I need to disable it again during first chat message. I need to disable developer as these tools do not work.

2. even after disabling like this I am still getting these???

3. Goose seems slower that my vscode/continue with same model. I assume this is because the context window is to big. Goose uses context window 105000 while I set in vscode/continue it to 65536, I guess this causes a K/V spill over? There should be an option to set this somewhere.
   this does not work

set GOOSE_INPUT_LIMIT=65536

"%~dp0goose.exe" %*

4. Sort configured provider on the top, constantly need to search where mine is.

5. I have green check marks on providers I did not configure ...

6. Auto detect models in ollama

7. option to set keep_alive I am getting these states in Ollama "Stopping..." "2 minutes from now"

8. maybe an option that automates sending '?' or '.' when receiving this

9. If the whole chat history is send as context. Have the opportunity to delete items from this chat

10. enable / disable specific tools from an extension.

11. move chat window out of the application, so I can have chat window on different virtual desktop

12. offer to work in sequence. I have the impression chat sessions run concurrently that is less efficient for running on own hardware. There should be a toggle switch that runs the tasks in sequence.

[f1-outsourcing]

wtf???

Tool Name (tree vs fs__fs_tree)
The tool was called with the short name tree, but the registered tool name is fs__fs_tree (with the fs__ prefix). The framework couldn't route it. This is the immediate cause of the error.

[f1-outsourcing]

are you checking this @filipkujawa, @claude, @DOsinga, @jamadeo

[f1-outsourcing]

Where is the history? Why the llm can not access the previous command ouputs? Why does it think it is on S:\tmp???

[filipkujawa]

Thanks for this @f1-outsourcing , and sorry for the wait. In the future, please file things like this as issues rather than a discussion. We've moved to an issue-first model where the issue is the source of truth for any work that gets implemented so you will get faster response there.

Also, you're on 1.43 and 1.46.0 is out - please upgrade first, items 1 and 2 and your tree comment are all the same bug fixed there.

1. Fixed in 1.46.0 by fix: respect disabled builtin extensions (developer) at session start #10223

2. Not developer. those cards are analyze which is a separate platform extension that is on by default and curl_get, which is one of your own remote tools (green dot means it succeeded). Disable "Analyze" in Settings -> Extensions as well. The red dots are Analyze failing on local paths, which fits your setup.

3. Real bug: goose sends num_ctx as a native Ollama options field but posts to the OpenAI-compatible /v1 endpoint, which ignores it, so GOOSE_INPUT_LIMIT has no effect.

For now set OLLAMA_CONTEXT_LENGTH=65536 on the Ollama box, plus GOOSE_CONTEXT_LIMIT: 65536 in config.yaml so goose's meter matches (your .bat only reaches the CLI, not the desktop).. Will raise your bug on the related #10966

4. Accepted, seems like a good improvement. I'll file an issue.

5. Real bug. goose marks a provider configured when its required keys merely have defaults, or when it has no required keys at all. I'll file an issue. Related to Deleted providers are still listed in Goose Desktop (Linux - contin.) #11212

6. Already works. goose reads your model list from Ollama's /api/tags. the list is cached for 24h, so a freshly pulled model may need a restart to show up.

7. Set OLLAMA_KEEP_ALIVE on the Ollama server

8. That message means goose already retried three times and got nothing back. Given your newest comment I think this is the same root cause as item 3: your server is rejecting the request once truncation drops the last user message, and goose dead-ends instead of recovering. Fixing the context window should make this go away. If it doesn't, which model and Ollama version are you running?

9. Partially exists. Hover your own message, click Edit, then "Edit in Place" - that deletes that message and everything after it. Deleting a single message from the middle is not possible. Feel free to file an issue about this.

10. Already works, add available_tools to the extension in config.yaml and only those tools are sent to the model.

11. Already works. Ctrl+N opens a new chat window, each chat window is a real separate OS window

12. Interesting, will file an issue about this to discuss.

On your newest comment - same root cause as 3. "no user query found in messages" is Ollama's error, not ours: it truncates from the front until no user message is left, then refuses to render. That's also why the model lost your earlier command outputs, and why it invented S:\tmp - the working directory is sent in a message class Ollama drops first, so it had none to read. OLLAMA_CONTEXT_LENGTH should clear all three.

On tree vs fs__fs_tree: tree is a real goose tool, one of developer's, registered without a prefix - so it was in your list because of #.1. goose never rewrites fs__fs_tree. Upgrading should make it disappear.

[f1-outsourcing]

Also, you're on 1.43 and 1.46.0 is out - please upgrade first, items 1 and 2 and your tree comment are all the same bug fixed there.

I had to down grade, because my chats were constantly terminating. This qwen is quite talkative.
#11269

That message means goose already retried three times and got nothing back. Given your newest comment I think this is the same root cause as item 3: your server is rejecting the request once truncation drops the last user message, and goose dead-ends instead of recovering. Fixing the context window should make this go away. If it doesn't, which model and Ollama version are you running?

I had to upgrade the container to 0.32.13 for qwen3.8. I assume it is the newest.