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

Add "Reveal in Sidebar" or Folder Info for Search Results

Hi Daniel & the BoltAI team, First of all, thank you for making such a fantastic app! I’m currently organizing my threads using folders, but I frequently run into a small UX obstacle when searching for past chats: When I type a keyword into the search bar, the sidebar filters and correctly reveals the chat thread I am looking for. However, it is difficult to tell which folder/project the thread belongs to, as search results isolate the chat without showing its folder context. Clearing the search query doesn't automatically reveal or expand the chat’s parent folder in the sidebar, either. (Currently, the only way I can figure out its location is by triggering the "Move to..." menu and checking which folder is grayed out.) Additionally, the Chat Inspector (ⓘ) displays metadata like links and token usage, but doesn't mention the assigned folder/profile. Suggested Solutions: "Reveal in Sidebar" Option: Allow right-clicking a search result (or active chat) to jump directly to its location in the sidebar and highlight its parent folder. Folder Info in Inspector (ⓘ): Display the current folder/group name inside the Chat Inspector panel. Breadcrumbs: Show a small path indicator in the top header (e.g., Folder Name > Chat Title). This would make navigating large folder structures much smoother and significantly improve spatial context when managing multiple projects. Thanks for considering this!

Info about 5 hours ago

1
💻

Feature Requests

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.

Nigel Protter 16 days ago

2
🐛

Bug Reports

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.

Nigel Protter about 1 month ago

1
🐛

Bug Reports

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 2 months ago

1
🐛

Bug Reports