GitHub Actions获取仓库环境公钥提示需管理员权限问题排查

这个报错本质是Actions运行器里调用密钥接口时，携带的令牌没有仓库管理员权限，基本都是下面几个原因，按踩坑概率从高到低排：

• 最高发：你的自定义PAT根本没正确注入到步骤环境里
  别被你那个测试命令骗了——查GitHub用户信息的接口是完全公开的，就算不带任何认证令牌、带无效令牌都能正常返回公开用户数据，根本证明不了你配置的PAT生效了。
  GitHub Windows运行器本身会自动生成一个内置的GITHUB_TOKEN，这个令牌默认只有仓库读写权限，没有管理员权限，也无法操作环境密钥。如果你没把自己的PAT正确注入，请求要么带了空的无效Authorization头，要么默认走了内置低权限令牌，调用需要管理员权限的环境公钥接口自然会报权限不足。
  常见的注入失败场景：
  • 你把SL_GITHUB_TOKEN存成了Production环境的专属密钥，但工作流对应步骤没绑定Production环境，环境级密钥根本不会加载到步骤上下文里
  • 步骤里没显式声明把密钥注入到环境变量，漏写了env配置块
  • 密钥名拼错，比如存的时候叫SL_GITHUB_TOKEN，引用的时候大小写写错、多打漏打了字符
• 次常见：PowerShell的curl别名坑
  GitHub的Windows运行器里同时存在两个curl：一个是随Git for Windows带的原生curl.exe，另一个是PowerShell把curl作为Invoke-WebRequest的别名，两者参数格式完全不兼容。如果因为运行器版本、配置差异导致别名映射不对，你写的传参可能根本没把Authorization头带出去，最终请求没带有效PAT。
• 低概率：组织SAML权限拦截
  如果仓库在开了SAML单点登录的组织下面，就算你创建PAT的时候勾了全权限，也得在PAT设置页单独给这个组织授权，否则从Actions运行器的IP段发请求时，会被组织权限策略拦截，当成无权限请求处理。你本地能跑通大概率是因为本地网络已经过了组织SAML认证，请求会自动带上认证上下文。

1. 先确认PAT有没有真的注入
   在跑接口命令之前，加一行PowerShell命令打印当前环境里的PAT长度：

Write-Host "当前加载的PAT长度：$($env:SL_GITHUB_TOKEN.Length)"

拿这个长度和你本地存的PAT长度对比，如果输出是0或者长度对不上，先修复注入问题：

• 如果密钥存在Production环境下，必须给对应步骤加environment: Production配置
• 步骤里显式把密钥引入到环境变量，参考配置：

  - name: 拉取环境公钥
    runs-on: windows-latest
    environment: Production # 用环境级密钥必须加这行
    env:
      SL_GITHUB_TOKEN: ${{ secrets.SL_GITHUB_TOKEN }} # 确认这里的密钥名和仓库里存的完全一致
    run: |
      # 后续执行你的接口调用命令
  

2. 绕开PowerShell别名问题
   别直接写curl，显式用Invoke-WebRequest命令，加上-UseBasicParsing参数避开旧版PowerShell的DOM解析坑，改完的命令：

$keyData = Invoke-WebRequest -Uri "https://api.github.com/repos/你的账号/你的仓库名/environments/Production/secrets/public-key" -Headers @{"Accept" = "application/vnd.github.v3+json"; "Authorization" = "token $env:SL_GITHUB_TOKEN"} -UseBasicParsing | Select-Object -ExpandProperty Content | ConvertFrom-Json

3. 排查组织权限
   如果仓库属于组织，打开PAT的设置页，找到「组织访问」板块，给对应仓库所属的组织点授权，按提示完成SAML认证后再重试。

内容的提问来源于stack exchange，提问作者Den