Reconnect required

What the symptom looks like#

The mailbox asks to be reconnected, in Needs You and on the Mailboxes screen. Signing in to Connect still works perfectly, which is the confusing part: Google OAuth is the only way to sign in here, so it is natural to assume one grant covers both. It does not. Signing in proves who you are; the mailbox grant lets Connect read and send as that mailbox, and they are separate grants that are revoked separately.

Why a grant stops refreshing#

Access to a provider is short-lived by design and is renewed behind the scenes: oauth.store_tokens rebuilds the mailbox's config and assigns it back each time a fresh token is issued. config is a real setter rather than a read-only view precisely so that renewal sticks — a read-only property would drop every refresh and the mailbox would work until the first token expired.

1. The grant was revoked. Somebody removed Connect's access in the Google account's security settings, deliberately or during a clear-out.
2. The account's security posture changed. A password change, two-factor enrolment, or an administrator policy can invalidate an existing grant. The provider decides this, not Connect.
3. The scopes no longer cover the work. A grant that was narrowed can authenticate and still refuse the operation the mailbox needs.
4. The account itself moved. A mailbox migrated between domains or providers is a new identity even when the address looks the same.

The reconnection, stage by stage#

1. Trigger — a refresh fails, and the mailbox is marked as needing consent again.
2. User event — you start the consent from the existing mailbox row rather than from Add a mailbox.
3. Authentication and workspace resolution — the flow returns into your session and finds the row inside your own workspace.
4. Ingest — the provider issues a new grant.
5. Canonical record — the same mailbox row is updated; no second row is created for the same inbox.
6. Classification — the uniqueness check confirms this identity is the one already connected, using the query that can see rows an ordinary list cannot.
7. Knowledge, memory and rules — the endpoint tier stays attached to the row, so nothing set against this mailbox is lost.
8. Autonomy and approval — unchanged. A mailbox that was holding replies still holds them.
9. Action — oauth.store_tokens rebuilds config and it is sealed on save.
10. Result — sync resumes from the cursor, which never moved past unprocessed mail.
11. Relationship, timeline and memory — history is continuous; the outage is a gap in delivery, not in the record.
12. Audit, usage and Needs You — the reconnection is recorded and the queued entry drains as its cause clears.

What Connect did complete#

• Everything already bridged is in the canonical tables and readable throughout the outage.
• The cursor is intact, so the backlog is fetched in order rather than skipped.
• Held drafts, approvals and dated commitments survive untouched and under the same rules.
• The mailbox's role, signature, autonomy and endpoint memory all survive, because the row survives.

What Connect did not complete#

• A send that failed during the outage is not replayed. It stays a failed record against its thread and a person decides whether to send it again.
• A send left *uncertain* is not resolved by reconnecting. Only the provider's own sent folder settles that — see the send result is uncertain.
• Write-back that was missed is not backfilled. Read state and labels at Gmail stay as they were, which never affected the replies themselves.
• A duplicate mailbox created during an earlier panic is not merged by reconnecting. Two rows for one inbox stay two rows.

What you can do, and when to escalate#

1. Reconnect from the existing row and grant every scope the consent screen asks for.

   Result A partial grant authenticates and then refuses the work, which is harder to diagnose than a clean failure.

2. Sync and confirm the last-sync time moves, then send one message.

   Result Reading and sending are proved separately, because they can fail separately.

3. Watch the mailbox over the following ticks rather than only the next minute.

   Result A grant that authenticates once and cannot refresh looks healthy for as long as the first token lasts.

An administrator can check whether an organisation-level policy is revoking grants, whether the mailbox is one of several identities where only one is affected, and whether a row with an empty workspace stamp is hiding the mailbox from the list rather than the grant being at fault. Escalate when a fresh consent, with every scope granted, still fails on the first sync; the useful evidence is the timing and the verdict, not a copied provider error.

Questions#

Related#

• Connecting Gmail
• Gmail OAuth scopes and why each is asked for
• Connecting Gmail, end to end
• Repairing a broken mailbox, end to end
• The mailbox disconnected
• A copy of a password somebody else rotates
• Hitting the daily allowance, end to end