GitHub App创建仓库不必给管理权限：短期令牌怎样逐步启用

只创建仓库，先移除不需要的管理能力

GitHub于2026年10月13日宣布这组GitHub Apps改进，新增的两项仓库细粒度权限也适用于细粒度个人访问令牌。最小权限的意思是只给完成任务所需的能力，而不是为了方便一并开放所有管理操作。

repository_creation:write允许在获授权的账户中创建仓库。过去创建需要更宽的repository_administration:write，后者还包含删除、转移等管理能力；只做创建的自动化现在可以按新权限重新设计。

创建后，执行创建的应用或用户会获得新仓库的访问权。应用使用创建权限时，仍需由组织管理员安装应用；新权限没有取消组织审批，也不能证明原来每个自动化步骤都可直接删掉管理权限。

先列出流程实际执行的操作，再对照官方创建仓库接口核权限。若流程还会修改管理设置，就要逐项核其独立需求，不能只凭创建这一步成功就宣称整条流程权限足够。

仓库加入安装，不等于给应用更多组织权限

installation_repositories:write允许把获授权的那个仓库加入或移出组织内的应用安装。若调用方是用户，还必须是组织所有者或该仓库管理员；它不是让任意成员管理组织全部仓库的通行证。

官方Add和Remove接口现在支持GitHub App用户访问令牌、安装访问令牌及细粒度个人访问令牌。文档把所需仓库权限列为GitHub App installation repository access的write，并要求认证用户对仓库有管理员访问权。

对应接口路径为/user/installations/{installation_id}/repositories/{repository_id}，添加用PUT，移除用DELETE。移除还要求安装的repository_selection为selected；不能用它从所有仓库安装中排除一个仓库，或移除应用在组织中可访问的最后一个仓库。

另一项变化是：应用已经安装在组织、相关组织权限已获所有者批准后，仓库管理员可编辑现有安装，把自己的仓库加入。组织所有者仍可限制此行为；全部组织级权限、仓库管理和仓库创建这三类敏感权限仍需所有者批准。

offline_access改变令牌期限，不改变应用权限

GitHub App的用户访问令牌代表用户执行操作，与代表一次应用安装的安装访问令牌用途不同。这次offline_access支持针对用户授权，不能把两种令牌的期限或刷新流程混在一起。

即使应用全局选择了用户令牌不过期，开发者也能在某次用户授权中请求offline_access，让这一次返回会过期的用户令牌和刷新令牌。影响仅限这次授权，不会自动套用到以后所有会话。

GitHub App的scope参数不用于动态申请仓库或组织权限。此处支持的offline_access只选择过期机制；应用权限仍在应用注册中静态配置，用户令牌也受应用与用户双方现有权限限制。

因此，逐人试用短期令牌与缩减仓库权限应作为两个检查项。前者降低长期持有同一令牌的风险，后者约束令牌能做什么；启用offline_access本身不会临时增权或撤回已有权限。

先接好刷新，再安排8小时到期后的工作

官方文档给出的期限是用户访问令牌8小时、刷新令牌6个月。用刷新令牌换取新的一对令牌后，旧刷新令牌和旧用户访问令牌都会失效，不能把旧刷新令牌反复复用。

刷新请求向GitHub的/login/oauth/access_token路径发送POST，grant_type取refresh_token，并提供应用的client_id和当前refresh_token。client_id与App ID不是同一个值；除用户令牌由device flow生成的情况外，还需要client_secret。

实现时读取响应中的access_token、expires_in、refresh_token和refresh_token_expires_in，安全保存新的一对令牌，并让后续请求使用新值。完整请求和字段含义见来源中的官方刷新文档，不要把真实令牌或客户端密钥粘贴进工单。

作为迁移建议，可先在可控的测试授权中核对首次获取、一次刷新、旧令牌失效和客户端恢复路径，再扩大范围。这里没有执行授权、刷新或接口变更，这些步骤也不是已完成的实测结果。

逐步迁移时，别把旧令牌误当成已经到期

假设一个应用有交互式网页和长时间运行的命令行客户端。可以先对已支持刷新的测试客户端使用offline_access，观察到期与恢复处理，再安排其他客户端接入；这是说明迁移顺序的假设场景，不代表任何现成客户端已支持。

新建应用默认开启用户令牌过期，除非开发者选择退出。已存在的应用可在Developer settings下进入GitHub Apps，编辑目标应用，再到Optional Features调整User-to-server token expiration。操作前先确认自己管理的是哪个应用。

如果过去已签发不过期的用户令牌，后来重新开启全局过期设置，这些旧令牌仍不会自动过期。官方给出的处理方式是让用户重新认证，或通过文档中的令牌撤销接口删除旧令牌；应按自己的迁移安排选择，不能把开关切换当作已完成轮换。

记录每个客户端是否能刷新、是否仍持有旧令牌及重新认证的恢复方式，比只看全局开关更能判断迁移进度。本文没有操作任何账户、安装、权限或真实凭据。

GitHub Enterprise Server要分别看3.23和3.24

公告把大部分改进对应到GitHub Enterprise Server 3.24，offline_access例外，对应3.23。较旧部署不能仅凭GitHub.com公告就假定已有支持；这些来源没有给出每个Server版本的具体部署日期或全部实例的就绪状态。

GitHub App凭据现在集中到独立的Credentials标签页，方便管理。公告提到为未来的workload federation凭据预留空间，但这只是计划中的工作负载身份联合能力，不能把新标签页当成该能力已经上线。

以上来源没有宣布新的价格、国家资格名单或强制全体应用迁移截止日。按实际GitHub产品、组织策略和部署版本安排变更，不因使用英文界面或来自某个国家就推定权限不同。