When I select a connector (MCP / NAS / custom), it stays checked (✓) in the Connectors dropdown, but it never appears as a chip in the composer — the input bar where I type. On send, the model behaves as if no connector is attached and the tool is never dispatched. A Comet browser session that was opened before the regression still dispatches the same connectors correctly, so this looks like a client-side desync between the dropdown selection state and the actual composer attachment, not a server outage.
Reproduction steps
Open a fresh session (any machine).
Open the Connectors dropdown.
Select one or more connectors (e.g. an MCP / NAS connector).
The connector stays checked (✓) in the dropdown, but no chip appears in the composer.
Type a prompt that requires the connector.
Send.
The model responds as if no connector is attached — the tool is never called.
Environment
Occurs in fresh sessions across multiple machines.
Affects standard chats (with and without a Space).
A Comet browser session opened before the regression still dispatches the same connectors correctly.
What I ruled out
Not a network issue: proxy / DNS / TLS all verified.
Not a dangling / broken connector: reproduced with freshly re-added connectors.
Not specific to one connector: reproduced with multiple different connectors.
Not a service outage: status page is green, and pre-regression cached sessions still work.
Related reports
Mac app 26.24.0 (28) – all MCP tools broken and irrecoverable in Spaces (thread 5397) — team already confirmed.
Custom MCP connector fails with ‘did not return a client_secret’ (thread 5172).
Additional note: in my case this also affects chats without a Space, which the existing threads do not cover.
Request
Please investigate the desync between the dropdown selection state and the composer attachment so connectors are actually dispatched on send. Happy to provide a HAR capture or a screen recording (fresh session fails vs. pre-regression cached session works) on request.
I have been suffering this issue with attempts to use Linear and Github. Very frustrating that perplexity itself is unaware of the bug and unable to describe the workaround.
Hey @Viktor_Hadzhiyski, @ckeryakes! Could you please let us know if you are still facing issues with the connectors you mentioned, as the team has been working on it and this should be fixed. They should work properly when you @ tag them in your prompts.
still have the problem. need full restarter to be sure. will check an let you know. Do you need more explanation and screnshots, or you are fully aware what look like the problem?
I get this message when I try:
I don’t have the ability to create or modify issues/PRs directly in your Linear or GitHub from this chat, even with the connectors enabled; my access to those systems is read/assist, not write.perplexity+3
What I can do is:
Draft precise Linear tickets (titles, descriptions, acceptance criteria, labels, assignees) that you can paste into Linear.perplexity+1
Draft GitHub issues or PR descriptions tied to those tickets, so creation is a single copy‑paste step in your repo.perplexity+1
If you share which tickets you want (for example, “Watermarked animal photos V1” and how you want them split across BD/BL/Codex), I’ll write out:
Linear-ready issue text (including status, priority, and labels).
Matching GitHub issue/PR boilerplate for breederdesk or catgenes.
You can then create them in Linear/GitHub with minimal manual work.
It appears that the link is visible in this session, but isn’t actually being passed to the analysis engine. There is likely a session- or client-side desync, causing a new chat to pick it up correctly while the old one does not.
I’m adding my report here because this appears to be the same broader MCP / connector regression affecting multiple contexts.
In my case, the issue started around July 2–4, and Support later confirmed on July 9 that the GitHub MCP / Spaces behavior was a confirmed issue and had been logged with engineering. As of now, the problem is still unresolved. There is no fix, no ETA, and no visible status update showing that it is still actively being worked on.
What is especially concerning is that there has been no visible activity in the related Discord bug threads, and no public acknowledgement or notification that the issue remains open. From the user side, it looks like the reports have gone quiet even though the regression is still reproducible.
The symptoms reported across these threads seem consistent:
In regular chats, GitHub MCP may work normally, while in Spaces it becomes read-only or write tools disappear.
Inline @connector mentions sometimes do not actually attach the selected connector.
In fresh sessions, the connector can remain checked in the dropdown but never appear in the composer and never dispatch.
In some sessions, connector tools disappear after the first prompt or become unavailable mid-conversation.
Similar behavior has been reported for other connectors, including Notion.
The issue appears across web, desktop, and mobile contexts, which makes it look like a broader MCP / connector regression rather than a single connector-specific bug.
At this point, the current state seems to be:
The issue has been known for weeks.
It has been acknowledged by Support.
It is still reproducible.
There is still no fix.
There is still no visible “we’re still investigating this” update in the affected threads.
I would really appreciate one of the following:
confirmation that this is still an open engineering issue,
a short status update, even without an ETA,
a note on whether Discord bug threads are actively monitored for connector regressions,
or guidance on the preferred escalation path for MCP / connector bugs.
I’m happy to provide timestamps, anonymized examples, Space IDs, repository names, and any other reproduction details if needed.
Thank you, Andrew. As noted in my post, I first reported this issue in early July, and Support confirmed on July 9 that the GitHub MCP / Spaces behavior had been logged with engineering.
I also already have an active Perplexity Support Concierge conversation opened on August 4, where I provided a confirmed PC / desktop reproduction case, timestamps, the affected Space/thread, and the related Discord/community reports.
I will follow up via support@perplexity.ai as you suggested and ask them to link the existing July and Concierge reports for triage rather than open a separate duplicate case. Thank you again for escalating this.
I agree that a rollback or restoration of the last known working connector behavior should at least be evaluated, especially if the current regression cannot be resolved quickly.
I have been tracking related connector/MCP failures since early July. In my GitHub MCP case, the connector could identify repositories and return status/SHA metadata while failing to expose decoded file contents to the assistant. This made repository browsing appear partially functional, but blocked reliable code review, debugging, analysis, and safe edits.
I submitted structured reproductions, timestamps, affected-thread links, exact tool output, and environment details to Perplexity Support. The case was reportedly routed to Bug Reports / engineering review, but I did not receive a substantive status update from that team.
The support conversation has now been automatically closed. The automated system stated that the conversation was being closed because it had not heard back from me or because requested follow-up information had not been provided. However, the prior messages in the same email thread explicitly stated that no additional information was required from me, and no specific outstanding question or missing-data request was ever identified.
More recently, I observed a partial recovery: explicitly using a repository in read-only mode can sometimes restore file-text access. However, requesting write operations in the same thread can return the connector to the broken state, including loss of file-content access and, in some cases, failure to retrieve the latest commit SHA.
So the practical question is not only whether a full fix is planned, but whether Perplexity can restore or provide a stable fallback to the last working connector behavior while the regression is investigated. A clear public status update - and a support process that does not automatically close already-escalated reports without identifying a real outstanding request - would help affected users decide how to proceed.