用 GitHub Actions 让 Claude Code 审 PR、修 issue：安装、三个工作流和要守住的几条线

这篇教程解决一个问题：不想每次都在自己电脑上开 Claude Code，想让它直接待在 GitHub 仓库里，有人提了 issue、开了 PR 就能叫它干活。

官方的做法是一个 GitHub Action，叫 anthropics/claude-code-action。它在仓库的工作流里运行 Claude Code。装好之后，在 issue 或 PR 的评论里写 @claude 加一句要求，它就在 GitHub 的运行器上把代码拉下来，分析、修改、推提交，再把结果回复在同一个地方。也可以不等人叫，在某个事件发生时自动跑，比如每次开 PR 时审查一遍。

本站没有条件实测这一篇：服务器上的实测环境没有 GitHub 账号和仓库的授权。下面的内容全部按官方文档整理，工作流文件照文档原样给出。

先分清几样名字相近的东西

官方文档开头专门做了区分，因为都带着 Claude Code 的名字：

名字	是什么
Claude Code GitHub Actions（这篇讲的）	一个 Action，你在仓库里写工作流文件来配置它
Code Review	每个 PR 自动审查，不用自己写工作流。见提交之前让 Claude Code 先审一遍里的说明
云端会话	Claude Code 的会话跑在云上而不是你的机器上。见云端会话
Agent SDK	在 GitHub Actions 之外自己写自动化。这个 Action 就是基于它做的

需要准备什么

对这个仓库有管理员权限。
一份凭据，二选一：
- Claude 的 API key，在 Claude Console 里创建；
- 用 Claude 订阅生成的长期令牌，Pro、Max、Team、Enterprise 订阅可用，在本地运行 claude setup-token 生成。
仓库在 github.com 上。GitLab 见文末。

国内读者先看这一条。 工作流是跑在 GitHub 的运行器上的，网络不是问题，问题在凭据：文档写的认证方式只有上面两种，加上 Amazon Bedrock、Google Cloud、Microsoft Foundry 三家云厂商。通过中转站的 key 来跑，这一页文档没有写。

这个 Action 有一个 settings 输入，可以传一份 Claude Code 的设置；而接口地址和凭据在 Claude Code 里本来就可以写在设置的 env 里（见Claude Code 接入中转站）。从这两点看，接中转站在思路上走得通。但这是推断，我们没有实测，也没有在官方文档里核对到这种用法，不要把它当成已经验证的方案。要试的话，key 一样要放在仓库的密钥里，不能写进工作流文件。

安装：两种方式

快速安装

在本地用 Claude Code 打开这个仓库，输入：

/install-github-app

开始之前要先装好 GitHub 的命令行工具 gh 并登录（gh auth login），Claude Code 会检查，没有的话会提醒。

接下来它依次做三件事：

安装 Claude 的 GitHub App。
把凭据存成仓库的密钥。API key 存成 ANTHROPIC_API_KEY，订阅令牌存成 CLAUDE_CODE_OAUTH_TOKEN。如果 Claude Code 本地已经有一把 API key，它会直接用这一把。
推一个带工作流文件的分支，并在浏览器里打开一个准备好的 PR。

你把这个 PR 创建并合并，@claude 就能用了。中途想停，按 Esc；它会告诉你仓库里已经发生了哪些事，比如分支推了没有、密钥存了没有。

这条命令只支持 github.com 上的仓库。

手动安装

本地不用 Claude Code、上面的命令失败了、或者想自己完全掌握工作流文件的，手动做三步：

安装 Claude GitHub App 到仓库。这个 Action 用到它的三项权限：Contents、Issues、Pull requests，都是读写。
添加密钥。 在仓库的 Settings 里加 ANTHROPIC_API_KEY 或 CLAUDE_CODE_OAUTH_TOKEN。
复制工作流文件。 把官方仓库里的 examples/claude.yml 放进你仓库的 .github/workflows/。文档说明这个文件直接可用，不只是示例。用订阅令牌的话，把里面 anthropic_api_key 那一行换成 claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}。

装 App 时给出去的权限

安装 Claude GitHub App 时，你授予的不只是上面三项。这个 App 是 Claude 所有和 GitHub 集成的功能共用的，权限是一整套：Actions、Checks、Contents、Discussions、Issues、Pull requests、Repository hooks、Workflows 是读写，Administration、Members、Merge queues、Metadata、Statuses 是只读。GitHub 不允许只接受其中一部分。

组织要求最小权限的话，文档给的办法是自己建一个只带 Contents、Issues、Pull requests 的 GitHub App，做法在这个 Action 仓库的 setup 文档里。自建的 App 只能给这个 Action 用，Code Review 等功能仍然要官方的 App。

两种运行方式

Action 根据工作流里有没有 prompt 这个输入，自己判断怎么跑：

	交互方式	自动方式
工作流里	不写 `prompt`	写了 `prompt`
什么时候动	等有人在评论、PR 审查、或新 issue 的标题和正文里写 `@claude`	触发事件一发生就跑，不等人叫
结果在哪	回复在触发它的那个 issue 或 PR 里，边做边更新	默认只在工作流的运行日志里。要它发评论，得在提示词里说，并且给它能发评论的工具

三个工作流

下面三个文件照官方文档给出。

一、有人 @claude 就响应

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
      id-token: write
      actions: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

几处不是套话的地方，文档逐个解释了：

id-token: write：Action 默认以 Claude GitHub App 的身份认证，需要它。
actions: read：让它能读 PR 上 CI 的结果。
actions/checkout：给它一份仓库的本地副本。
if 那一行：评论里没有 @claude 就不启动运行器，省分钟数。Action 自己也会再检查一遍触发词。

装好之后，在 issue 或 PR 的评论里这样写：

@claude 按这个 issue 的描述把功能实现出来
@claude 这个接口的用户认证应该怎么做？
@claude 修掉用户面板组件里的 TypeError

二、开 PR 时自动审查

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

这里 prompt 传的不是一句话，而是一个 skill 的调用：先用 plugin_marketplaces 和 plugins 装上 code-review 插件，再调用它里面的 skill。快速安装时如果勾了审查工作流，生成的就是这一套。

两行决定审查结果去哪：

--comment：有它，审查结果发在 PR 上，每个问题一条行内评论，没发现问题就发一条总结。没有它，什么都不发，结果只在运行日志里。
claude_args 那一行要保留。 skill 自己的头部虽然也写了这个工具，但 Action 只有在 claude_args 的 --allowedTools 里看到它，才会启动负责发行内评论的那个 MCP 服务器。

文档还说明了它会跳过哪些 PR：草稿、已关闭的、它判断不需要审的（自动生成的、改动很琐碎的），以及已经有它评论的。

公开仓库要注意：GitHub 不把密钥交给从 fork 发起的 PR 触发的运行，所以这个审查只对同一仓库内分支发起的 PR 生效。

三、定时跑

name: Daily Report
on:
  schedule:
    - cron: "0 9 * * *"
jobs:
  report:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read
      id-token: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Generate a summary of yesterday's commits and open issues"
          claude_args: |
            --model claude-opus-5-5
            --allowedTools "mcp__github__list_commits,mcp__github__list_issues"

每天 UTC 9 点（北京时间 17 点）生成一份报告，写在运行日志里。

这个例子里有一条容易忽略的规矩：用普通文字做 prompt 时，它默认没有命令行和 GitHub API 的权限。 提示词需要什么工具，要用 claude_args 里的 --allowedTools 明确给，或者在 settings 输入里写允许规则。这里给了两个 GitHub 的 MCP 工具，用来读提交和 issue，所以连 checkout 都省了。--allowedTools 的写法和本地的 claude -p 完全一样，见把 Claude Code 接进脚本和 CI。

GitHub 对定时工作流有两条限制：只从默认分支运行；公开仓库 60 天没有活动，定时会被停掉。

谁能触发它

仓库里谁都能评论，但不是谁写 @claude 都管用。Action 在启动之前对触发者做两项检查，任何一项不过，这次运行就失败：

写权限。 issue 和 PR 事件里，触发的人必须对仓库有写权限。要放行个别没有写权限的人，设 allowed_non_write_users，并传你自己的 github_token。
是人不是机器人。 机器人账号触发的一律拒绝，除非列进 allowed_bots。这是为了防止机器人之间互相触发、无限循环。

第一条是这套东西最基本的安全线：没有写权限的外人，不能靠一条评论让它在你的仓库里改代码、花你的额度。放宽它之前想清楚。

要守住的几条线

凭据只放在密钥里。 不要把 API key 或令牌写进工作流文件、提交进仓库。工作流里永远写成 ${{ secrets.ANTHROPIC_API_KEY }} 这种引用。

工作流只给它用得到的权限。 上面三个文件的 permissions 各不相同：响应 @claude 的要写权限，审查和报告只要读权限。照着你的用途给，不要图省事全开。

合并之前人要看。 它推的提交、开的 PR，和同事的一样要审。文档原话是在合并前检查 Claude 的改动。

把项目的规矩写进 CLAUDE.md。 它在 GitHub 上运行时同样会读仓库根目录的 CLAUDE.md，代码风格、审查标准、项目特有的规则都写在这里。写法见CLAUDE.md 怎么写。

控制花费

每次运行消耗两样东西：GitHub Actions 的分钟数，和模型的 token。用订阅令牌认证的话，token 算在订阅里，不走 API 计费。

文档给的几个办法：

@claude 后面的要求写具体，它需要的轮数就少。
用 issue 模板，把背景一次给全。
CLAUDE.md 保持精简，它每次运行都要读一遍。
在 claude_args 里加 --max-turns，给每次运行封顶。
给工作流设超时，避免跑飞。
用 GitHub 的并发控制限制同时运行的数量。

claude_args 可以传任何 Claude Code 的命令行参数，比如：

claude_args: "--max-turns 5 --model claude-sonnet-5-5"

不写 --model 时，用的是 Claude Code 的默认模型。

常见问题

以下来自官方文档的排错部分。

@claude 没有反应。 依次确认：GitHub App 装到了这个仓库；仓库启用了工作流；密钥设了；评论里的 @claude 是一个完整的词，不是 /claude 或 @claude-bot；评论的人对仓库有写权限。

它推的提交没有触发 CI。 GitHub 不会为用默认的 GITHUB_TOKEN 做的提交触发工作流。如果你给 Action 传了 github_token: ${{ secrets.GITHUB_TOKEN }}，去掉它，让 Action 以 Claude GitHub App 的身份认证；或者换一个自建 App 的令牌。

认证报错。 先在本地用同一份凭据运行 claude，确认凭据本身有效，再回头查工作流。

还在用 @beta。 旧的工作流如果引用的是 anthropics/claude-code-action@beta，要改成 @v1：去掉 mode 输入，把 direct_prompt 改成 prompt，把 max_turns、model 这类选项移进 claude_args。

不想用了怎么卸

三样东西分别撤：

工作流文件：删掉 .github/workflows/ 里用到这个 Action 的文件。快速安装生成的是 claude.yml，勾了审查的还有 claude-code-review.yml。
密钥：从仓库里删掉。注意删掉密钥并不会让那份凭据失效，要彻底作废一把 API key，还得到 Console 里把它删掉。
GitHub App：在仓库或组织的设置里卸载。如果你还在用 Code Review 这类别的 Claude 功能，就不要卸，它们共用这个 App。

GitLab 上的做法

GitLab 没有对应的 Action，做法是在 .gitlab-ci.yml 里加一个任务，直接调 claude -p。官方文档注明这个集成目前是测试版，由 GitLab 维护。

最简的配置分两步。先在 Settings → CI/CD → Variables 里加一个打了掩码的变量 ANTHROPIC_API_KEY，然后加这个任务（官方文档的例子，这里去掉了注释和一行调试输出）：

stages:
  - ai

claude:
  stage: ai
  image: node:24-alpine3.21
  rules:
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  variables:
    GIT_STRATEGY: fetch
  before_script:
    - apk update
    - apk add --no-cache git curl bash
    - curl -fsSL https://claude.ai/install.sh | bash
    - export PATH="$HOME/.local/bin:$PATH"
  script:
    - /bin/gitlab-mcp-server || true
    - >
      claude
      -p "${AI_FLOW_INPUT:-'Review this MR and implement the requested changes'}"
      --permission-mode acceptEdits
      --allowedTools "Bash Read Edit Write mcp__gitlab"
      --debug

可以看到它就是一条 claude -p：在任务里现装 Claude Code，用 --permission-mode 和 --allowedTools 定好权限，然后跑。所以把 Claude Code 接进脚本和 CI里讲的输出格式、权限、上限，在这里都直接适用。

这也说明了一件事：任何 CI 系统，只要能装 Claude Code、能放密钥，就可以用同样的办法接进去，不限于 GitHub 和 GitLab。

这篇没有覆盖到的

全篇没有实测。 工作流文件照官方文档给出，没有在真实的仓库里跑过。
通过中转站的 key 来跑，没有核对到官方的说法，文中的思路是推断。
云厂商的接法没有展开：Amazon Bedrock、Google Cloud、Microsoft Foundry 各有一页专门的文档，用的是 OIDC 身份联合，不存静态的密钥。
组织级的部署只提了一句。 文档里还有用工作负载身份联合替代长期密钥的做法。
GitHub Enterprise Server 没有涉及。
这个 Action 完整的输入清单在它自己仓库的文档里，这里只用到了常用的几个。

系列的上一篇：把 Claude Code 接进脚本和 CI。权限和输出格式的细节都在那一篇，本站实测过。
在本地做同样的事：提交之前让 Claude Code 先审一遍。
不写工作流、让它在云上跑：云端会话。