For a bug report, please include the following information:
Your OS version.
Your BoltAI app version.
Are you a Setapp user.
The AI provider & model you’re using.
Steps to reproduce the issue.
The error message
Help me improve BoltAI
mervinisaacmarket@gmail.com's appeal (PLEASE STOP THE MISCONCEPTION) (You had a misconception because mervinisaacmarket@gmail.com did NOT do wrong)
mervinisaacmarket@gmail.com did NOT mean to do personal abuse at comments as he did NOT mean to swear as abuse but he sweared at comments because he WAS overwhelmed that you were thinking that he made no sense when saying that word but he MEANT THAT he saw the app is still working even without the API key and IT’S TRUE and he does NOT accept the false ban. PLEASE UNBAN HIM. NO PERMANENT BANS.
Custom Agent Doesn't Save Plugins (Swift Error)
When selecting plugins for a custom agent, closing the selection dialogue doesn’t save the setting. At the bottom of the pane is the attached Swift error:
In QA
MCP Writes and Edits hang - formerly with Gemini Pro 2.5, now with Claude Sonnet 5.0:
BoltAI MCP Tool-Call Hang: Technical Report Date stamp: 260912 Reporter: Nigel Protter (existing Featurebase reports below) Scope: Local MCP filesystem server tool calls (write_file, edit_file) issued from an AI agent session running inside BoltAI on macOS. 1. Summary Two distinct fault mechanisms were observed during a single BoltAI chat session using a local stdio MCP filesystem server. Both produce the same visible symptom: a tool call appears to stop progressing, with a "Continue" or "Continue generating" control appearing in the UI, and no corresponding tool-result content in the model-visible transcript. 2. Environment OS: macOS (build/version not captured in-session; to be supplied by reporter) BoltAI version/build: not captured in-session; to be supplied by reporter MCP server: local stdio filesystem server (custom, exposing write_file, edit_file, get_file_info, read_text_file, list_directory, among others) Model in use during observation: Claude (Sonnet), accessed via BoltAI's chat interface 3. Fault Mechanism A: Tool-Call Relay Hang Sequence observed: The model issues a tool call (e.g. edit_file) to the MCP server. Screenshots of the BoltAI window show the tool-call block in a "Running tool: ..." state. In at least one occurrence, that running-state block disappeared from the visible history entirely on the next screen state, replaced by a "Continue" or "Continue generating" control, with no result block and no error message rendered. The model's own transcript contains no corresponding tool-result for that call — from the model's side, the call simply never returned. Disk state was checked directly via a separate get_file_info call after the stall. In one occurrence the target file was confirmed unchanged (the write had not reached disk). In a separate occurrence in the same session, the stall occurred immediately after a trivial, already-completed read-only shell command, with no write pending at all, indicating the stall is not exclusively tied to write payload delivery. 4. Fault Mechanism B: Large-Payload Write Non-Return Sequence observed: A write_file call was issued with a content payload of approximately 11,000 characters (11 KB), targeting a new file. The call entered a running state in the BoltAI UI and did not return a result for the remainder of the session turn. No error was surfaced. No tool-result block was produced in the model's transcript for that call. Directory listing after the stall confirmed the target file was never created on disk. A control test was then run: a write_file call with a 4-byte payload to a new file. That call returned a success result immediately, and the file was confirmed present on disk via get_file_info. This establishes that the write pathway is not universally blocked; the fault is correlated with, but not conclusively proven to be caused by, larger single-call payload size. 5. Escalation Test Log A controlled escalation test was run: successive edit_file append calls of increasing size against a single target file, with get_file_info verification after each. StepPayload sizeResult 1 4 bytes (write_file to new file)
In QA
Are MCP and AI preferences completely broken?
For the past six months i’ve been using BoltAI, MCP and AI preferences have not worked for me. Yes, I have read all the posts and the web. New project chats do not inherit MCP server or default AI settings. New Projects do do not inherit MCP server or default AI settings. Preferences seem useless. I have to set all MCP server settings and the AI with every chat spawned to a project row. I have to set set all MCP server settings and the AI with every new Project. Also, there are three separate places to enter AI settings. Settings are a hot mess.
In QA
Silent failures with Opus 5
Hi, I keep finding that Opus 5 requests fail silently. I put in a fairly long prompt, hit enter, it goes away thinking for awhile, then just stops. No response, no error, no nothing. Refreshing the prompt tends to create the same effect. If I switch to an OpenAi model, it then works. v 2.15.0 (build 84) on macOS 26.5.2
In QA
License immediately "forgotten"
Just purchased a Pro license for the latest-and-greatest BoltAI, entered the code, everything looked good: cute confetti animation, congrats, etc. However, I’m soon pestered to “Link Cloud Account” to recognize the license, but that keeps failing with “This license is not active”. Sure enough, when I click Settings went to the License tab, it claims that my license is revoked/deactivated. Restarting BoltAI doesn’t help. I just visited the License Manager web page, and everything looks fine / matches-up over there. Bizarre and (obviously) frustrating.
In QA
web_fetch server_tool_use block sent without its tool_result → Anthropic 400 on next turn
OS version: macOS 26.6 BoltAI app version: 2.15.0 Setapp user: No AI provider & model: Anthropic, Claude (extended thinking on, web_fetch tool enabled) Steps to reproduce: Start an Anthropic chat with the web_fetch server tool enabled. Ask something that makes the model call web_fetch, and let it also emit regular tool_use blocks in the same assistant turn. Continue the conversation for at least one more turn. Error message: messages.1: web_fetch tool use with id srvtoolu_01RYeaAtRGtJzhpnvMWP8ys7 was found without a corresponding web_fetch_tool_result block What's actually wrong: When BoltAI rebuilds the messages array for the follow-up request, the web_fetch_tool_result block belonging to the MOST RECENT server_tool_use is dropped. Earlier web_fetch calls in the same thread are paired correctly — only the latest one loses its result. Once another turn is appended after it, that server_tool_use is a permanent orphan in the history and every subsequent request 400s. The chat is unrecoverable without editing history. Note on the error text: Anthropic reports the wrong index. It says "messages.1" but the id it quotes belongs to a much later assistant message. Match by block id, not by the index in the message. Expected: the web_fetch_tool_result is persisted alongside its server_tool_use and replayed in every subsequent request. Note: the 2.15.0 changelog entry about "Anthropic-powered chats occasionally failing after tool calls when using extended thinking" does not fix this — I'm on 2.15.0 and still hitting it.
In QA
Constant halts using MCP file/directory reads/writes/searches per this:
BoltAI2's MCP file tools are thin wrappers around POSIX file APIs. They're designed for simplicity, not scale. The serializer bottleneck (JSON validation before payload size check) is architectural—it affects ANY tool in this MCP server that uses JSON parameter arrays. The serializer limit is a BoltAI2 server constraint, not a file-tool defect. Even if you swapped the underlying tool, you'd hit the same JSON validation ceiling on the MCP protocol layer. Better Strategy Than Tool Swapping: Instead of replacing BoltAI2's tools, adopt a hybrid workflow: For reads >100 kB: Use ripgrep-based search tools (no size limit on results). For writes >1,500 chars: Pre-split into chunks BEFORE calling edit_file (we're already doing this). For bulk file ops: Use the mcp__directory_tree_17ba7w to get the structure first, then target individual small edits. For escape-sensitive paths with spaces: NEVER use bash; always use the file tool wrappers.
In QA
Bug: Instant chat bar on Mac app enters endlessly looping spasm of thinking and responses
Your OS version. Tahoe 26.4.1 Your BoltAI app version. 2.14.0 (build 77) Are you a Setapp user. No. The AI provider & model you’re using. OpenRouter. DeepSeek V4 Flash. Steps to reproduce the issue. Start a chat with the instant chat bar. See the video below to see what happens maybe ~20% of the time. The error message. NA.
In QA
Error messages about API keys being encrypted
Tahoe 26.6 BoltAl 2 Version 2.14.0 (build 77) Not on setup I get random error messages about wanting a master password because my APIkeys are encrypted. 1) I have not encrypted them 2) Sometimes the same model is working and after restaing Bolt it is not ¯|(ツ)/¯
In QA
Local MCP server 𝐓𝐨𝐨𝐥-𝐂𝐚𝐥𝐥 𝐋𝐨𝐨𝐩 𝐁𝐮𝐠
The hanging behavior is a known technical issue in the integration between the local client application (the chat interface or terminal wrapper) and the LLM API. It is called a Tool-Call Loop Hang. Here is the step-by-step sequence that causes the freeze: AI Initiates Tool: The user requests a file modification or read. The AI generates a tool call (e.g., mcp_edit_file_6lpu9l) and stops generating text, as required by the API protocol. MCP Server Executes: The local MCP server successfully executes the file edit and returns the result (the diff or file contents) to the client application. The Integration Gap (The Hang): In a fully automated integration, the client application is supposed to immediately feed the tool's output back to the LLM to trigger the next text generation turn. However, in this specific client setup, the application fails to auto-trigger the next turn. It pauses and waits. The Wake-Up: Because the client is waiting for the AI, and the AI is waiting for the client to send the tool results, the interface hangs. When the user types any message (e.g., "are you stuck again?"), it forces the client application to package the entire conversation history—including the pending tool results—and send it to the LLM. This instantly wakes the AI up, resulting in the immediate "AI-OK" response. 𝐇𝐨𝐰 𝐭𝐨 𝐅𝐢𝐱 𝐨𝐫 𝐌𝐢𝐭𝐢𝐠𝐚𝐭𝐞 𝐭𝐡𝐞 𝐈𝐬𝐬𝐮𝐞 Client-Side Configuration (Permanent Fix): The developer of the client application or terminal wrapper must update the execution logic. The client must automatically post the tool output back to the LLM API endpoint to request the next completion turn without waiting for manual user input. User Workaround (Immediate Fix): Whenever a tool call completes (you will see the green tool response block in the interface) and the interface pauses for more than 3 seconds, type a single character (such as a period . or go) and press Enter. This forces the client to send the tool results to the LLM and resumes execution instantly. AI Mitigation (Combining Steps): The AI will minimize sequential tool calls where possible, combining reads or edits into single multi-file operations to reduce the number of turn transitions.
In QA
Main window not visible on launch
I have reopen windows when logging in checked during shutdown. But most times, after a restart, the main window doesn’t show when I switch to the app via Cmd+Tab. I believe its the same behavior if I tap on the dock icon. While restarting the app works, it’s starting to get to me since I don’t quit it. Hopefully its a quick fix?
Error on attaching image gemma4
Gemma4 is supposed to be able to read images. But I’m getting Bad request error. Tried in LM studio it is able to generate the markdown of the table with this model.
In QA
Kagi Search Plugin not accepting API key
I have tried to input my Kagi API key in Settings>Plugins>Kagi Search and it will not accept. I have the latest version and have tested on MacOS, both Paid and Setapp, and on the mobile Beta. The error says that Kagi Search API is in Beta but this is no longer true, it is now Public per Kagi support. Desktop screenshot: Mobile screenshot
Dock icon stays visible even when “Hide Dock icon when last window closes” is enabled
Bug report: OS version: macOS 26.5, build 25F71 BoltAI app version: BoltAI 2.13.3, build 72 Setapp user: No. I’m using the standalone app installed at /Applications/BoltAI 2.app. AI provider & model: N/A. This is a window/Dock behavior issue and is not related to an AI provider or model. Steps to reproduce: Open BoltAI 2. Go to Settings > General. Enable “Hide Dock icon when last window closes”. Disable “Show menu bar” because I do not want the menu bar icon either. Close all BoltAI windows, including the Settings window. Do not quit the app. BoltAI continues running in the background, but its Dock icon remains visible. I also tried turning “Show menu bar” back on, toggling “Hide Dock icon when last window closes” off and on again, then restarting BoltAI. The Dock icon still remains visible. Expected behavior: After the last BoltAI window is closed, BoltAI should continue running in the background and the Dock icon should disappear. Actual behavior: BoltAI keeps running in the background, no BoltAI windows are open, but the Dock icon still stays visible. Additional diagnostics: The preference appears to be saved correctly: app.hideDockWhenNoWindows = true System Events reports no open BoltAI windows, but NSRunningApplication still reports BoltAI’s activationPolicy as regular, so macOS keeps showing it in the Dock. Error message: No error message.
In Progress
iOS app high battery/CPU usage
V1.0 build 27 - very high cpu usage resulting in phone (16e) getting noticeably warm
Planned
BoltAI issues due to outdated documentation
OS: MacOS Tahoe 26.5 BoltAI V2 I am having several issues with BoltAI because the documentation appears to be outdated. Google web search does not seem to work given that it no longer supports searching the entire web. Next to that, I can't get any models in BoltAI to perform file operations like Codex does, even though the documentation mentions support for both a Shell and an AppleScript plugin. Neither plugins seem to show up anywhere, no matter which model, cloud or local. Also, the documentation mentions setting a path variable in the settings pane, but I can't find that anywhere either.
Google Deep Research models not working
When connecting through “Google AI” AI Providers and when selecting any Deep Research model there is an error: Error This model only supports Interactions API. I have all MCPs and plugins disabled… all other Gemini models work. https://ai.google.dev/gemini-api/docs/interactions/deep-research i guess you would need to implement an additional api endpoint for this to work?
A delay of BoltAI 2 GUI between app switching on Mac
Another problem which also exists for PDF Pals, is that after a few days running on my Mac, the app switch from other app to BoltAI 2 GUI is slow. There is a significant delay between the action of switch (e.g., by command + Tab) and the BoltAI 2's GUI shows up.
Bug: Agent LLM Parameters not always passed through to chat
Your OS version: Sequoia 15.5 Your BoltAI app version. 2.8.0 (build 55) Are you a Setapp user. No. The AI provider & model you’re using. Google Gemini 3.0 Flash Preview on Google Vertex via OpenRouter. Steps to reproduce the issue. Create an agent and in the agent settings specify Google Gemini 3.0 Flash Preview as the model and set Thinking tokens budget to be non-zero. Create a new chat, set the new agent as the active profile then check the LLM Parameters section in the right sidebar. The thinking budget has not been applied. The error message. No error message.