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?

8

Same problem here too even on the webapp

9

Where can I see priority fixes? This is for me essential for my Perplexity usage: I’m considering asking refund for my whole company

10

It’s been months now that I pay perplexity max for nothing!
I hoped they fixe it but they never did.
It’s the most needed feature for my work and the perplexity team don’t even bother replying to max users.
I will for sure ask for refund in the week, this company obviously don’t care about its paid users as its a core feature of their app and it doesn’t work for months

11

Same issue here on Mac desktop. Full Disk Access granted, project folder correctly attached to the Space, but write permissions remain completely blocked. Reads appear to work intermittently but any attempt to write to local files fails. The workaround of having the agent output content for manual paste is not a viable long-term solution for automation workflows.

This is a core feature for paying subscribers. Please prioritize a proper fix, it’s been months.

12

Plz fix this. It is strange to limit such a key functionality to the (much) more expensive branch of the service (=computer), which creates the strange impression that you can do it, but do not want to it to push ppl into using computer…
Hence, it is not only a bug, it is also a PR issue :wink:

13

Full Disk Access granted, write_file/edit_file approved for workspace, read works, write blocked, version 26.31.1

14

Having the same issue here. Stopped working after recent update. Its frustrating the documentation is ambiguous Local and Remote MCPs for Perplexity - Perplexity Help Center

Summary

The local Filesystem MCP connector (@ modelcontextprotocolmodelcontextprotocolmodelcontextprotocolmodelcontextprotocol/server-filesystem) that previously worked in the Perplexity Mac app is gone after the v26.42.0 update (Oct 21, 2026). The GUI only exposes URL-based MCP connectors; there is no command/stdio option for local servers. The required helper daemon (perplexityd / PerplexityXPC) is not auto-installed on clean install or first launch.

Timeline

Before Oct 21, 2026: Local Filesystem MCP connector worked in the Perplexity Mac app

Oct 21, 2026: Perplexity.app updated to v26.42.0

Oct 25, 2026: User discovered Filesystem connector missing Environment macOS 26.2 Perplexity.app 26.42.0 at /Applications/Perplexity.app Node/npx: v26.11.1 / 11.20.0 via Homebrew at /opt/homebrew/bin/

Expected Behavior and what i found

Per the official Help Center: Local MCP connectors should be addable via Plugins → Add custom → Simple tab with a c@ modelcontextprotocolmodelcontextprotocolmmand (e.g. npx -y @ modelcontextprotocol/server-filesystem ~/.agents)

The PerplexityXPC helper should be installed so Perplexity can securely connect to local MCP servers After adding, the connector should show status “Running” and be toggleable under Sources Actual Behavior perplexityd is not running after clean install; not in launchctl list; not found anywhere on disk via find / -iname ‘perplexityxpc’

Helper binary is bundled inside the app but not registered as a LaunchAgent and not started automatically GUI only shows URL-based connectors; “Add custom connector” modal has an “MCP server URL” field only, no command field No helper instal@ modelcontextprotocolocal prompt appears on first launch, co@modelcontextprotocoltrary to documentation @ modelcontextprotocolocal MCP server works manually: npx -y @ modelcontextprotocol/server-filesystem ~/.agents outputs Secure MCP Filesystem Server running on stdio and responds to JSON-RPC initialize with valid result

Evidence

Manual MCP server test works — valid JSON-RPC initialize response received perplexityd process: absent Helper binary in app bundle: present but not installed as LaunchAgent

15

Ran into this issue today with the latest build as well. Only updated a few days ago, but prior to that the tool was working well. If this is an intended deprecation of a feature, then as someone else pointed out it defeats paying for this service. Yes, the overpriced Perplexity Computer option still exists, but I paid for my Perplexity subscription in no small part due to the presence of this feature.

I was able to establish the following technical details about the current issue:

The application logs the following when attempting to use the local MCP tool..

00:56:18.334 I  [ai.perplexity.macv3:ToolFilteringPipeline] 

00:56:23.160 I  [ai.perplexity.macv3:MCPToolsProvider] 

00:56:23.163 Db [ai.perplexity.macv3:MCPExecutionContextStore] 

00:56:23.428 E  [ai.perplexity.macv3:default]

Perplexity’s own analysis of this issue:

  • MCP-related code is executing inside the app. Both MCPToolsProvider and MCPExecutionContextStore produce log entries. This is evidence against the broad claim that all MCP code has simply disappeared, but it doesn’t establish that local MCP support is working or enabled.
  • A component named ToolFilteringPipeline is active. Its message is hidden, so the log does not reveal which tools it considered, whether it excluded anything, or why. Its name alone is not evidence of intentional blocking.
  • perplexityd is running and making network requests. The capture contains successful HTTP responses from it, so a blanket “the daemon isn’t running” explanation does not fit this capture. That still doesn’t prove its local-tool connection is healthy.
  • There is no visible deprecation explanation. I found no literal deprecated , unsupported , bash_execute , tools/list or PerplexityXPC in the supplied text. The hidden messages prevent treating those absences as definitive.

PS. Verified that local file access still works via Perplexity Computer, so this issue is very much specific to Perplexity Search.

16

Further update to the investigation above (generated by Perplexity itself):

How it appeared when it worked

The earlier calls in this thread used:

Callable tool: functions.mcp_tool_1_bash_execute

Server label: LOCAL_MCP

MCP tool name: bash_execute

The tool accepted a tool_args object containing fields such as command , working_directory , timeout and stdin . Its returned metadata explicitly identified LOCAL_MCP as the server and bash_execute as the MCP tool.

Those are the identifiers visible in the conversation—not a server URL, launch command or configuration-file entry.

How connectors are exposed to me now

The current interface offers this discovery-and-call sequence:

list_external_tools

→ source_id and available tool names

describe_external_tools

→ tool input schema

call_external_tool

→ execute the selected tool
17

@andrewmadson-pplx I was wondering if anyone at Perplexity had noticed this thread and was now looking into this, or what is the current situation around this, please? As you can see this has become one of the most popular threads in this category and with amongst the largest number of views, too.

18

Same here. Tried to migrate from Claude Desktop to Perplexity.app 26.43.0 (direct download, not App Store), macOS on an M5 Mac Studio.

The helper perplexityd is installed and running ( Contents/Library/LaunchAgents/Perplexity Helper.app ), but Plugins → Add custom only shows “MCP server URL”. There’s no Simple tab or command field. The stdio servers (mcp-remote wrappers) run fine from Terminal.

The help center article still describes the Simple/command flow.

Is local MCP still supported in the direct-download app, and is a fix planned?

19

Looks like they do not care about it, the issue is running months already. Also the GUI is still with the same rendering issues, supper laggy from chats rendering for a year already.

Honestly, even open source has better community management :stuck_out_tongue:

but yeah, buy more credits, that would ring them a bell.

It is time to just jump straight to Claude alone now…

20

Temporal solution

A workaround that might help getting the MCP filesystem connector back alive:

(shared from Discord user あ @a_un from perplexity’s server)

Requisites: Supergateway and ngrok

Perplexity Mac app
↓ HTTPS requests with API key authentication
ngrok
↓ Encrypted tunnel to the local ngrok
agent
↓ Local forwarding to http://127.0.0.1:8001/mcp
Supergateway
↓ Validates the API key
↓ stdio Serena MCP
↓ Started with a specific project

Supergateway converts the local stdio MCP server to Streamable HTTP, and ngrok provides a public HTTPS URL that you can add as a URL-based MCP connector. API key authentication is handled by Supergateway. I tested the public /mcp endpoint, and both requests without a key and requests with an invalid key returned 401 Unauthorized. This works around the missing command/stdio option, but it isn’t a replacement for native local MCP support: traffic goes through ngrok, and the endpoint is publicly reachable, so authentication is important. One caveat for Serena: selecting a project with --project does not sandbox it to that directory, especially if shell execution is enabled.

So, in a nutshell, the steps:

  1. Setup Supergateway and ngrok
  2. Inside Perplexity.app GUI
    1. Settings > Apps tab > Connectors section > “Manage your connectors in Plugins” > “Add custom +” button
    2. Connector submenu > “+Add MCP connector”
    3. Use the configs you used in ngrok to bridge the Supergateway server
    4. Done
21

The URL-only connector UI in current direct-download builds suggests the old Simple/command field was removed from the GUI, not that all MCP code is gone. That also explains why the stdio wrappers work in Terminal but not in the app: the app now expects an HTTP/SSE endpoint. Supergateway is the practical bridge, but keep it authenticated and avoid leaving an unauthenticated public tunnel open. Until Perplexity confirms otherwise, treat the help-center Simple/command instructions as stale.