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.