Help me improve BoltAI

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

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.

Rui 4 days ago

🐛

Bug Reports

Extremely high energy usage.

When I put a discussion in the trash, a loading indicator appears on the navigation bar. However, when this indicator is active, it triggers a massive energy consumption spike and significant overheating. The issue goes back to normal when I hide the navigation bar and then make it reappear. OS Version : 26.5.1 BoltAI Version : 2.13.2 (Build 71) Are you a Setapp user : No Provider AI : Crof.AI Model : DeepSeek Pro V4 Steps to reproduce the issue : Open the application and navigate to any discussion page. Move the/a discussion to the trash. Observe that a “Loading…” indicator. Do not interact with the navigation bar — let the loading indicator remain active for several seconds. Notice the device starts overheating and the battery drains rapidly due to increased energy consumption. To temporarily resolve the visual/performance issue: Hide the navigation bar. Then make it reappear. Observe that the loading indicator disappears and the device returns to normal temperature/power behavior. You can see the video for more details.

Valentin Arnould 9 days ago

1
🐛

Bug Reports

Extremely high energy usage.

When I put a discussion in the trash, a loading indicator appears on the navigation bar. However, when this indicator is active, it triggers a massive energy consumption spike and significant overheating. The issue goes back to normal when I hide the navigation bar and then make it reappear. OS Version : 26.5.1 BoltAI Version : 2.13.2 (Build 71) Are you a Setapp user : No Provider AI : Crof.AI Model : DeepSeek Pro V4 Steps to reproduce the issue : Open the application and navigate to any discussion page. Move the/a discussion to the trash. Observe that a “Loading…” indicator. Do not interact with the navigation bar — let the loading indicator remain active for several seconds. Notice the device starts overheating and the battery drains rapidly due to increased energy consumption. To temporarily resolve the visual/performance issue: Hide the navigation bar. Then make it reappear. Observe that the loading indicator disappears and the device returns to normal temperature/power behavior. You can see the video for more details.

Valentin Arnould 9 days ago

💻

Feature Requests

Support Gemini 3.1 and 3.5 Flash for Google Vertex AI Provider

Problem Currently, the Google Vertex AI provider in BoltAI is missing recent models, such as the Gemini 3.1 series (including 3.1 Pro Preview) and Gemini 3.5 Flash. Additionally, other non-Gemini models offered through Vertex AI are not supported. Because the AI models evolves rapidly, it is difficult to maintain and update a hardcoded list every time a new model is released. Proposed Solution Add Gemini 3.1 Pro and 3.5 Flash next release for a quick fix. For the long run, add a custom "Model ID" input field within the Google Vertex AI provider settings. This would allow users to manually enter the exact ID of the language model they wish to use. Benefits This approach future-proofs the integration. Instead of waiting for Daniel to release an update with a new model, users can instantly access the latest models (like Gemini 3.1 Pro Preview and 3.5 Flash) or any other supported Vertex AI model simply by entering the corresponding model ID.

Anıl Yuvalı 12 days ago

1
💻

Feature Requests

MCP tool input schemas are stripped of type/enum/default — some properties sent as empty {}

When forwarding MCP tools to Claude/Anthropic, BoltAI appears to apply a lossy transformation to each tool's input_schema, dropping type information that the MCP server provides: Several properties are emitted as empty schemas with no type, e.g. "query": {}, "continuation": {}, "channel": {}, "playlist": {}. Properties that have enum/default in the source schema lose them — e.g. format is sent as {"type": "string"} instead of {"type": "string", "enum": ["json","text"], "default": "text"}. This is valid JSON Schema ({} matches any type) and is accepted by the API, so it's not a hard error — but it's a quality regression. With no type, the model has to guess the expected argument type, which reduces tool-call reliability (malformed or wrong-typed arguments). Dropped enum/default values remove guidance the model would otherwise use. Confirmed by comparison: another client (not named) hitting the same MCP server forwards the full schemas intact — typed properties plus enum and default values — while BoltAI's version is stripped down. This points to a transformation in BoltAI's MCP→Anthropic schema handling rather than the MCP server's output. Request: forward the MCP server's tool inputSchema unchanged — preserve each property's type, enum, and default.

David 14 days ago

🐛

Bug Reports

in BoltAI - MCP tool names use single-underscore mcp_ prefix → Anthropic rejects Claude (OAuth) requests with HTTP 400

When a Claude/Anthropic request includes MCP tools, BoltAI names them mcp (single underscore, e.g. mcpsearch_youtube_z50gm8). Anthropic classifies any tool whose name starts with mcp (single underscore) as a third-party MCP tool and bills it to "extra usage," returning: 400 invalid_request_error: "Third-party apps now draw from your extra usage, not your plan limits…" On accounts with extra usage disabled, every MCP-tool request fails. Claude Code's own convention is a double underscore — mcp — which Anthropic accepts as first-party. Verified fix: renaming mcpsearch_youtube_z50gm8 → mcp__search_youtube_z50gm8 (only change: one extra underscore) turns the 400 into a 200. Requests without tools, or with tools that don't use the mcp prefix, already work. Request: name MCP tools with the mcp__ double-underscore convention. Tried it with https://github.com/router-for-me/CLIProxyAPI and https://github.com/automazeio/vibeproxy (and used in AI Providers - Anthropic endpoint and pointed it to CLIProxyAPI)

David 14 days ago

4
💻

Feature Requests