Auth Manager v3.1 — 平台ログイン状態管理

fast-browser-use (fbu) をベースに、--user-data-dir を使用して完全な Chrome profile（cookies + localStorage + IndexedDB）を保存します。

環境設定（必須）

fbu バイナリは ~/.cargo/bin/ にあります。毎回実行前に必ず設定してください：

export PATH="$HOME/.cargo/bin:$PATH"
export CHROME_PATH=/usr/bin/google-chrome
export DISPLAY=:1   # デスクトップ表示、headless false の場合は必須

核心的な責務

責務 1: 保存済み profile の可用性チェック

auth-platforms.json 内のすべての enabled: true なプラットフォームに対して、定期的にスナップショットチェックを実行します。

# Chrome の残留を防ぐため、必ず timeout で囲む
timeout --kill-after=5 60 fast-browser-use snapshot \
  --url "<check_url>" \
  --user-data-dir ~/.openclaw/chrome-profiles/<platform> || true
pkill -f "chrome.*--remote-debugging" 2>/dev/null || true

判定ロジック：

• DOM に logged_in_indicators キーワードが含まれる → ✅ active
• DOM に login_page_indicators キーワードが含まれる → ❌ expired
• どちらにも一致しない → ⚠️ uncertain
• コマンド失敗 → 🔴 error

Cloudflare サイト（例：linux.do）は headless モードでブロックされるため、--headless false を追加する必要があります。

timeout --kill-after=5 90 fast-browser-use snapshot \
  --url "https://linux.do" \
  --user-data-dir ~/.openclaw/chrome-profiles/linuxdo \
  --headless false || true
pkill -f "chrome.*--remote-debugging" 2>/dev/null || true

結果は ~/.openclaw/auth-session-state.json に書き込まれ、期限切れ/異常時にはアラートが送信されます。

責務 2: 新しいプラットフォームの認証 — 自動 profile 保存

ユーザーが fbu を使用して新しいプラットフォームを認証する場合、以下の完全なフローを実行します。

ステップ 1: profile ディレクトリの作成

mkdir -p ~/.openclaw/chrome-profiles/<platform>

ステップ 2: デスクトップブラウザを開いてユーザーにログインさせる

fast-browser-use login \
  --url "https://platform.com/login" \
  --headless false \
  --user-data-dir ~/.openclaw/chrome-profiles/<platform> \
  --save-session ~/.openclaw/chrome-profiles/<platform>-session.json

重要なパラメータの説明：

• --headless false — 必須、デスクトップに可視の Chrome ウィンドウを開きます
• --save-session — 必須パラメータ（fbu login で要求）、主要な状態保存は user-data-dir に依存する場合でも必要です
• --user-data-dir — 完全な Chrome profile を保存します
• ブラウザが開いた後、ターミナルに "Press Enter after you have logged in..." と表示されます
• ユーザーがログインを完了すると、agent はプロセスに改行文字（Enter）を書き込み、保存をトリガーします

ステップ 3: ユーザーがログインを確認した後、Enter を送信する

# process write を使用して fbu プロセスに Enter を送信する
process.write(sessionId, "\n")

ステップ 4: ログイン状態の検証

fast-browser-use snapshot \
  --url "<check_url>" \
  --user-data-dir ~/.openclaw/chrome-profiles/<platform>

DOM 出力にログイン状態のキーワード（ユーザー名、残高、dashboard など）が含まれているか確認します。

ステップ 5: 設定ファイルの更新

新しいプラットフォームを auth-platforms.json に追加します。check_url、login_url、indicators などを含めます。

ステップ 6: 状態ファイルの更新

auth-session-state.json に書き込みます。

ファイル構造

~/.openclaw/chrome-profiles/<platform>/   # fbu Chrome profile（完全な状態）
~/.openclaw/auth-platforms.json           # プラットフォーム設定
~/.openclaw/auth-session-state.json       # チェック結果の状態

プラットフォーム設定形式

~/.openclaw/auth-platforms.json:

{
  "platforms": {
    "platform_id": {
      "name": "表示名称",
      "profile_dir": "~/.openclaw/chrome-profiles/platform_id",
      "check_url": "https://example.com/dashboard",
      "login_url": "https://example.com/login",
      "logged_in_indicators": ["キーワード1", "キーワード2"],
      "login_page_indicators": ["ログイン", "Sign in"],
      "enabled": true,
      "credentials": {
        "username": "user@example.com",
        "password": "xxx"
      },
      "login_method": "github_oauth"
    }
  }
}

オプションフィールドの説明

• credentials：アカウントとパスワードを持つプラットフォームは、認証情報を保存できます。profile が期限切れになった場合、agent は fbu navigate を使用してフォームに自動的に入力し、再ログインできます。
• login_method：ログイン方法の説明（例：github_oauth、qrcode、password）。agent が自動ログインできるかどうかを判断するのに役立ちます。

批量チェック

すべての enabled なプラットフォームを反復処理し、grep でキーワードを照合してすばやく判定します。

# 批量チェックの例（grep でキーワードを照合）
for platform in polymarket aixn xingjiabiapi github douyin xiaohongshu linuxdo; do
  echo "=== $platform ==="
  fast-browser-use snapshot \
    --url "$(jq -r ".platforms.$platform.check_url" ~/.openclaw/auth-platforms.json)" \
    --user-data-dir ~/.openclaw/chrome-profiles/$platform 2>&1 \
    | grep -E "キーワード" | head -5
done

既知のプラットフォームの特性

2026-03-30 小红书 実践からの結論（重要）

1. 優先戦略は、新しい hidden/CDP ブラウザを起動するのではなく、ホストマシンから見える Chrome + 既存のセッションの再利用です。

   • OpenClaw 公式のデフォルトブラウザの考え方は、defaultProfile: "user" + driver: "existing-session" + attachOnly: true に近い
   • 小红书 のような強力なリスク管理プラットフォームの場合、最初にユーザーにホストマシンから見えるブラウザでログインを完了させ、そのログイン状態を自動化で再利用します

2. 18800 をデフォルトの真実として扱わないでください。

   • 18800 は、オプションの CDP profile（例：openclaw）にすぎません
   • 可視のローカルブラウザがすでにログインしている場合は、追加のクリーンなブラウザを起動するのではなく、existing-session セマンティクスを優先する必要があります

3. 小红书 creator ログインページには SMS ログインのみが表示される場合があります。

   • 創作者バックエンドを開いても、必ずしもスキャン可能なエントリが表示されるとは限りません
   • メインサイトの QR コードログインは、リスク管理（例：error_code=300012 / IP リスク）をトリガーする可能性があります

4. 推奨 SOP（更新版、QR コード優先）：

   • 最初にスキャン可能な 小红书 ログイン QR コードの取得を試みます
   • スクリーンショットを撮り、ユーザーに直接送信して、ユーザーに携帯電話でスキャンしてログインさせます
   • QR コードパスが利用できない/リスク管理されている/ページに QR コードが提供されていない場合は、ホストマシンから見える Chrome にダウングレードします
   • ユーザーに手動で 小红书 創作者バックエンドにログインさせます
   • ページを開いたままにします
   • 次に、公開/自動化スクリプトに、そのログイン済みセッションをアタッチして公開を続行させます

5. QR コード優先ルール（ハード制約）：

   • プラットフォームが 小红书 であり、利用可能なログイン状態がないことが検出された場合、デフォルトの目標は「ログインページを開く」ではなく、「ユーザーがスキャンできる QR コードを優先的に生成する」ことです
   • agent は、QR コードが表示される可能性のあるログインエントリを優先的に試し、スクリーンショットをユーザーに送信する必要があります
   • QR コードを取得できない場合は、理由（例：creator は SMS ログインのみ、メインサイトのリスク管理 300012）を明確に通知してから、ダウングレードパスに入ります

6. デバッグ判定順序：

   • 最初に、現在のページが 401/ログインページにリダイレクトされているかどうかを確認します
   • 次に、再利用可能なログイン状態が実際に存在するかどうかを確認します
   • 次に、QR コードログインパスが到達可能かどうかを試します
   • 最後に、アップロード、セレクター、またはカバーファイルの問題を疑います

状態ファイル形式

~/.openclaw/auth-session-state.json:

{
  "platforms": {
    "polymarket": {
      "status": "active",
      "message": "ログイン正常 ✅ (発見: 資産組合 $6.02)",
      "checkedAt": 1740000000
    }
  },
  "lastCheck": 1740000000
}

status 値: active | expired | uncertain | error

Cron タスク

定期的な自動チェックが設定されています（cron id: 1f2eb5a5-5c2e-4556-b006-e29325f41609）。期限切れになるとアラートが送信されます。

注意事項

1. fbu login 必須パラメータ：--url、--headless、--user-data-dir、--save-session の 4 つはすべて必須です
2. Profile ロック：--user-data-dir は profile をロックします。同じ profile を複数の Chrome インスタンスで同時に使用することはできません
3. Cloudflare サイト：headless がブロックされた場合は --headless false を使用しますが、snapshot の --headless パラメータには明示的に false を渡す必要があります
4. OAuth ログイン（GitHub OAuth など）：新しい profile にはサードパーティのログイン状態がないため、ユーザーはポップアップページでサードパーティのアカウントにログインする必要があります
5. スキャンログイン（抖音、小红书）：ユーザーが手動で操作する必要があります。agent は自動的に完了できません
6. snapshot 検証：新しいプラットフォームの認証後、必ず snapshot 検証を 1 回実行して、profile が正しく保存されていることを確認してください
7. タイムアウト設定：fbu login には時間がかかる場合があるため（ユーザー操作）、exec timeout は ≥ 300s にすることをお勧めします