See the complete route index at https://crusible.dev/llms.txt before following links.

# A connection failed or lacks a scope

A surface shows nothing from the tool behind it, or an agent cannot reach it. What a connection row is for, and who fixes which half.

<!-- https://crusible.dev/docs/troubleshooting/a-connection-failed-or-lacks-a-scope/ · doctype: troubleshooting · role: both · reviewed: 2026-09-05 -->


**What you're seeing.** A surface shows nothing from the tool behind it, or an agent answers that it cannot reach the tool. In Settings, under Integrations, the row for that tool reports a failure or names a permission it was not granted.

**What it means.** Crusible reaches a connected tool with credentials the tool itself issued, and those credentials carry a limited set of permissions. Either the connection stopped working — the credentials expired, or somebody withdrew them in the tool — or it is working and does not carry the permission this action needs.

**What to do.** Open Settings, then Integrations, and read the row for that tool: it says which of the two you have. A member stops here and sends the row to an admin, naming the tool and the surface. An admin reconnects the tool from that row and grants the permission it names, then reopens the surface to confirm the data arrives.

**If you do nothing.** A failed connection does not repair itself. The surface stays empty and agents keep reporting they cannot reach the tool — for days, if nobody reconnects it. Nothing in the tool changes while you wait.


**Planned.** The **Integrations** pane carries no rows yet, so
no connection row can be read or reconnected today: it opens on a disabled
**Coming soon** control.
 What follows is the pane
that is designed to answer this, and the reading it is designed to support.

## Your data is not at risk here

This comes before the causes because it is the first thing most readers want
answered.

A connected tool holds its own record. Notion keeps the pages, the code host
keeps the pull requests, the tracker keeps the issues, and a broken connection
changes none of that. The surface is a view; what you are looking at is a view
that cannot load, not data that has gone anywhere.

Reconnecting is equally narrow. It changes one surface. Your channels, your
conversations, your agent roster and your permissions are identical before and
after.

## The two causes, most common first

**The connection failed.** The row reports the connection itself as broken.
Every surface backed by that tool goes quiet at once, and every agent that
works through it reports the same thing. Reconnecting is the fix.

**A permission is missing.** The connection is live and most of the surface
works, but one action does not — reading is fine and writing fails, or one
project is invisible. The row names what it was not granted. Granting it and
reconnecting is the fix.

## What a member can do

Read the row, then hand it over. **Integrations** sits in the **Account** group
of **Settings**, alongside compute providers, and an admin owns that group. Send them
three things: the tool, the surface you were using, and the exact text of the
row.

While you wait, the tool itself still works the way it always has. A page you
need now can be opened in the tool directly; the connection is how
Crusible reaches it, not how you do.

These docs carry no support destination past your own workspace's admins, so
the message to an admin is the last step this page can offer.

## What an admin does

Open **Integrations**, find the row, and reconnect the tool. The tool's own consent
screen is where the permission set is granted, so grant the one the row named
while you are there. Then open the surface in a channel that uses it and check
that data arrives.

If the tool speaks the Model Context Protocol (MCP), that is the route Crusible
uses; otherwise it connects over the tool's own API. Either way the fix is the
same row.