GitHub 通知渠道

GitHub 渠道轮询 Notifications API，再读取相关 Issue 或 PR 评论。它与GitHub Actions 集成不同，不需要配置仓库 Webhook。

认证与最小配置

可以提供 classic PAT，需 notifications 和 public_repo；私有仓库改用 repo。当前通知 API 不支持用 fine-grained PAT 替代这一配置。也可先 gh auth login，再显式启用 useLocalGh: true；该选项默认 false，授权范围是主机登录账号可访问的全部仓库通知。显式 token 优先于本地 gh。

下面通过环境变量提供 PAT，只接受指定操作者在已获准仓库中的请求：

{
  "channels": {
    "github-work": {
      "type": "github",
      "token": "$GITHUB_TOKEN",
      "pollInterval": 60000,
      "groupPolicy": "allowlist",
      "groups": {
        "owner/repo": {
          "requireMention": true,
          "senders": "allowlist",
          "allowedUsers": ["operator-username"]
        }
      },
      "operators": ["operator-username"],
      "sessionScope": "chat_thread",
      "cwd": "/path/to/project"
    }
  }
}

替换仓库和用户名后运行 qwen channel start github-work。认证账号自己的操作不会产生可用触发，适配器也忽略自己的评论；需要一个独立操作者与机器人账号。将机器人自己放入成员白名单仍不能让它触发自己。

baseUrl 默认 https://api.github.com，Enterprise 可设为 https://github.example.com/api/v3。本地 gh 必须登录同一主机，且此模式要求 HTTPS baseUrl。

仓库、成员和通知类别

所有流量都是群流量，groupPolicy 默认 disabled。放行仓库后成员默认 open；公开仓库中，这会让任何能触发支持事件的用户向工作区 agent 提交任务。应使用群内 senders: allowlist，并显式设置共享会话 operators；privatePolicy 和顶层 allowedUsers 不限制仓库成员。

成员与 operators 按用户名授权，用户名改名后应移除旧值，避免后来注册旧名称的人继承权限。配对按 owner/repo 路径保存，仓库改名、转移或删除后也要撤销旧批准。

requireMention 对普通评论检查实际 @bot-username，大小写不敏感；定向通知理由另有处理。reasonFilter 只是通知类别白名单，支持 mention、review_requested、assign、author、comment、ci_activity、manual、state_change、subscribed、team_mention、security_alert、approval_requested、invitation、member_feature_requested、security_advisory_credit。

不要用 reasonFilter: ["mention"] 代替提及检查：GitHub 的 reason 属于线程且可能保留旧值，新提及可能以 comment 或 subscribed 等理由到达。过滤项会在窗口内已接纳工作完成后标成已读，以后移除过滤器不会重放它们。

游标与任务恢复

默认每 60000 毫秒轮询未读通知，枚举 (previousCursor, currentMaxUpdatedAt] 窗口中的评论，先持久化来源和去重键再分发任务。已接纳任务完成后才标记通知已读并推进游标；存在可恢复任务或状态读写失败时不推进。

重启先恢复已持久化任务，再轮询新通知。失败任务最多尝试 3 次，之后成为终止状态；取消的任务不重跑。已经发表、被抑制或进入确定未写入投递重试的最终回复也不触发任务重跑。

首次接触的新 Issue/PR 在没有评论分发时可回退到正文；mention 类仍需正文实际提及。推送、标签变化等若没有窗口内新评论，不会单凭更新时间启动 agent。首次启动以当时为游标，跳过旧未读内容，之后的新活动才可能触发；轮询前手动标已读也会跳过。

回复与范围

只发表完成的回复，不将模型流式片段逐条发成评论。处理期间的 👀 是尽力添加和移除，失败只记录日志，不阻止最终回复。

确定没有写入的投递失败会把结果存到工作区渠道目录下的 github-pending-deliveries.json 文件，在下次渠道启动时重试；入站状态保持 reply_pending，直到成功或确定终止。结果不明确的失败不自动重试，以免重复评论。

当前入口处理 Issue/PR 普通评论，不读取 PR 行内审查评论、审查总结或游标之前的完整历史。需要这些上下文时，不能假定通知适配器已经自动提供。