ワンクリックでManusで任意のスキルを実行

janitor-refresh-cc-logins

スター1

フォーク1

更新日2026年7月21日 14:54

Refresh the claude.ai login session (cookie) for each rotator account when one nears expiry — the ~monthly human REAUTHENTICATE step the rotator can't automate (claude.ai login needs an OS-level passkey / Google-2FA prompt). Opens Chrome per account (you log in), verifies the session, then mints fresh OAuth tokens via RENEW. Use on an oauth-login-needed / oauth-cookie-reminder nudge, or when "had to log in manually / accounts won't switch / cookie expired". Trigger with /janitor-refresh-cc-logins, "reauth my accounts". (Named cc-logins, not claude-logins — a skill name may not contain the reserved word "claude".)

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Emasoft

Emasoft/ai-maestro-janitor

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Janitor refresh-cc-logins

Overview

The interactive multi-account claude.ai login refresher — the REAUTHENTICATE leg of the OAuth rotator, and the ONLY step that needs a human, because the claude.ai login uses a passkey / Google-2FA prompt that is OS-level — outside any browser, so no automation (Playwright, agent-browser, anything) can satisfy it. The user logs in; you orchestrate and verify. Never enter credentials or log in for the user — only open the browser and check results.

This skill + its helper scripts live IN the plugin (TRDD-3T4DZWXA, completing the TRDD-f892e109 fold — they were previously a user-scope /refresh-claude-logins command). The rotator ENGINE and these helpers are now always the same plugin version. The architecture is the oauth-rotation-renew-reauth PROJECT memory page (the ROTATE → RENEW → REAUTHENTICATE 3-layer model); this skill is layer 3.

Scripts (in the plugin, beside the rotator engine):

ROT="$CLAUDE_PLUGIN_ROOT/scripts/oauth_rotator"
#   $ROT/rotator.py            — the engine (read-only subcommands + the RENEW tick)
#   $ROT/open-login.sh <email> — open a clean REAL Chrome on the account's profile (blocks until Cmd+Q)
#   $ROT/check-login.sh <email>— verify the profile saved a LIVE session (exit 0 = saved)
#   $ROT/lifetime-status.sh    — cookie-vs-OAuth lifetime table + what's due

Run every rotator invocation with env -u CLAUDE_PLUGIN_DATA so the engine resolves the JANITOR's data dir via its own guard (a foreign CLAUDE_PLUGIN_DATA from another plugin's context would otherwise mis-route the state — TRDD-7100178d / TRDD-5EUYV08H). Invoke the engine with python3 (NOT uv run) — rotator.py is stdlib-only, so uv run would only sync the caller's cwd uv-project for no gain; the helper .sh drive it the same way (TRDD-3T4DZWXA).

When to use

An oauth-login-needed or oauth-cookie-reminder heartbeat nudge fired (a cookie is expiring, or an account needs a fresh human login).
The user says "refresh my claude logins" / "reauth my accounts" / "I had to log in manually".
~Monthly proactive refresh, to stagger cookie-vs-OAuth lifetimes so they never coincide.

Instructions

Preflight. Confirm the engine + 3 helpers exist and the rotator resolves a roster. If anything is missing, tell the user exactly what and stop.

ROT="$CLAUDE_PLUGIN_ROOT/scripts/oauth_rotator"
for f in rotator.py open-login.sh check-login.sh lifetime-status.sh; do
  [ -f "$ROT/$f" ] || { echo "missing: $ROT/$f"; exit 1; }
done
env -u CLAUDE_PLUGIN_DATA python3 "$ROT/rotator.py" known-emails   # the roster, one email/line

Show current status first. Surface lifetime-status.sh's table so the user sees which accounts need a refresh and that OAuth is healthy enough to do it safely. (If it says all healthy and nothing is due, ask whether they still want to refresh everything anyway.)
```
env -u CLAUDE_PLUGIN_DATA bash "$ROT/lifetime-status.sh"
```
For EACH account that needs a refresh, in turn: a. Tell the user, as your own message BEFORE launching: ▶ Account k/N — a Chrome window will open. Log in as <email>, tick "stay signed in", then QUIT Chrome with Cmd+Q (closing just the window is not enough). b. env -u CLAUDE_PLUGIN_DATA bash "$ROT/open-login.sh" <email> with a generous Bash timeout (it blocks while the user logs in, returns when they Cmd+Q). c. env -u CLAUDE_PLUGIN_DATA bash "$ROT/check-login.sh" <email> and report ✓/✗. If ✗, offer to retry that account (back to 3a) before moving on.
Mint OAuth tokens NOW (RENEW — don't wait for the daemon). The reauth above only saved COOKIES; the OAuth tokens still need minting. Trigger the rotator's renew so each refreshed account gets a refresh-bearing slot via the CDP-attach capture (it re-opens the REAL Chrome and connect_over_cdp-attaches to decrypt the cookies you just saved):
```
env -u CLAUDE_PLUGIN_DATA CLAUDE_ROTATOR_AUTO_BOOTSTRAP=1 python3 "$ROT/rotator.py" tick   # _bootstrap_seeded_slots → capture per eligible slot (detached)
```
Captures run DETACHED (a real Chrome window may flash per account, then close). The CLAUDE_ROTATOR_AUTO_BOOTSTRAP=1 above authorizes the capture's visible browser for THIS user-initiated run; the unattended daemon keeps auto-bootstrap OFF by default (and caps it per slot) so it never opens a surprise window (TRDD-5OJX3SCF). Poll each account until its slot holds a refresh token before declaring success (env -u CLAUDE_PLUGIN_DATA python3 "$ROT/rotator.py" list). If a capture keeps failing, re-check check-login.sh — the session may not have persisted.
Finish. Run lifetime-status.sh once more to confirm. If every account is ✓ AND its slot holds a refresh-bearing token, reassure the user (all refreshed + minted; cookie and OAuth lifetimes staggered; the daemon keeps them alive and rotates automatically). If any account is still ✗ or its slot stayed empty, list them and what to retry.

Notes

Each account has its OWN Chrome profile (separate cookie jar) — you never log out, you just log into each account's profile once. Re-run only when a session nears expiry (the monitor / the oauth-cookie-reminder heartbeat tells you when).
The opener is a clean, normal Chrome (no automation flags) so Cloudflare + Google-2FA treat it as a human browser. The rotator's automation later reuses these saved profiles; it never logs in itself. The passkey / 2FA prompt is OS-level — that is WHY this step needs a human and cannot be automated.

Scope

ONLY orchestrates the human claude.ai login refresh + the follow-up OAuth mint for the rotator's seeded accounts. Does NOT change rotator config, does NOT rotate the live account, does NOT enter credentials for the user. Toggle daemon-managed rotation with /janitor-auto-manage-oauth-on / -off.

Resources

$CLAUDE_PLUGIN_ROOT/scripts/oauth_rotator/ — the engine (rotator.py, reauth.py, slot_capture_browser.py, …) + the helpers (open-login.sh, check-login.sh, lifetime-status.sh).
/janitor-auto-manage-oauth-on / -off — toggle daemon-managed rotation.
The oauth-rotation-renew-reauth PROJECT memory page — the ROTATE → RENEW → REAUTHENTICATE architecture this skill's layer 3 belongs to.

このリポジトリの他の Skills

同じリポジトリ

janitor-memory-consolidate

Emasoft/ai-maestro-janitor

CONSOLIDATE (MERGE) executor — fuses two duplicate memory notes about the SAME subject + same type into one page (dedup lessons, redirect backlinks, keep the oldest origin date), through the crash-safe transaction core, never editing a live page. ABSTAINS on uncertainty, cross-type/cross-scope/two-hub, or a third page sharing the subject. Use on a [janitor-memory-consolidate] marker, or "consolidate / merge / deduplicate the memory", "two notes cover the same thing", "fold these memory pages together".

2026-07-261

janitor-memory-recall

Emasoft/ai-maestro-janitor

RECALL — before working on a file or debugging/deciding, surface the right memory WIKI page and navigate it. Two entry points - FILE-anchored (about to edit a file → surface that functionality's HUB page and descend its links to the detail needed) and SYMPTOM ("have we hit this before?" → rank pages by how the symptom hits their description/title/tags). Use before re-deriving architecture/gotchas, or when the user says "recall memories about X" or "did we already solve this". Reads only the pages the task needs, degrading to grep when memgrep is absent. The RECALL leg of the wiki-memory protocol.

2026-07-261

janitor-memory-write

Emasoft/ai-maestro-janitor

MEMORIZE — capture a durable decision/fact into the project's memory WIKI as a navigable page, not a loose note. Use after a bug-autopsy gotcha, a design/architecture decision, a project constraint not derivable from code, a confirmed user preference, or when the user says "remember this", "memorize this", "save a memory". Finds the right existing wikimem page first so it never duplicates; only when none fits, creates a HUB / ASPECT / COMPONENT page via the expand/reduce decision, wires it into the See-also web, and indexes it by symptom. The MEMORIZE leg of the wiki-memory protocol.

2026-07-261

janitor-memory-update

Emasoft/ai-maestro-janitor

UPDATE — modify an existing memory WIKI page when something changes — ADD a decision to the page that owns the subject, CORRECT a memory a new discovery contradicts (the 2-step non-destructive protocol), or RESHAPE a page that outgrew its tier (expand a shared rule into an aspect, reduce element-specific detail into its component page). Use when a decision changes, a memory turns out wrong, a page mixes too many subjects, or the user says "update the memory", "that's no longer true", "fix the note about Y", "this memory is outdated". Keeps the See-also web, the hub map, and the lessons trail consistent. The UPDATE leg of the wiki-memory protocol.

2026-07-261

janitor-auto-manage-oauth-on

Emasoft/ai-maestro-janitor

Opts THIS machine into the janitor's unattended multi-account OAuth rotator. Sets an opt-in flag the always-on janitor daemon's 60s oauth-rotator-tick Task reads to rotate the live Claude Code credential to an alternate paid account before a rate-limit 429 stalls an overnight session. Default OFF, macOS only, idempotent; refuses if a pinning env var would defeat rotation. Trigger with /janitor-auto-manage-oauth-on, "turn on oauth rotation", or "enable account rotator".

2026-07-261

janitor-token-attribution

Emasoft/ai-maestro-janitor

Rank every project on this machine by how many tokens it is burning right now and name the one to throttle — the fleet token-attribution dashboard. The account 5h/7d utilization% is aggregate across all your parallel projects; this scans each project's transcripts to say WHICH one is over-consuming (large 5h share AND above its own baseline) and where its spike came from. Read-only. Use when the user asks which project is eating the token budget / which session to throttle / who is burning the rate-limit window.

2026-07-261