Lovable MCP + Skill Brokered remote MCP connector + enabled skill produces cascading, account-persistent conversation-state failure on web + desktop — two distinct trigger paths converge on the same stuck state

### What happened?

**Environment**

- Surfaces affected: claude.ai (web) and Claude Desktop. Cowork NOT affected (connector never enabled there).
- Desktop version: [Most current as of 06-02-2026] / Web: [Chrome + most current cersion] / OS: [Mac + Windows]
- Connector: official Lovable remote MCP (OAuth, brokered, full-account scope)
- Skill: org-distributed skill invoking the Lovable connector, enabled across multiple users
- Model: [Opus (mix)] / Incident window: [06-02-2026]

**Summary** On instances with both the Lovable remote MCP connector and an org-distributed skill enabled, web and desktop conversations entered a progressive failure state: "Conversation not found"; "A previous response is still running in this conversation. It will appear shortly — try again once it finishes."; and "Your message was sent, but Claude couldn't respond — try again." Failures spread slowly and user-by-user, confined to connector+skill instances. Standard remediation (reconnect connector, switch model, new conversation) did NOT clear state. Recovery required full teardown: delete connector → uninstall skill → log out → hard-close → relaunch.

**Two trigger paths identified (both converge on the same stuck backend state)**

1. _Synchronous-timeout path (bare sessions):_ the skill's default `send_message` call is synchronous (`wait=true`). The Lovable agent builds real code and frequently runs long. The brokered connector's hard tool-call timeout (documented 300s; observed in our environment cancelling as early as ~30s under load) kills the call mid-build, leaving the generation in a "still running" backend state.
2. _Per-turn tool-call path (in-Project sessions):_ these sessions correctly used `wait=false` (avoiding the timeout) but, per their orchestration, issued multiple `send_message` calls in a single turn. This collides with the documented failure where **3+ sequential MCP tool calls in one turn drop the response** ("Claude's response could not be fully generated"), leaving builds in-flight that the conversation never reconciles.

The common downstream symptom is a conversation whose new-session initialization is gated behind an unresolved/orphaned prior generation — surfacing as "Conversation not found" and "previous response still running."

**Why the cascade was gradual and selective** The connector is full-account scope and the skill is org-distributed, so the failure pathway was replicated to every user it was pushed to. Each instance degraded independently as it crossed one of the two thresholds; staggered usage produced the slow, user-by-user spread (replication, not contagion).

**Expected behavior** A long-running or multi-call brokered MCP interaction should fail in a contained, recoverable way — surface an error and allow a new conversation to start — without leaving account-scoped backend conversation state in an unrecoverable condition, and without a hard per-turn limit of ~2 MCP calls silently dropping responses.

**Confirmed vs. inferred**

- _Confirmed:_ brokered cloud origin (no local subprocess); the 300s connector timeout; `send_message` is long-running by design; the 3+-calls-per-turn response drop is reproduced; brokered tool calls can return server-side 200 while erroring client-side; backend conversation-state loss is a documented recurring fault.
- _Inferred:_ that timeout-orphaned and multi-call-orphaned generations are the specific cause of _these_ error strings. "Conversation not found" and "previous response is still running" are **undocumented** strings; their exact backend cause is reasoned, not vendor-confirmed.

**Related issues (pattern match)**

- #43642 — 3+ sequential MCP tool calls drop the response (per-turn path).
- #154, #207, #227 — brokered remote-MCP failures (200 server-side / opaque client error / broker start failures).
- #33130 — server-side conversation data loss; new conversations vanish; "accepts input, no response."
- #29971 / #28660 / #20412 — context bloat, O(n) skill injection per tool call, claude.ai MCP auto-injection.

**Impact** Workflow-blocking; lost/unrecoverable conversations; required full client teardown. Multi-user blast radius via org-distributed skill.

**Requesting**

1. Server-side investigation of conversation/session state for account/org [available upon request] during [06-02-2026] — not diagnosable from local logs.
2. Confirmation of what happens to backend conversation state when a brokered call (a) exceeds the timeout or (b) is dropped by the 3+-call-per-turn failure.
3. Consideration of a contained-failure path (per-conversation cancel / stuck-generation reaper) so an orphaned generation cannot block new-session initialization.

**Available on request:** conversation UUIDs, timestamps, account/org ID, skill manifest, connector config (secure channel).

### What did you expect to happen?

The MCP to not crash Claude instances?

### Steps to reproduce

See following URL for setup:

https://docs.lovable.dev/integrations/lovable-mcp-server

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

https://mcp.lovable.dev

### Error messages or logs

```shell
"Conversation not found" - main issue; could not start or continue any chat sessions
"Conversation still running [...]" - observed only after partial fixes were attempted
```

### Additional context

The above report should contain all necessary info - please reach outc for further info if needed