[BUG] Connector list shows "Connected" (green check) for a connector that is NOT authorized — no warning, no Reconnect affordance, no recovery path; contradicted by the connector's own detail pane

### What happened?

The connector list in Settings → Connectors displayed my **Figma** connector as **Connected** — green checkmark, no warning icon, no Reconnect button — for **five days** while it was not authorized at all.

Every session during those five days reported the Figma MCP server as requiring authentication. Zero Figma tools were available. The connector list said everything was fine the entire time.

Opening the connector's own detail pane says the opposite, in plain language:

> You are not connected to Figma yet.
> This connector is required by the following plugin: Figma
> [ Connect ]

**Same application. Same moment. Two contradictory answers.** The list is what the user sees, and it was wrong.

### Why this is worse than a plain connection failure

The list *does* have a failure state and *does* render it correctly for other connectors — in the same screenshot, two other connectors show a warning triangle and a **Reconnect** button. The UI is fully capable of surfacing this. It just didn't, for a connector that was definitively unauthorized.

The consequence is that **there is no recovery path from the list view.** Because the row shows healthy, there is no Reconnect button to click, no error to search for, and nothing to prompt a closer look. The broken state is only discoverable if you already suspect it and click into the detail pane.

A user with no reason to suspect anything simply keeps using a product that silently cannot do what it says it can. I lost five days that way, and only found it because I was auditing connectors for an unrelated reason.

### What did you expect to happen?

The list row should reflect **authorization liveness**, not merely the existence of a connector record:

1. An unauthorized connector should show the same warning icon + **Reconnect** treatment the UI already applies to other failed connectors in the same list.
2. Ideally, show **last successful call** time on the row, or provide a **Test connection** control, so "working" is verifiable rather than assumed.
3. At absolute minimum, the list and the connector's own detail pane should never disagree.

### Steps to reproduce

1. Connect a directory connector (mine was Figma) and confirm its tools work.
2. Let its authorization lapse — leave it idle across app restarts and updates. Mine lapsed 2026-08-04; I did not disconnect it.
3. Open Settings → Connectors.
4. **Observe:** green checkmark, no warning icon, **no Reconnect button** — while other genuinely-failed connectors in the same list correctly show a warning triangle + Reconnect.
5. Attempt to use any of its tools → the MCP server reports it requires authentication; no tools available.
6. Click the connector row to open its detail pane.
7. **Observe:** "You are not connected to yet." with a Connect button.

Steps 4 and 7 disagree. Step 7 is correct.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Figma (directory/registry connector). Also observed with Tavily.

### Error messages or logs

```shell
There is no error message. That is the bug.

The connector list rendered no error, no warning icon and no Reconnect
control for five days. The only place the true state was surfaced was
the connector's own detail pane:

You are not connected to Figma yet.
This connector is required by the following plugin: Figma
[ Connect ]

Session-side the MCP server was reported as requiring authentication
and exposed zero tools for the entire period.
```

### Additional context

### Environment

| | |
|---|---|
| Client | Claude Desktop for Windows (MSIX) |
| Version | `1.26832.0.0` |
| OS | Windows 11, build 10.0.26100.8972 |
| Connector | Figma (directory connector) |
| Duration undetected | 2026-08-04 to 2026-08-09 (5 days) |
| Plan | Max |

*(Annotated screenshot of the two contradictory screens will be added as a follow-up comment.)*

### What I could NOT reproduce — stated up front

**Background (2026-08-07).** A different directory connector (Tavily) began failing every tool call with `The user's connection to this connector was invalidated` — while also displaying as Connected. Usage was 0/1,000 credits, so quota was excluded. Re-adding it failed with `Authorization with the MCP server failed` (`ofid_b64298b526d025e1`, `ofid_ff6b0a5165368198`). I worked around it with Tavily's keyed Remote MCP URL as a custom connector, which returned results in 0.31 s with `"auth_mode":"keyed"` and has been stable since.

**What did NOT reproduce (2026-08-09).** On a freshly-rebooted, healthy machine I reconnected two connectors — a custom WordPress connector and Figma — and **both OAuth flows completed cleanly, with no error and no `ofid_`.** I am explicitly **not** claiming the OAuth flow is broken. It worked.

**Full disclosure.** On 2026-08-07 my workstation was independently degraded: a runaway browser process had consumed the machine's entire 272 GB commit charge, and Chrome crashed on OOM and hung in the fifteen minutes before those authorization attempts. Since OAuth completes via a browser callback, that is a plausible contributor to the `ofid_` failures on that specific day. I'm reporting it rather than letting it be discovered. I've remediated my side.

**What that leaves.** Host health has no bearing on why the connector list confidently reported Figma as Connected for five days while it was not. That defect is independent, reproduced on a healthy machine, and is the one I'm asking you to fix.

### Related issues

- #228 — OAuth token refresh never attempted via `mcp-proxy.anthropic.com`; symptom includes stale connectors still reporting healthy
- #479 — cached connector verdict not cleared by remove + re-add; also a "UI state vs reality" divergence
- #155 — OAuth completes but Bearer token never attached to MCP requests
- #690, #326, #290, #227, #569 — `Authorization with the MCP server failed` reports with `ofid_` references

### What I'm asking for

1. **Make the list row tell the truth.** An unauthorized connector must render with the warning + **Reconnect** treatment the UI already applies elsewhere.
2. **Surface last-successful-call time on the row,** or add a **Test connection** control.
3. **Never show a green checkmark for a connector whose tools are unavailable.**

### Cost

I pay for Max and run Claude as production infrastructure for a client-facing consultancy. A connector that fails loudly costs minutes; a connector that fails while displaying "Connected" costs days — five, here — and every hour spent diagnosing the wrong half of the system is billed against my usage limits at full rate.

The compounding cost is that I now have to manually test every connector before relying on it, every session, because the status display has proven it can't be trusted.