mise token github排查 GitHub 认证来源的调试利器【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise 在解析工具版本、下载发布资产或访问私有仓库时依赖 GitHub Token而 Token 可能来自环境变量、配置文件、gh CLI、OAuth 或 git 凭据助手等多个来源。mise token github用于显示 mise 针对指定 GitHub 主机实际会使用的 Token 及其来源是定位认证失败问题的首选诊断入口。读完本文你将掌握该命令的全部参数与输出格式理解 8 级 Token 解析优先级背后的源码实现并能针对 GitHub Enterprise、CI、OAuth 设备码等场景给出可落地的排障方案。命令概览mise token github是一个只读命令不会向 GitHub 发起任何请求也不修改任何凭据仅在本机解析并打印结果。其完整签名如下用法mise token github [FLAGS] [HOST]效果只读read-only源码位置src/cli/token/github.rs从命令结构看它隶属于mise token子命令族docs/cli/token/目录下还有 gitlab、forgejo 等对应子命令全局标志与参数语法可参考 Global flags and argument syntax命令行解析由usage_rs::Argsderive 宏生成见 src/cli/token/github.rs#L9-L28。该命令的核心行为是默认对 Token 进行掩码处理只显示前 4 位与后 4 位字符同时标注来源source既便于排查认证问题又避免在日志或终端中泄露完整凭据。参数与标志详解位置参数[HOST]指定要查询的 GitHub 主机名默认值为github.com对应源码中的#[usage(default github.com)]见 src/cli/token/github.rs#L30-L32。查询公共 GitHub省略参数或显式传github.com查询 GitHub Enterprise 实例传入对应主机名如github.mycompany.com该参数支持api.github.com与github.com之间的规范化映射源码中canonical_token_host会将api.github.com映射为github.com见 src/github.rs#L586-L592标志Flags标志说明源码依据--oauth仅通过原生 GitHub OAuth 来源解析缓存、刷新或设备码流程跳过其他 Token 来源src/cli/token/github.rs#L38-L41--raw仅打印 Token 值本身不包含主机名与来源前缀src/cli/token/github.rs#L43-L45--refresh即使缓存 Token 未过期也重新签发 OAuth Token先走 refresh-token grant失败则回退到新的设备码流程。在修改了 GitHub App 的安装范围或权限后使用因为缓存的 Token 会保留其签发时的原始访问权限直到过期src/cli/token/github.rs#L47-L52--unmask显示完整的未掩码 Tokensrc/cli/token/github.rs#L54-L56-h, --help打印帮助信息—需要注意两个约束关系--refresh带有requires oauth属性见 src/cli/token/github.rs#L51即必须与--oauth搭配使用单独使用会报参数校验错误--raw与--unmask都会输出完整凭据--raw只打印裸 Token 值便于管道传输--unmask则保留host: token (source: ...)的完整格式。二者都不应出现在共享的诊断日志中详见 docs/dev-tools/github-tokens.md 的调试章节。隐藏参数--git-credential源码中还定义了一个hide true的参数git_credential见 src/cli/token/github.rs#L34-L36用于说 Git 凭据助手协议。当该参数被传入时命令会直接转交git_credential::run(operation)处理见 src/cli/token/github.rs#L61-L63。这是内部为 git 集成预留的通道普通用户无需关注。输出格式与示例默认输出掩码mise token github github.com: ghp_…xxxx (source: GITHUB_TOKEN)输出格式为{host}: {masked_token} (source: {source})。掩码规则实现在 src/tokens.rs#L251-L263Token 长度 ≤ 4全部替换为*长度 ≤ 8保留前 4 位后接…长度 8保留前 4 位与后 4 位中间以…连接完整显示--unmaskmise token github --unmask github.com: ghp_xxxxxxxxxxxx (source: GITHUB_TOKEN)未配置 Token 的主机mise token github github.mycompany.com github.mycompany.com: (none)当解析结果为None时即所有来源都未命中输出(none)若同时使用了--raw则会直接以错误退出并提示no GitHub token found for {host}见 src/cli/token/github.rs#L90-L95。强制 OAuth 来源并刷新mise token github --oauth --refresh github.com: gho_…xxxx (source: GitHub OAuth)此例中 Token 前缀gho_表明它是 GitHub App 签发的 OAuth Token而非个人访问令牌ghp_。源码中--oauth分支会构造TokenRequest同时开启allow_device_flow: true与force_refresh: self.refresh并以TokenSource::GithubOauth作为来源标签见 src/cli/token/github.rs#L64-L73。来源优先级8 级 Token 解析链mise token github的核心价值在于揭示mise 会从哪个来源取 Token。这一逻辑集中在 src/github.rs#L729-L803 的resolve_token_inner函数中按优先级依次尝试第一个命中者胜出。优先级越高越靠前而一个错误或已过期的高优先级 Token 会遮蔽下方正常可用的来源这正是Token 存在但安装失败的常见根因。github.com 的解析顺序优先级来源对应 TokenSource1MISE_GITHUB_TOKEN环境变量EnvVar(MISE_GITHUB_TOKEN)2GITHUB_API_TOKEN环境变量EnvVar(GITHUB_API_TOKEN)3GITHUB_TOKEN环境变量EnvVar(GITHUB_TOKEN)4credential_command若配置CredentialCommand5原生 GitHub OAuth若配置GithubOauth6github_tokens.toml按主机TokensFile7gh CLI Token来自hosts.ymlGhCli8git credential fill若启用GitCredential三个环境变量按GITHUB_TOKEN_ENV_VARS常量顺序逐一检查src/github.rs#L680-L681因此MISE_GITHUB_TOKEN始终优先于GITHUB_TOKEN。注意GH_TOKEN不是 mise 的直接 Token 来源——但如果你配置了gh auth token作为credential_command它依然能间接生效。GitHub Enterprise 的解析顺序对于非github.com主机优先级变为见 docs/dev-tools/github-tokens.md 与源码中is_ghcom分支 src/github.rs#L741-L747优先级来源1MISE_GITHUB_ENTERPRISE_TOKEN环境变量2MISE_GITHUB_TOKEN/GITHUB_API_TOKEN/GITHUB_TOKEN环境变量3credential_command若配置4原生 GitHub OAuth若配置5github_tokens.toml按主机6gh CLI Token来自hosts.yml按主机名匹配7git credential fill若启用一个值得注意的细节github.com 的通用环境变量在MISE_GITHUB_ENTERPRISE_TOKEN未设置时会作为 GHE 的兜底来源。若你同时需要 github.com 与某个 GHE 实例使用不同 Token就必须显式设置MISE_GITHUB_ENTERPRISE_TOKEN或改用 gh CLI 集成、github_tokens.toml等按主机区分的方案。两个特殊分支发布资产主机短路对objects.githubusercontent.com、release-assets.githubusercontent.com等资产下载域名resolve_token_inner直接返回None避免将 GitHub Token 误发往非 API 域名src/github.rs#L594-L605、L732-L734。git 场景不递归调用凭据助手resolve_token_for_git以use_git_credentials: false调用因为 git 本身已经执行过其配置的凭据助手mise 不再重复触发src/github.rs#L724-L727。各 Token 来源配置实战方式一环境变量最直接export MISE_GITHUB_TOKENghp_xxxxxxxxxxxx对于公开仓库的发布访问经典个人访问令牌无需私有仓库 scope访问私有仓库时需要为令牌授予仓库访问权及 API 所需权限细粒度令牌至少需要Contents: read才能下载发布资产。已有GITHUB_TOKEN时在无更高优先级来源覆盖的前提下也能直接生效。方式二Token 文件github_tokens.toml按主机隔离# ~/.config/mise/github_tokens.toml [tokens.github.com] token ghp_xxxxxxxxxxxx [tokens.github.mycompany.com] token ghp_yyyyyyyyyyyy该文件在环境变量、credential_command、原生 OAuth 之后、gh CLI 文件之前被检查对应源码优先级第 6 位。文件位置遵循MISE_CONFIG_DIR默认~/.config/mise无需额外设置即自动生效。解析逻辑见 src/tokens.rs#L35-L43 的parse_tokens_toml。该文件存放明文凭据建议设置仅本人可读chmod 600 ${MISE_CONFIG_DIR:-$HOME/.config/mise}/github_tokens.toml适合的使用场景不使用 gh CLIgh CLI Token 权限受限如 Coder 预置的、仅限特定组织的 Token而需要更宽的 Token或者希望 Token 与其他工具互不干扰。方式三gh CLI 集成默认启用mise 直接读取 gh CLI 的hosts.yml配置文件不会 shell 调出gh进程。按以下位置依次查找首个命中者胜出$GH_CONFIG_DIR/hosts.yml$XDG_CONFIG_HOME/gh/hosts.yml当该变量被设置时~/Library/Application Support/gh/hosts.yml仅 macOS%APPDATA%\GitHub CLI\hosts.yml仅 Windowsgh 在该平台的默认位置~/.config/gh/hosts.yml这一方式对 GitHub Enterprise 尤其有用——gh CLI 按主机存储 Token因此 mise 无需来回切换环境变量即可认证多个 GHE 实例# ~/.config/gh/hosts.yml由 gh auth login 管理 github.com: oauth_token: ghp_xxxxxxxxxxxx user: you github.mycompany.com: oauth_token: ghp_yyyyyyyyyyyy user: youhosts.yml的解析实现在 src/tokens.rs#L265-L335支持oauth_token、token、access_token、access-token等字段名。若 gh CLI 配置了凭据助手如 macOS Keychain而非在hosts.yml中存储 Token此方法取不到 Token——此时应改用git credential fill见下文。如需关闭该行为[settings.github] gh_cli_tokens false方式四credential_command自定义凭据命令在全局设置中配置自定义命令以获取 GitHub Token。github.credential_command仅限全局配置项目级配置无法选择凭据命令这是刻意的安全设计——项目不能读取你的凭据[settings.github] credential_command op read op://Private/GitHub Token/credential执行细节见 src/tokens.rs#L69-L158 的get_credential_command_tokenmise 使用配置的默认内联 shellunix_default_inline_shell_args或windows_default_inline_shell_args执行该命令并从 stdout 读取 Token主机名通过MISE_CREDENTIAL_HOST传入提供商名github通过MISE_CREDENTIAL_PROVIDER传入为兼容性ash、bash、dash、ksh、sh、zsh等 sh 兼容 shell 还会额外收到$1/${1}作为主机名参数src/tokens.rs#L186-L194命令以移除 mise shims 的 PATH运行避免递归调用 mise结果按{provider}:{host}键缓存在进程生命周期内src/tokens.rs#L17-L18同一主机只执行一次该来源在github_tokens.toml与 gh CLI 之前检查优先级高于文件类来源。计划弃用警告旧的$1/${1}主机名参数已弃用请改用MISE_CREDENTIAL_HOST。mise 将在2026.11.0开始告警$1兼容将在2027.11.0移除。搭配 ghtkn 生成短期 Tokenghtkn 可生成短期有效的 GitHub App 用户访问令牌并打印到 stdout天然兼容credential_command。建议先手动执行一次ghtkn get让基于浏览器的设备码流程按预期发生之后 ghtkn 可复用操作系统密钥管理器中的 Token 直到需要重新生成。若 ghtkn 由 mise 安装务必用mise which找到真实可执行路径写入命令避免经由 shim 递归调用mise settings set github.credential_command\$(mise which ghtkn)\ get -m 1h若 ghtkn 已不依赖 mise shim 可用也可直接配置[settings.github] credential_command ghtkn get -m 1h注意不要将mise x、mise exec等可能反过来需要 GitHub 访问权限的命令写进 credential_command否则会在获取 Token 时形成死循环。方式五原生 GitHub OAuth设备码流程mise 可以直接通过 GitHub 的 OAuth 设备码流程创建短期 GitHub App 用户访问令牌无需个人访问令牌、App 私钥、客户端密钥、gh、ghtkn 或任何外部凭据命令。该设计受 ghtkn 启发若你更希望由独立进程生成 Token 再由credential_command接管参见上文 ghtkn 一节。配置步骤# 1. 创建启用 device flow 的 GitHub App配置其 client ID mise settings set github.oauth_client_idIv1.yourgithubappclientid # 2. 首次授权会触发浏览器设备码流程 mise token github --oauth此后 mise 会为自己的 GitHub API 调用复用缓存的 Token并在 GitHub 返回 refresh token 时自动刷新。缓存 Token 有效期间mise 还会通过mise activate/mise hook-env/mise env/mise exec将其以GITHUB_TOKEN导出到你的 shell 环境使gh等读取GITHUB_TOKEN的工具直接可用mise exec -- gh pr list相关机制说明mise不会替换已存在的导出变量值git 凭据助手与 Cargo registry 认证各有自己的配置导出GITHUB_TOKEN并不会自动配置它们若想改用其他变量名如 gh 偏好的GH_TOKEN设置github.oauth_export_env设为空字符串则禁用自动导出需要将 Token 管道传给其他命令时用mise token github --oauth --raw裸输出是机密仅在其他命令确实需要 Token 值时使用把该值复制进MISE_GITHUB_TOKEN会让环境变量在后续解析中优先于 OAuth修改了 GitHub App 的权限或安装范围后缓存 Token 仍保留签发时的原始访问权直到过期此时执行mise token github --oauth --refresh源码中force_refresh会先尝试 refresh-token grant失败再回退到设备码流程见 src/github/oauth.rs#L17-L33。可选的完整设置[settings.github] oauth_client_id Iv1.yourgithubappclientid oauth_scopes # GitHub App 用户访问令牌通常为空 oauth_open_browser true oauth_export_env GITHUB_TOKEN # 设为 可禁用自动导出方式六git 凭据助手可选兜底mise 可复用既有的 git 凭据助手获取 GitHub Token。该行为默认关闭作为所有其他来源之后的最后兜底对应优先级第 8 位。启用方式[settings.github] use_git_credentials truemise 以GIT_TERMINAL_PROMPT0运行git credential fill防止交互式提示并按主机在会话内缓存结果实现见 src/tokens.rs#L200-L249。典型适用场景Devcontainer 环境Token 由 git 凭据助手提供macOS / Windowsgh auth login将 Token 存入系统钥匙串macOS Keychain、Windows 凭据管理器而非hosts.yml此时hosts.yml存在但没有oauth_token键读取无济于事。判据mise token github打印(none)而gh auth status正常就应启用此设置或配置调用 gh 的credential_command任何 git 已配置凭据的环境。单账号场景credential_command gh auth token即可多主机GHE场景需传入 mise 正在查询的主机因为裸gh auth token返回的是 gh 自身活动主机的 Token。macOS/Linux 与 Windows 的内联 shell 变量语法不同# macOS / Linux [settings.github] credential_command gh auth token --hostname $MISE_CREDENTIAL_HOST# Windowscmd 不展开 $VAR [settings.github] credential_command gh auth token --hostname %MISE_CREDENTIAL_HOST%调试 Token 解析问题mise token github的掩码输出足以区分配置问题与API 故障无需暴露完整凭据mise token github mise token github github.mycompany.com结合 docs/dev-tools/github-tokens.md 的排查表常见症状与对策如下症状检查方向意外选中了某个环境变量清理进程环境中该覆盖变量优先级更高的来源命中后低优先级来源根本不会被查询输出(none)但gh auth status正常gh 可能使用系统钥匙串配置带主机感知的 credential_command或启用 git 凭据助手选中了 Token 但仓库仍不可访问检查仓库访问权限、Token 过期时间、组织授权与 API 主机GitHub 返回403或429检查响应中的限流详情403也可能是权限失败OAuth 刷新被拒绝检查配置的 GitHub App client ID修正后重新执行mise token github --oauth --refresh--unmask与--raw用于需要完整凭据的少数场景不应纳入共享诊断日志。关联场景GitHub Enterprise 与 CI自托管 GitHubGHE为工具指定api_url后端选项[tools] github:myorg/mytool { version latest, api_url https://github.mycompany.com/api/v3 }认证按前文 Enterprise 优先级依次检查。多个 GHE 实例需要不同 Token 时单一MISE_GITHUB_ENTERPRISE_TOKEN无法区分应改用github_tokens.toml、gh CLI 集成、credential_command或 git 凭据助手gh auth login --hostname github.mycompany.com gh auth login --hostname github.other-company.comCI / GitHub ActionsGitHub 通过secrets.GITHUB_TOKEN与github.token上下文提供工作流 Token作为环境变量传给运行 mise 的 shell 命令即可# checkout 与 mise setup 之后的步骤 - name: Install development tools run: mise install env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}工作流 Token 的权限与仓库范围仍然生效。若私有工具位于其他仓库可能需要以 Actions secret 形式存储具备该仓库访问权的 GitHub App Token 或个人访问令牌。补充提示mise 也支持.netrc的 HTTP Basic 认证.netrc凭据优先于基于 Token 的认证头详见 URL Replacements。借助 lockfile 可以显著减少发布发现请求mise lock记录所需产物 URL 与校验和mise install即可离线安装从而降低公开下载场景下的 Token 需求但私有制品、provenance 校验与 Packslip 策略检查仍可能需要网络或认证CI 中应保留必要凭据。mise token github的价值在于把mise 到底会用什么 Token这一黑盒问题显式化通过一次只读调用即可确认来源、掩码展示避免泄密再配合本文的优先级矩阵与各来源配置绝大多数 GitHub 认证问题都能被快速定位并修复。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 mise token github：排查 GitHub 认证来源的调试利器
mise token github排查 GitHub 认证来源的调试利器【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise 在解析工具版本、下载发布资产或访问私有仓库时依赖 GitHub Token而 Token 可能来自环境变量、配置文件、gh CLI、OAuth 或 git 凭据助手等多个来源。mise token github用于显示 mise 针对指定 GitHub 主机实际会使用的 Token 及其来源是定位认证失败问题的首选诊断入口。读完本文你将掌握该命令的全部参数与输出格式理解 8 级 Token 解析优先级背后的源码实现并能针对 GitHub Enterprise、CI、OAuth 设备码等场景给出可落地的排障方案。命令概览mise token github是一个只读命令不会向 GitHub 发起任何请求也不修改任何凭据仅在本机解析并打印结果。其完整签名如下用法mise token github [FLAGS] [HOST]效果只读read-only源码位置src/cli/token/github.rs从命令结构看它隶属于mise token子命令族docs/cli/token/目录下还有 gitlab、forgejo 等对应子命令全局标志与参数语法可参考 Global flags and argument syntax命令行解析由usage_rs::Argsderive 宏生成见 src/cli/token/github.rs#L9-L28。该命令的核心行为是默认对 Token 进行掩码处理只显示前 4 位与后 4 位字符同时标注来源source既便于排查认证问题又避免在日志或终端中泄露完整凭据。参数与标志详解位置参数[HOST]指定要查询的 GitHub 主机名默认值为github.com对应源码中的#[usage(default github.com)]见 src/cli/token/github.rs#L30-L32。查询公共 GitHub省略参数或显式传github.com查询 GitHub Enterprise 实例传入对应主机名如github.mycompany.com该参数支持api.github.com与github.com之间的规范化映射源码中canonical_token_host会将api.github.com映射为github.com见 src/github.rs#L586-L592标志Flags标志说明源码依据--oauth仅通过原生 GitHub OAuth 来源解析缓存、刷新或设备码流程跳过其他 Token 来源src/cli/token/github.rs#L38-L41--raw仅打印 Token 值本身不包含主机名与来源前缀src/cli/token/github.rs#L43-L45--refresh即使缓存 Token 未过期也重新签发 OAuth Token先走 refresh-token grant失败则回退到新的设备码流程。在修改了 GitHub App 的安装范围或权限后使用因为缓存的 Token 会保留其签发时的原始访问权限直到过期src/cli/token/github.rs#L47-L52--unmask显示完整的未掩码 Tokensrc/cli/token/github.rs#L54-L56-h, --help打印帮助信息—需要注意两个约束关系--refresh带有requires oauth属性见 src/cli/token/github.rs#L51即必须与--oauth搭配使用单独使用会报参数校验错误--raw与--unmask都会输出完整凭据--raw只打印裸 Token 值便于管道传输--unmask则保留host: token (source: ...)的完整格式。二者都不应出现在共享的诊断日志中详见 docs/dev-tools/github-tokens.md 的调试章节。隐藏参数--git-credential源码中还定义了一个hide true的参数git_credential见 src/cli/token/github.rs#L34-L36用于说 Git 凭据助手协议。当该参数被传入时命令会直接转交git_credential::run(operation)处理见 src/cli/token/github.rs#L61-L63。这是内部为 git 集成预留的通道普通用户无需关注。输出格式与示例默认输出掩码mise token github github.com: ghp_…xxxx (source: GITHUB_TOKEN)输出格式为{host}: {masked_token} (source: {source})。掩码规则实现在 src/tokens.rs#L251-L263Token 长度 ≤ 4全部替换为*长度 ≤ 8保留前 4 位后接…长度 8保留前 4 位与后 4 位中间以…连接完整显示--unmaskmise token github --unmask github.com: ghp_xxxxxxxxxxxx (source: GITHUB_TOKEN)未配置 Token 的主机mise token github github.mycompany.com github.mycompany.com: (none)当解析结果为None时即所有来源都未命中输出(none)若同时使用了--raw则会直接以错误退出并提示no GitHub token found for {host}见 src/cli/token/github.rs#L90-L95。强制 OAuth 来源并刷新mise token github --oauth --refresh github.com: gho_…xxxx (source: GitHub OAuth)此例中 Token 前缀gho_表明它是 GitHub App 签发的 OAuth Token而非个人访问令牌ghp_。源码中--oauth分支会构造TokenRequest同时开启allow_device_flow: true与force_refresh: self.refresh并以TokenSource::GithubOauth作为来源标签见 src/cli/token/github.rs#L64-L73。来源优先级8 级 Token 解析链mise token github的核心价值在于揭示mise 会从哪个来源取 Token。这一逻辑集中在 src/github.rs#L729-L803 的resolve_token_inner函数中按优先级依次尝试第一个命中者胜出。优先级越高越靠前而一个错误或已过期的高优先级 Token 会遮蔽下方正常可用的来源这正是Token 存在但安装失败的常见根因。github.com 的解析顺序优先级来源对应 TokenSource1MISE_GITHUB_TOKEN环境变量EnvVar(MISE_GITHUB_TOKEN)2GITHUB_API_TOKEN环境变量EnvVar(GITHUB_API_TOKEN)3GITHUB_TOKEN环境变量EnvVar(GITHUB_TOKEN)4credential_command若配置CredentialCommand5原生 GitHub OAuth若配置GithubOauth6github_tokens.toml按主机TokensFile7gh CLI Token来自hosts.ymlGhCli8git credential fill若启用GitCredential三个环境变量按GITHUB_TOKEN_ENV_VARS常量顺序逐一检查src/github.rs#L680-L681因此MISE_GITHUB_TOKEN始终优先于GITHUB_TOKEN。注意GH_TOKEN不是 mise 的直接 Token 来源——但如果你配置了gh auth token作为credential_command它依然能间接生效。GitHub Enterprise 的解析顺序对于非github.com主机优先级变为见 docs/dev-tools/github-tokens.md 与源码中is_ghcom分支 src/github.rs#L741-L747优先级来源1MISE_GITHUB_ENTERPRISE_TOKEN环境变量2MISE_GITHUB_TOKEN/GITHUB_API_TOKEN/GITHUB_TOKEN环境变量3credential_command若配置4原生 GitHub OAuth若配置5github_tokens.toml按主机6gh CLI Token来自hosts.yml按主机名匹配7git credential fill若启用一个值得注意的细节github.com 的通用环境变量在MISE_GITHUB_ENTERPRISE_TOKEN未设置时会作为 GHE 的兜底来源。若你同时需要 github.com 与某个 GHE 实例使用不同 Token就必须显式设置MISE_GITHUB_ENTERPRISE_TOKEN或改用 gh CLI 集成、github_tokens.toml等按主机区分的方案。两个特殊分支发布资产主机短路对objects.githubusercontent.com、release-assets.githubusercontent.com等资产下载域名resolve_token_inner直接返回None避免将 GitHub Token 误发往非 API 域名src/github.rs#L594-L605、L732-L734。git 场景不递归调用凭据助手resolve_token_for_git以use_git_credentials: false调用因为 git 本身已经执行过其配置的凭据助手mise 不再重复触发src/github.rs#L724-L727。各 Token 来源配置实战方式一环境变量最直接export MISE_GITHUB_TOKENghp_xxxxxxxxxxxx对于公开仓库的发布访问经典个人访问令牌无需私有仓库 scope访问私有仓库时需要为令牌授予仓库访问权及 API 所需权限细粒度令牌至少需要Contents: read才能下载发布资产。已有GITHUB_TOKEN时在无更高优先级来源覆盖的前提下也能直接生效。方式二Token 文件github_tokens.toml按主机隔离# ~/.config/mise/github_tokens.toml [tokens.github.com] token ghp_xxxxxxxxxxxx [tokens.github.mycompany.com] token ghp_yyyyyyyyyyyy该文件在环境变量、credential_command、原生 OAuth 之后、gh CLI 文件之前被检查对应源码优先级第 6 位。文件位置遵循MISE_CONFIG_DIR默认~/.config/mise无需额外设置即自动生效。解析逻辑见 src/tokens.rs#L35-L43 的parse_tokens_toml。该文件存放明文凭据建议设置仅本人可读chmod 600 ${MISE_CONFIG_DIR:-$HOME/.config/mise}/github_tokens.toml适合的使用场景不使用 gh CLIgh CLI Token 权限受限如 Coder 预置的、仅限特定组织的 Token而需要更宽的 Token或者希望 Token 与其他工具互不干扰。方式三gh CLI 集成默认启用mise 直接读取 gh CLI 的hosts.yml配置文件不会 shell 调出gh进程。按以下位置依次查找首个命中者胜出$GH_CONFIG_DIR/hosts.yml$XDG_CONFIG_HOME/gh/hosts.yml当该变量被设置时~/Library/Application Support/gh/hosts.yml仅 macOS%APPDATA%\GitHub CLI\hosts.yml仅 Windowsgh 在该平台的默认位置~/.config/gh/hosts.yml这一方式对 GitHub Enterprise 尤其有用——gh CLI 按主机存储 Token因此 mise 无需来回切换环境变量即可认证多个 GHE 实例# ~/.config/gh/hosts.yml由 gh auth login 管理 github.com: oauth_token: ghp_xxxxxxxxxxxx user: you github.mycompany.com: oauth_token: ghp_yyyyyyyyyyyy user: youhosts.yml的解析实现在 src/tokens.rs#L265-L335支持oauth_token、token、access_token、access-token等字段名。若 gh CLI 配置了凭据助手如 macOS Keychain而非在hosts.yml中存储 Token此方法取不到 Token——此时应改用git credential fill见下文。如需关闭该行为[settings.github] gh_cli_tokens false方式四credential_command自定义凭据命令在全局设置中配置自定义命令以获取 GitHub Token。github.credential_command仅限全局配置项目级配置无法选择凭据命令这是刻意的安全设计——项目不能读取你的凭据[settings.github] credential_command op read op://Private/GitHub Token/credential执行细节见 src/tokens.rs#L69-L158 的get_credential_command_tokenmise 使用配置的默认内联 shellunix_default_inline_shell_args或windows_default_inline_shell_args执行该命令并从 stdout 读取 Token主机名通过MISE_CREDENTIAL_HOST传入提供商名github通过MISE_CREDENTIAL_PROVIDER传入为兼容性ash、bash、dash、ksh、sh、zsh等 sh 兼容 shell 还会额外收到$1/${1}作为主机名参数src/tokens.rs#L186-L194命令以移除 mise shims 的 PATH运行避免递归调用 mise结果按{provider}:{host}键缓存在进程生命周期内src/tokens.rs#L17-L18同一主机只执行一次该来源在github_tokens.toml与 gh CLI 之前检查优先级高于文件类来源。计划弃用警告旧的$1/${1}主机名参数已弃用请改用MISE_CREDENTIAL_HOST。mise 将在2026.11.0开始告警$1兼容将在2027.11.0移除。搭配 ghtkn 生成短期 Tokenghtkn 可生成短期有效的 GitHub App 用户访问令牌并打印到 stdout天然兼容credential_command。建议先手动执行一次ghtkn get让基于浏览器的设备码流程按预期发生之后 ghtkn 可复用操作系统密钥管理器中的 Token 直到需要重新生成。若 ghtkn 由 mise 安装务必用mise which找到真实可执行路径写入命令避免经由 shim 递归调用mise settings set github.credential_command\$(mise which ghtkn)\ get -m 1h若 ghtkn 已不依赖 mise shim 可用也可直接配置[settings.github] credential_command ghtkn get -m 1h注意不要将mise x、mise exec等可能反过来需要 GitHub 访问权限的命令写进 credential_command否则会在获取 Token 时形成死循环。方式五原生 GitHub OAuth设备码流程mise 可以直接通过 GitHub 的 OAuth 设备码流程创建短期 GitHub App 用户访问令牌无需个人访问令牌、App 私钥、客户端密钥、gh、ghtkn 或任何外部凭据命令。该设计受 ghtkn 启发若你更希望由独立进程生成 Token 再由credential_command接管参见上文 ghtkn 一节。配置步骤# 1. 创建启用 device flow 的 GitHub App配置其 client ID mise settings set github.oauth_client_idIv1.yourgithubappclientid # 2. 首次授权会触发浏览器设备码流程 mise token github --oauth此后 mise 会为自己的 GitHub API 调用复用缓存的 Token并在 GitHub 返回 refresh token 时自动刷新。缓存 Token 有效期间mise 还会通过mise activate/mise hook-env/mise env/mise exec将其以GITHUB_TOKEN导出到你的 shell 环境使gh等读取GITHUB_TOKEN的工具直接可用mise exec -- gh pr list相关机制说明mise不会替换已存在的导出变量值git 凭据助手与 Cargo registry 认证各有自己的配置导出GITHUB_TOKEN并不会自动配置它们若想改用其他变量名如 gh 偏好的GH_TOKEN设置github.oauth_export_env设为空字符串则禁用自动导出需要将 Token 管道传给其他命令时用mise token github --oauth --raw裸输出是机密仅在其他命令确实需要 Token 值时使用把该值复制进MISE_GITHUB_TOKEN会让环境变量在后续解析中优先于 OAuth修改了 GitHub App 的权限或安装范围后缓存 Token 仍保留签发时的原始访问权直到过期此时执行mise token github --oauth --refresh源码中force_refresh会先尝试 refresh-token grant失败再回退到设备码流程见 src/github/oauth.rs#L17-L33。可选的完整设置[settings.github] oauth_client_id Iv1.yourgithubappclientid oauth_scopes # GitHub App 用户访问令牌通常为空 oauth_open_browser true oauth_export_env GITHUB_TOKEN # 设为 可禁用自动导出方式六git 凭据助手可选兜底mise 可复用既有的 git 凭据助手获取 GitHub Token。该行为默认关闭作为所有其他来源之后的最后兜底对应优先级第 8 位。启用方式[settings.github] use_git_credentials truemise 以GIT_TERMINAL_PROMPT0运行git credential fill防止交互式提示并按主机在会话内缓存结果实现见 src/tokens.rs#L200-L249。典型适用场景Devcontainer 环境Token 由 git 凭据助手提供macOS / Windowsgh auth login将 Token 存入系统钥匙串macOS Keychain、Windows 凭据管理器而非hosts.yml此时hosts.yml存在但没有oauth_token键读取无济于事。判据mise token github打印(none)而gh auth status正常就应启用此设置或配置调用 gh 的credential_command任何 git 已配置凭据的环境。单账号场景credential_command gh auth token即可多主机GHE场景需传入 mise 正在查询的主机因为裸gh auth token返回的是 gh 自身活动主机的 Token。macOS/Linux 与 Windows 的内联 shell 变量语法不同# macOS / Linux [settings.github] credential_command gh auth token --hostname $MISE_CREDENTIAL_HOST# Windowscmd 不展开 $VAR [settings.github] credential_command gh auth token --hostname %MISE_CREDENTIAL_HOST%调试 Token 解析问题mise token github的掩码输出足以区分配置问题与API 故障无需暴露完整凭据mise token github mise token github github.mycompany.com结合 docs/dev-tools/github-tokens.md 的排查表常见症状与对策如下症状检查方向意外选中了某个环境变量清理进程环境中该覆盖变量优先级更高的来源命中后低优先级来源根本不会被查询输出(none)但gh auth status正常gh 可能使用系统钥匙串配置带主机感知的 credential_command或启用 git 凭据助手选中了 Token 但仓库仍不可访问检查仓库访问权限、Token 过期时间、组织授权与 API 主机GitHub 返回403或429检查响应中的限流详情403也可能是权限失败OAuth 刷新被拒绝检查配置的 GitHub App client ID修正后重新执行mise token github --oauth --refresh--unmask与--raw用于需要完整凭据的少数场景不应纳入共享诊断日志。关联场景GitHub Enterprise 与 CI自托管 GitHubGHE为工具指定api_url后端选项[tools] github:myorg/mytool { version latest, api_url https://github.mycompany.com/api/v3 }认证按前文 Enterprise 优先级依次检查。多个 GHE 实例需要不同 Token 时单一MISE_GITHUB_ENTERPRISE_TOKEN无法区分应改用github_tokens.toml、gh CLI 集成、credential_command或 git 凭据助手gh auth login --hostname github.mycompany.com gh auth login --hostname github.other-company.comCI / GitHub ActionsGitHub 通过secrets.GITHUB_TOKEN与github.token上下文提供工作流 Token作为环境变量传给运行 mise 的 shell 命令即可# checkout 与 mise setup 之后的步骤 - name: Install development tools run: mise install env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}工作流 Token 的权限与仓库范围仍然生效。若私有工具位于其他仓库可能需要以 Actions secret 形式存储具备该仓库访问权的 GitHub App Token 或个人访问令牌。补充提示mise 也支持.netrc的 HTTP Basic 认证.netrc凭据优先于基于 Token 的认证头详见 URL Replacements。借助 lockfile 可以显著减少发布发现请求mise lock记录所需产物 URL 与校验和mise install即可离线安装从而降低公开下载场景下的 Token 需求但私有制品、provenance 校验与 Packslip 策略检查仍可能需要网络或认证CI 中应保留必要凭据。mise token github的价值在于把mise 到底会用什么 Token这一黑盒问题显式化通过一次只读调用即可确认来源、掩码展示避免泄密再配合本文的优先级矩阵与各来源配置绝大多数 GitHub 认证问题都能被快速定位并修复。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考