Bug Reports

For *NIX systems, there is an open specification for a standard set of directories that applications should tap into regarding where a user would prefer an app's configuration/state/metadata files go to over just some .dotdir cluttering up a user's home directory, which may or may not contain sensitive data. https://specifications.freedesktop.org/basedir-spec/latest/ Currently MCP configuration on macOS gets dropped in ~/.boltai , regardless of the presence of a known preferred XDG standard location. A good number of apps will fallback to a home dotdir if a known XDG location isn't present on the machine and it would be nice if BoltAI at least made the attempt to read/store data in the standard's location before writing to ~/.boltai . The most fitting place to check first for a user's config of MCPs would be at ~/.local/share/boltai/mcp.json ( $XDG_DATA_HOME/boltai/mcp.json ) to conform with the following: "$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used." $XDG_DATA_HOME (~/.local/share/boltai) is preferred over $XDG_CONFIG_HOME (~/.config/boltai) because it is common for people to put their config dir in a git repository and share publicly on something like GitHub. Because the MCP file will probably contain tokens/auth, it is more fit to be a private "user data" file than a public config file.

I'm using Gemini-2.5-flash-image-preview model via OpenRouter API. It can access attached images (input) but generated image outputs are not displayed in BoltAI chat. FYI, in OpenRouter Chatroom, Gemini 2.5 Flash Image Preview works well. The generated images (output) are displayed in chat.

Release v1.30.2, "Fixed the issue where Gemini 2.0 Flash model cannot use Grounding Tool" None of the Gemini models (e.g., Gemini 2.5 Pro and Gemini 2.5 Flash) work with Grounding in v1.36.1 (build 165). Is there a fix I can implement on my end or does this need a new release to fix?

Usually when configuring MCP servers you set Streamable HTTP or SSE in the "type" parameter, e.g: { "mcpServers": { "crawl4ai-sse" : { "type": "sse", "url" : "https://crawl4ai.my.domain/mcp/sse" }, "crawl4ai-http" : { "type": "streamableHttp", "url" : "https://crawl4ai.my.domain/mcp/http" } } But when providing either of these Bolt fails to save the config with the error "Invalid JSON format: The data couldn't be read because it is missing." I'm assuming either bolt is using a different configuration parameter for the transport type or only supports local servers running in STDIO mode? If it is the latter - I'd like to request streamable HTTP and SSE transports (although streamable HTTP will replace SSE-only mode in a future MCP specification) as the majority of MCP servers I consume these days are networked.

Using 1.36.4 and tried with Anthropic and OpenAI models: I tried out the BoltAI MCP capability on a MCP that crawls a graph database and will retrieve information based on what the user asks for. This usually takes a few calls for the LLM to "feel around" and see what data is out there and how it is structured. I usually found that the provider sends an error message after the 5th tool call, right when the LLM seems to get its bearings. To abstract and isolate the issue, I got the memory knowledge graph MCP and instructed it to fill the memory with 20 fun facts of a random topic. It consistently fails on the 6th call because the previous tool calls aren't provided in the request. Here are two instances of this happening: MCP: { "mcpServers" : { "memory" : { "args" : [ "-y", "@modelcontextprotocol/server-memory" ], "command" : "npx", "env" : { "MEMORY_FILE_PATH" : "/Users/zack/.local/state/mcp/memory.json" } } } } OpenAI Error Message: Sorry, OpenAI has rejected your request. Here is the error message: Invalid parameter: messages with role 'tool' must be a response to a preceeding message with 'tool_calls'. Anthropic Error Message: Sorry, your request has been rejected. Here is the error message: {"error":{"message":"Provider returned error","code":400,"metadata":{"raw":"{"message":"messages.0.content.0: unexpected tool_use_id found in tool_result blocks: toolu_vrtx_018SdtQtQUurgmV1ECHwXXVD. Each tool_result block must have a corresponding tool_use block in the previous message."}","provider_name":"Amazon Bedrock"}},"user_id":"redacted"}

Ollama returns the ID for tool calls, but BoltAI ignores them and instead sends an empty string as a response. ollama response: { "choices": [ { "index": 0, "message": { "role": "assistant", "content": "[REMOVED]", "tool_calls": [ { "id": "call_d282inrd", "index": 0, "type": "function", "function": { "name": "[REMOVED]", "arguments": "[REMOVED]" } } ] }, "finish_reason": "tool_calls" } ] } subsequent BoltAI request: { "messages": [ { "content": "[REMOVED]", "role": "assistant", "tool_calls": [ { "function": { "name": "[REMOVED]", "arguments": "[REMOVED]" }, "type": "function", "id": "" } ] }, { "content": "[REMOVED]", "tool_call_id": "", "role": "tool" } ] } BoltAI v1.35.3 (build 163) Ollama v0.9.5

I have a subset of OpenRouter models selected in the Models tab in the preferences. I've noticed that every time OpenRouter adds new models, this list is messed up. I have to go back re-select the ones I care about. This is especially annoying since I have multiple OR connections and I have to redo this for each.

MacOs Sequoia 15.5 Bolt 1.36.1 I had sent one message with a LOT of text. Then it responded with a little text. I maximized the window fine. Then when I went to drag it smaller from the top left corner, the app hung and I got the pinwheel of death. Had to force quit.

BoltAI only displays reasoning data for messages, not for tool calls. This data could be useful for debugging purposes, such as improving prompts. BoltAI v1.35.3 (build 163) Ollama v0.9.5

Despite the status of the flag Stream responses , the result is only returned once the stream has completed. This is necessary to avoid request timeouts and improves the user experience since request processing can take a significant amount of time. BoltAI v1.35.3 (build 163) Ollama v0.9.5