Project context not reachable through MCP

Ask us anything Tips and Hacks
1

Hey,

tried to use MCP several times and getting the same error in ChatGPT:

The WeWeb MCP connection is reachable and the target workspace/project exists, but the MCP session did not preserve the active project after switching, so page inspection could not be completed.

Could anyone be able to use MCP?

image
image627×249 13.1 KB

image
image1480×1285 59.2 KB

2

UPD: it does work through Codex, but it doesn’t work in ChatGPT no matter how many times I reconnect MCP.

3

yeah, i also experienced it a bit working with vs code at some point, it works well in Claude chat but kind of acts up when i use claude in vs code.

4

Hi everyone @Batik_Okazov @iconic

Yes, indeed, there is a known issue with the MCP server and Chat GPT at the moment. Our team is investigating this with priority and we hope to fix it asap. We will keep you posted. Thanks for the patience!

5

It stopped working in Codex too

image
image1405×504 25 KB

6

Adding another case to confirm this is still happening after the topic was marked solved — this is “additional details,” since the bug is still occurring.

Third independent client now affected: Claude (Anthropic MCP client). So it’s reproduced across ChatGPT, Codex (per @Batik_Okazov), and Claude — which points to a server-side session issue rather than anything client-specific.

Same symptom on a production project: switchProject returns “Switched to project” successfully, but the very next project-scoped call (searchVariables, getPageSemantic, createVariable, editElement, editElementWorkflow, etc.) immediately fails with:

No active project on this MCP session. Call listWorkspaces, switchWorkspace, listProjects, then switchProject to select one before using this tool.

Two details that may help pin it down:

  1. The binding is lost at the workspace level, not just project. This matches @Batik_Okazov’s screenshot exactly — switchProject/switchWorkspace return success, but the next call reports “No workspace selected” / “No active project.” So the successful switch response isn’t actually persisting the workspace/project selection into the following request’s session state.
  2. It’s an intermittent loss that becomes sticky. Earlier in the same session a handful of project-scoped write calls (editElement / editElementWorkflow / editPageWorkflow) succeeded, then the session degraded and never recovered — re-running switchProject doesn’t fix it, only a brand-new MCP session does.

Account is workspace owner, hasMcpAccess: true, and the project shows correctly under getMe.

Any client-side mitigation while the fix ships (keep-alive call, mid-session re-bind, reconnect cadence)? And is there a rough ETA? Happy to provide session IDs/logs if useful.

7

Hey there :waving_hand:

Not sure why the topic was marked as solved. I think it may have just been in response to Daniel acknowledging it’s a known issue the team is working on.

So, to clarify:

  • yes, the solution is that the team is working on it
  • no, the issue is not solved yet

I removed the “Solved” tag to remove the confusion.

8

yes, indeed. Thanks for removing the tag.

9

Hey again!

Just got an update from the team: the issue should be fixed with the next release. ETA next week :slight_smile:

10

Hey there :waving_hand:

This should now be fixed. Could you create a bug ticket here if you still encounter issues with the MCP so the team can investigate?

11

Yes, it seems fixed. I was able to connect to my project. Thank you