核心用法
OAuth Helper 通过浏览器自动化与 Telegram 即时通讯双通道，实现"人机协同"的 OAuth 登录流程。系统首先扫描目标网站的登录页，自动识别可用的第三方登录入口（Google、Apple、Microsoft、GitHub、Discord、WeChat、QQ），然后通过 Telegram 向用户推送选项列表，等待用户数字回复确认。用户选定提供商后，系统跳转至对应 OAuth 授权页，再次通过 Telegram 发送二次确认请求（"Reply yes"），获得授权后才执行实际的点击与表单填充操作。全程采用 60 秒超时机制，未响应则自动取消。
显著优点
双重确认机制：在"选择提供商"和"执行授权"两个关键节点均要求用户显式确认，有效防止自动化脚本被恶意劫持后的非授权登录。
广泛的提供商覆盖：涵盖全球主流 5 家（Google/Apple/Microsoft/GitHub/Discord）与中国大陆生态 2 家（WeChat/QQ），适应跨境与国内双场景。
灵活的登录模式：支持传统密码登录（自动填充）与 QR 扫码（截图推送至 Telegram 等待移动端确认），适配不同提供商的安全策略。
账号预托管设计：要求 Clawd 浏览器预先登录各 OAuth 提供商，避免在自动化流程中处理敏感凭据，降低凭证泄露风险。
潜在局限与风险
浏览器状态依赖：技能依赖预配置的浏览器 Profile，若会话过期或触发风控，需人工重新登录维护，自动化连续性受限。
2FA 场景人工兜底：当提供商触发二次验证（如 GitHub TOTP、Microsoft Authenticator）时，系统仅能提示用户手动输入，无法完全闭环。
QR 码时效性问题：WeChat/QQ 的二维码具有有效期（通常 5 分钟），网络延迟或用户响应慢可能导致扫码失败需重试。
Telegram 渠道单点风险：所有用户确认依赖单一通讯渠道，若用户未携带手机或 Telegram 服务异常，流程完全阻塞。
适合人群
- 拥有 Clawd 浏览器环境且愿意预配置社交账号的自动化用户
- 需要频繁登录多个支持 OAuth 的第三方服务，但希望保留人工最终控制权的隐私敏感型用户
- 中国大陆与国际服务混用的跨境开发者
常规风险
会话劫持风险：若 Clawd 浏览器 Profile 被未授权访问，攻击者可利用已登录状态绕过用户确认直接授权恶意应用。
社交工程攻击面：Telegram 确认消息可能被伪造，需确保用户已验证机器人身份，防止钓鱼者冒充"OAuth Helper"诱导确认。
元数据泄露：Telegram 消息本身可能暴露用户正在尝试登录的目标网站列表，形成行为画像。