Connect a provider
Where an outside tool is connected to the surface it backs, how it is authorised, and what settles the writes agents may make to it.
What you'll have
Knowing how one provider comes to back one surface, and where the record sits once the tool your team already uses holds it.
A provider is the tool behind a surface: Linear behind Issues, Notion behind Docs, Sentry behind Dashboards, GitHub behind both Forge and Review. Connecting one is a workspace-level action, done once by an admin, and it decides where the record of that work lives. A tool that backs two surfaces backs both of them from the one row, so read what a row names before you connect or leave it.
Planned The Integrations pane carries no rows and no
Connect control yet: it opens on a blurred picture of the pane, the sentence
Connect GitHub, Linear, Slack and the rest, and keep their keys in one place.
and a disabled Coming soon control.
The steps
below are the procedure that pane is designed for, and none of them can be
carried out today.
Select Settings, then, under Account, open Integrations.
Result The pane opens on the tools a workspace can connect, grouped by what they are for: source control, project management, communication, monitoring, and the model provider behind the agents. A connected row reads “Connected” and names the account it was authorised as; an unconnected row carries a “Connect” button.
Find the tool you are connecting, under its category.
Result Each row names the tool and what connecting it does in one line — “Sync repos, issues, and pull requests”, “Create and track issues from the terminal”. That line names the work the tool backs.
Select Connect, and authorise Crusible as the account you want the workspace to act as.
Result Authorisation happens in the tool, as that tool's own account, and returns to the pane. The row then reads “Connected” and names the account.
Open a channel that has that surface enabled, and select it in the surface switcher.
Result The surface now reads from the tool rather than from Crusible's own store, and the tool stays the record: work opened there appears here, and work opened here appears there under the account you authorised.
Open the channel’s settings and read the Access rows: Agents may push to the branch, Agents may open pull requests, Agents may merge without a human and Agents may reach production. Which of them start on is in what agents can see and do .
Result Those four rows are what an agent may do with the connection you made. A connected provider does not widen them, and neither does connecting a second one.
If this doesn't work
If Account does not appear in Settings, or Integrations is missing from it, your sign-in does not hold the permission that opens it: a pane you may not open is absent rather than shown and disabled, so ask whoever created the workspace to grant it. If the row returns from authorisation still reading its Connect button, the authorisation did not complete in the tool — start it again and finish it in the tool’s own window. If the row reads Connected but the surface shows nothing, check that the account you authorised can see the project, repository or workspace you expected on the tool’s side; a connection carries exactly the reach of the account behind it. If the surface is not in the channel’s switcher at all, it has not been enabled for that channel, which is in the channel’s own settings rather than here. If a step still does not match what you see, Troubleshooting is written for that moment.
One surface in the workspace is then backed by the tool your team already uses, and the row in Integrations is the record of it: the tool and the account it was authorised as. Everything else is unchanged — the conversation is still the spine of the work, and what agents may write is still the channel’s own Access policy.