Mac app 26.24.0 (28) – all MCP tools broken and irrecoverable in Spaces

Bug Reports
1

Environment
• Platform: macOS (Perplexity desktop app with Personal Computer / MCP enabled)
• App version: Perplexity Version 26.24.0 (28)
• Setup: Spaces with MCP tools for filesystem/bash ( bash_execute , read_file , osascript , etc.).
Issue
Immediately after updating to 26.24.0 (28), every MCP tool in my Space stopped working. This includes:
• Shell commands via the bash tool (even trivial ls /tmp or listing the repo root)
• File reads via the read_file tool (even small local markdown files in the workspace)
• osascript‑based tools (simple System Events queries)
All calls return generic tool errors. No tools succeed, regardless of command or target path. Prior to this update, the same Space and tools worked and powered a fully automated “morning triage” workflow that reads from /tmp and my local repo. After the update, that workflow is completely blocked because the agent cannot access any local files or run any shell commands through MCP.
What I’ve tried
• Fully quit the Perplexity Mac app (Cmd+Q) and reopened
• Logged out and back in
• Started new chats in the same Space
• Verified Perplexity processes and helper ( Perplexity , Perplexity Helper , external MCP servers) are running via ps
• Confirmed that the commands and file paths themselves are valid when run directly in my terminal
None of these steps restored MCP tool functionality. The failure is consistent across all MCP tools and all calls.
Expected behavior
• MCP tools should be able to execute shell commands and read local files, as they did before the update.
• Existing Spaces that rely heavily on MCP (e.g., scripted Jira triage and filesystem automation) should continue working after upgrading the Mac app.
Actual behavior
• Every MCP tool call fails, including minimal smoke tests like ls /tmp or reading a known local markdown file.
• The agent cannot access any local files or run any shell commands through MCP, making automation‑heavy workflows unusable.
Impact
• Blocks daily QA workflows that depend on MCP connectors (e.g., automated morning Jira triage, file‑based reporting, scripted comments).
• From the user’s perspective, this looks like “all MCP connectors are broken and irrecoverable” after updating to 26.24.0 (28).
Request
• Please investigate whether 26.24.0 (28) introduced a regression in the Mac app’s MCP bridge for Spaces.
• If reproducible, consider publishing guidance or a hotfix, since teams relying on MCP‑driven workflows may want to avoid this build until it’s resolved.

2

Thanks for reporting this, @E1255264_PNR! The team is aware of this issue and is working on a fix.

4

I guess it is now fixed with the new updated release?

5

Good morning, in reality the update has only partially solved the problem.
Now the files can be accessed, but there are no write permissions.
So the bug has not been properly fixed as of today.

6

I have a similar issue, when updated to 26.24.0 (28), write permissions were broken when discussing in “chat” mode (not computer mode). With 26.25.0 (37), the behavior has changed. The problem now seems to be the attached workspace folder itself: the folder is correctly attached to the Space, but as soon as I start a new discussion/thread, the attached folder disappears from that thread.

7

I’m experiencing the exact same issue in the browser (not just on Mac app).

I have custom MCP connectors (e.g. GitLab) configured for internal company workflows. After a recent update:

  • In the first message of a new chat thread, the connector is visible and works.

  • In all subsequent messages in the same thread, the connector UI disappears and the connector is no longer dispatched.

This completely blocks use of MCP in ongoing conversations and makes multi-step workflows impossible.

Is this a known regression on the web side as well? Any workaround or expected fix timeline?