Signing out and replacing a session
Signing out revokes this browser's session and clears its cookie. Signing in as a different person on the same browser does the same thing to the session that browser was holding, before the new one is issued. Neither ends a session anywhere else. Ending your other devices is a separate control, and it deliberately never ends the session you are pressing it with.
Two endings that look alike#
Both endings revoke a session row rather than merely dropping a cookie, and the difference matters. A cookie that is deleted while its row stays valid is still a live credential: anything holding a copy of that token can keep using it. Revocation is what makes the token useless, and it is what both paths do.
| What you do | This browser's session | Other devices | What you see next |
|---|---|---|---|
| Sign out | Revoked, cookie cleared | Untouched | The sign-in screen |
| Sign in as somebody else on this browser | Revoked before the new session is issued | Untouched | The other person's workspace |
| Sign out of other devices | Kept, deliberately | Every other session for your address is revoked | The same screen, plus a count of what ended |
| Do nothing until it expires | Expires at the fixed time it was issued with | Each expires on its own clock | A screen that stops answering, then sign-in |
Stage by stage#
- Trigger — you sign out, or you choose to add or switch account and complete Google's consent screen as a different person.
- User or external event — for a replacement, Google returns the second identity to the same browser that is already holding a session.
- Authentication and workspace resolution — the browser's existing session is read *before* the new one exists, so the person being replaced is known rather than inferred afterwards.
- Ingest or request — the sign-out or callback request arrives carrying exactly one session cookie, which is all either path needs.
- Canonical record — the session row is marked revoked. Rows are keyed by a hash of the token, never the token, so nothing outside the session module ever holds the credential itself.
- Reasoning — none. Ending a session is a mechanical act and is deliberately not somewhere a model has an opinion.
- Knowledge, memory and rules — unchanged. Signing out does not stop Connect working: the runtime on-off control does that, and it is a separate decision.
- Autonomy and approval — unchanged. Scheduled work continues under the workspace's own rules whether or not anybody is signed in.
- Action through a provider — none. Google is not called to end anything; the session is Connect's own record and revoking it is local.
- Result — for a sign-out, a cleared cookie and a revoked row. For a replacement, a revoked previous row and a new session carrying one workspace.
- Relationship, timeline and memory — nothing is written. A sign-in is a person using the product, not a contact in the workspace's relationships.
- Audit, usage and Needs You — the ending is recorded with the reason, including which identity replaced which; no allowance is spent.
What a session actually holds#
- One workspace
- A session resolves to exactly one workspace, taken from your membership. Being a member of two does not put you in both at once — you are in one, and switching means a different session.
- A fixed lifetime
- The expiry is set when the session is created and does not slide forward as you use it. An afternoon of steady work does not extend a session that was issued a fortnight ago.
- An audience
- Whether the session is the operator's or a customer's is decided at creation and is what the customer allowlist and the path rewriting downstream both read.
- No password
- Google sign-in is the only way in. There is no password to reset, and no second factor for Connect to hold, because the identity check belongs to Google.
Because the lifetime is fixed rather than rolling, the most common surprise is not a fault at all: a tab left open overnight is a tab whose session quietly reached its end. The screen keeps its last drawn state until something asks the server a question and is refused.
Ending the sessions you cannot see#
Open the account screen and use the control that ends other sessions.
Result Every session for your address except the one you are using is revoked, and the count of what ended is reported back.
Check the count against what you expect.
Result A number higher than the devices you recognise is the signal worth acting on — that is when a security review is the next step, not a shrug.
If a shared machine was involved, sign out on it rather than closing the tab.
Result Closing a tab leaves the row valid until its expiry; signing out revokes it immediately.
The control never ends your own session on purpose. A button that signs you out while you are pressing it reads as a fault however it is labelled, and a person who has just been signed out by their own security action is less likely to finish the review they started.
Questions#
Does signing out stop Connect from working?
No. Connect is not driven by anybody being present: scheduled work, inbound handling and follow-ups continue under the workspace's autonomy rules. Stopping the work is a separate, deliberate control — see Turning Connect on and off.
If I sign in as a colleague on my laptop, are they signed out on theirs?
No. Only the session that this browser was holding is ended. Somebody else's other devices are not this sign-in's business, and treating them as though they were would make an ordinary account switch a disruptive act.
Can I see which sessions exist for my address?
Yes — the account screen lists them, and it can tell which row is the one you are currently using because the session is recognised by the stored hash of its token rather than by the token itself.