Playwright 系ツールの認証状態の持ち方には、永続プロファイル（userDataDir）方式と明示的な storageState ファイル方式の2系統がある。ログイン済みなのは永続プロファイル側なのに、使いたいツール（録画ツール、テストランナー等）は storageState ファイルを要求する、というギャップは、プロファイルから storageState を書き出すブリッジで非対話に埋められる。

手法

launchPersistentContext で対象プロファイルをヘッドレス起動し、認証必須ページへ遷移してから、context の storageState 保存 API でファイルへ書き出す。書き出したファイルは newContext の storageState 入力としてそのまま消費できる。手動ログインもユーザーへの依頼も不要なので、エージェントの自律作業や CI 前段でフローが止まらない。

採用の判断基準

• 手元にログイン済みの検証用永続プロファイルが既にあるなら、ツール側の対話ログインフロー（headed ブラウザで手動ログイン→保存）を挟むよりこの抽出を選ぶ。ユーザーの手を止めずに済む。
• プロファイルがない初回や、別アカウントでの状態が必要な場合は、対話ログインで storageState を作る側に倒す。抽出は「既にある状態の移植」にだけ使う。

検証方法

2点で判定する。(1) 遷移後の最終 URL がログイン画面へリダイレクトされていないこと。(2) 書き出した state に対象ドメインのセッション Cookie（access/refresh token 系の名前）が含まれること。生のトークン値を読んで確かめる必要はない。

落とし穴

• 永続プロファイルは排他ロックされるため、同じプロファイルで別プロセスのブラウザが起動中だと launchPersistentContext が失敗する。抽出前に該当プロファイルのブラウザを閉じる。
• 書き出した storageState は抽出時点のスナップショットで、トークン失効とともに無効になる。消費側がログアウト状態になったら再抽出する運用にする。
• storageState ファイルには認証トークンが入るので、VCS・バックアップの対象から外す。

関連

「検証用の専用永続プロファイルを1つ使い回す」運用の補完で、あちらがプロファイル自体の育て方、こちらはそこから状態を他ツールへ移植する手段。