Sign accounts back in automatically (automated re-login)
Driving the whole Claude sign-in for a stale account in your pool: the Sign them back in panel, what the automated flow clicks, the one inbox card raised when a click does not register, the optional Authorize-window setting, the opt-in 3-hourly automatic sweep that repairs a stale login before you notice it, adding a brand-new account, every failure message, and the CLI routes an agent uses.
What it is
When a Claude login in your pool goes stale, Omniscio flags it — that is the red row in Settings → Accounts and the "N need re-login" badge on the accounts popover. Fixing it by hand means, for each account: open Chrome, start a sign-in, click "Continue with email", go find the email, copy a six-digit code, paste it, and then run Omniscio's own capture so the account is saved back into the pool. Across a handful of accounts that is a genuinely tedious twenty minutes.
Automated re-login does the whole thing for you. It drives your real Chrome for the page, clicks "Continue with email", reads Anthropic's sign-in email from the Google account you already connected, types the code, and clicks the final Authorize consent screen — then captures each account back into Omniscio. In the normal case you do nothing at all.
It used to ask you for two clicks per account, on the belief that Cloudflare rejects automated ones. That turned out to be false — measured 2026-09-07, every automated click across four accounts was accepted — so now it clicks first and only asks when its own click did not register. If that happens, the old behaviour is exactly what you get: it brings the page to you and waits.
Clicking Authorize for you needs "drive any tab" turned on (see below), because that consent window is one Omniscio opens through your operating system rather than a tab this tool made.
Where to find it
How to use it
- Open Settings → Accounts → Claude. Above the account rows there is a re-login panel. When any login needs re-login it says how many and offers a Sign them back in button; when they are all healthy it just says so, and that is where the automatic option below lives.
- Click it. Omniscio works through the flagged accounts one at a time.
- Usually you do nothing. It is patient with a slow machine: it gives a page time to catch up after each click, waits out the Chrome connection dropping and coming back, and gives a sign-out a few minutes to land, rather than calling any of those a failure. If one of its own clicks genuinely does not register, it brings the Chrome page to the front and raises one inbox card ("Claude re-login — one click needed in Chrome") with a Show me the page button. Do that one click in Chrome.
- It carries on by itself the moment your click registers — no need to come back and tell it.
- At the end the card is replaced by the result: how many accounts are healthy again, and a plain-language line for any that are not.
Stop cancels a run mid-flight, and it genuinely stops: the email polling and page waits end immediately, the sign-in window it opened is abandoned, and every tab it opened is closed. Stopping also means it will not claim the account was fixed — a run that was cancelled before it could confirm anything says exactly that, rather than reading a badge that may have changed for reasons of its own.
Keeping them signed in without lifting a finger (optional, off by default)
The button above only helps if you notice a red row. If you would rather not have to, turn on "Sign them back in automatically" — the toggle at the bottom of that same panel.
With it on, Omniscio checks every three hours and runs the same sign-in for any account that has dropped out, so a stale login is normally repaired before you ever see the badge. A few things worth knowing:
- Off means off. While the toggle is off there is no timer at all — nothing checks, and no browser window can open on its own. Turning it on takes effect straight away; turning it back off stops the next check immediately.
- It only ever acts on an account that is actually broken. If every account is healthy it does nothing at all — no window, no card, no noise.
- It will not hammer an account it cannot fix. If a whole run signs nobody back in — no browser connected, no sign-in mailbox, a Cloudflare click there was nobody to make — it waits a day before trying that again, instead of opening a browser every three hours.
- You still do the one click Cloudflare insists on, exactly as with the button. If it needs you, you get the same single inbox card.
- The first check happens a few minutes after Omniscio starts, not the moment it opens.
This is per-computer and per-person: nobody has it until they switch it on.
Letting it bring the Authorize window to you (optional, recommended)
Omniscio opens the final Authorize screen through Windows, not through the browser connection — so as far as this feature is concerned it is a tab it did not create.
By default it is not allowed to see tabs it did not open. That is a deliberate privacy guardrail (it is the same rule that stops any agent looking at your banking or email tabs), and it has one consequence here: it cannot reach that Authorize window at all. Everything else still works — you just have to find the window in Chrome and click it yourself, and the run tells you so up front rather than leaving you watching a spinner.
If you would rather it handled that step too, turn on "drive any tab" for the bridge you have paired — "My Real Chrome" or "My Real Chrome — Lite" — in Settings. It reads that setting off whichever bridge is connected, so turning it on for the one you use is enough. Then it finds the Authorize window, brings it to the front, and clicks it for you, so the whole sign-in finishes without you. It waits a moment for that consent page to finish wiring itself up before clicking, because a click sent too early is ignored silently, and it re-checks afterwards — so if the click still does not land, the window is simply sitting there waiting for you, exactly as it would have been.
It will never turn this on for you. Widening what an agent can see in your browser is your decision, so the feature only ever reports which mode it is in.
How it behaves
Who can use it
Installs that balance work across a pool of Claude accounts. If yours doesn't, the panel is not rendered at all — no disabled button, no teaser. This is a compatibility/owner gate on the pooled-accounts pathway, not a paid tier.
What it will never do
- It never touches a tab it didn't open, with one deliberate exception. Your existing tabs — banking, email, anything — are untouched. The exception is Omniscio's own Authorize window, which it brings to the front and clicks so the sign-in can finish. That happens only if you have already turned on "drive any tab"; the tool never turns that on for you and never asks it to be. It matches only that one consent page, by exact address. With the setting off, nothing outside its own tabs is touched and it tells you so before it starts. See Letting it bring the Authorize window to you below.
- It never logs, saves, or shows the sign-in link or the six-digit code. Not in a log file, not in the inbox card, not in an error message.
- It never opens a link that isn't Anthropic's. The link's host must be exactly
claude.ai, and the email must genuinely be from Anthropic — checked on the parsed sender address, so a lookalike or a spoofed display name can't redirect it. - It never opens a sign-in email meant for a different account. One inbox often receives the sign-in emails for many accounts. It only opens the one addressed to the account it is signing in, so it can't use up another sign-in's one-time link or sign Chrome in as someone else. An email whose recipient can't be read is still used, so a mailbox that hides it never stalls a run.
- It never saves the wrong account and calls it a win. See below.
- It never deletes an account.
The one thing to know about the Authorize window
Omniscio's account capture opens your default browser — which may not be the Chrome the tool is driving — and it saves whoever finishes that sign-in. If your default browser happens to be signed in as a different Claude account, a naive tool would save that account and report success.
This one doesn't. After every capture it checks the saved account's email against the one it was fixing. A mismatch is reported as a failure with both addresses named, and nothing is deleted — you sign out in that browser and run it again. The run also tells you up front, before you wonder, that the Authorize window opens in your default browser.
Adding an account you have not signed in before
Everything above is about REPAIRING an account Omniscio already has. The same machinery also adds one:
POST /accounts/relogin
{ "newAccountEmails": ["you@example.com"], "wait": true }
It signs that address in and saves it into your pool, using exactly the flow it uses for a
repair — your real Chrome, the sign-in email read from your connected Google account, and the
Authorize click. You can mix the two in one run: pass accountIds as well and it repairs those
and adds these in the same pass.
Two things it will not do:
- It will not add an address you already have. That is a repair, not an onboard, so it is skipped and named rather than quietly creating a second entry for the same account.
- It will not claim success it cannot prove. A repair can be proven by the red re-login badge clearing. A new account was never flagged, so no badge can clear — the only proof is a confirmed capture whose saved address matches the one you asked for. If it does not match, the run stops, tells you both addresses, and deletes nothing.
Before each account it checks who your browser is signed in as. If it is already the right account it leaves your session alone; if it is a different one it signs out first, because otherwise the sign-in it captures would be the previous account. It confirms that sign-out by asking claude.ai's session API, not by waiting for the page to render — on a busy machine the page can take minutes to paint while the API answers instantly. If it cannot tell who is signed in, it stops rather than guessing.
If something goes wrong
Read the account's own line — it names the step that failed. Every account in the results carries its own sentence, so you should not have to guess which part broke. Each message below is what you will actually see, followed by the fix.
- "A re-login needs a connected Chrome bridge, and neither one is paired" — nothing is connected, so there is no route to Chrome at all. Pair either "My Real Chrome" (open Chrome and click the Omniscio extension icon) or "My Real Chrome — Lite", then try again. It works through whichever one you pair, and it prefers the Lite bridge when both are connected. The run also says this in its notes BEFORE it starts, so you can stop it before it wastes any time. (Before 2026-09-25 this message named only "My Real Chrome", so on a machine paired through the Lite bridge it told you to pair a bridge that was already paired, and the re-login could never run at all.)
- "no sign-in email for … arrived in … in time" — this one names two addresses on purpose: the account being signed in, and the mailbox that was watched. If mail for that account does not actually land in that mailbox, nothing will ever arrive — connect the Google account that does receive it (Settings → Connections → Google Workspace), or open the sign-in link yourself. This is the most common surprise on a machine other than the one this feature was built on.
- "no Google account is connected" — it still works; it just cannot fetch the sign-in email for you, so it hands the code entry back to you.
- "the sign-in page never finished loading" — Chrome was not responding in time. Check the browser is alive and re-run that account.
- "the sign-in page never moved past the Continue with email step" — nobody clicked it inside the five-minute window. Re-run and watch for the page it brings to the front.
- "the sign-in link had already expired" — Anthropic's links last about ten minutes. Just run it again to get a fresh one.
- "the page behind the sign-in link never showed a login code" — the link opened something unexpected. Re-run that account.
- "the login code could not be typed" — the code box was not on the page. Re-run; if it keeps happening, the sign-in page has changed shape and the tool needs updating.
- "the login code went in but the browser never signed in" — the code was rejected or the page never moved on. Re-run that account.
- "signed in, but the Authorize step was never confirmed" — the sign-in worked; the consent window is the part that did not finish. Switch to Chrome and look for the Claude consent tab, or turn on "drive any tab" (above) so it can bring that window to you next time.
For agents
Where it also lives
Everything above is also reachable from the command line, for an agent or a script:
POST /accounts/relogin— start it (optionally{"accountIds": [...]}; omit for all flagged). Add{"newAccountEmails": [...]}to ADD accounts — see Adding an account belowGET /accounts/relogin/status— progress, including what you need to click right nowPOST /accounts/relogin/cancel— stop it
One call instead of a poll loop. Add {"wait": true} to the start and it returns the
finished per-account results in that same response, so an agent can start a run and act on the
answer without polling. The wait is bounded; if the run outlives it you get the live progress
plus "timedOut": true and the run keeps going, so you can fall back to polling and lose
nothing. There is no caller-supplied timeout on purpose — the bound has to stay under what the
local server allows.
These need the full-trust global CLI token (~/.amc/cli-token), not the per-session
$AMC_CLI_TOKEN a spawned agent is handed — starting a browser sign-in on your machine is not
something a scoped agent token may do. A scoped token gets 401 here; that is the boundary
working, not a bug.
The automatic sweep has no route of its own and needs none: it is the setting
accountAutoReloginEnabled plus a 3-hourly in-app check in
src/main/services/account/relogin/relogin-auto-sweep.ts, which calls the same gated
startAccountRelogin the button and POST /accounts/relogin call — so it can never mint a login
the gate would refuse. Set the setting over the normal settings route to turn it on for a
machine; there is nothing new to learn.
Desktop only. There is no local Chrome for a phone to drive, so the feature is not exposed on the mobile/web bridge.
Related
See also
- account-pool.md — how multiple logins are used in the first place
- add-a-claude-account.md — the manual sign-in this automates
- real-chrome-bridge.md — the "My Real Chrome" connection it drives
Last verified 2026-09-29