feat(github): add github_tokens.toml, git credential fill, and mise github token command

[jdx]

Summary

• Adds github_tokens.toml ($MISE_CONFIG_DIR/github_tokens.toml) for per-host GitHub tokens that don't interfere with gh CLI's hosts.yml. Useful when gh CLI tokens have restricted scope or you want mise-specific tokens.
• Adds git credential fill integration (opt-in) as a last-resort fallback. Uses git's credential helpers (macOS Keychain, Windows Credential Manager, etc.) with GIT_TERMINAL_PROMPT=0 to prevent interactive prompts. Results are cached per host per session.
• Adds mise github token [host] command to display which token mise would use and where it came from. Supports --unmask to show the full token.
• New setting: github.use_git_credentials (default: false, env: MISE_GITHUB_USE_GIT_CREDENTIALS)

Updated token priority:

#	Source	New?
1	MISE_GITHUB_ENTERPRISE_TOKEN env var (non-github.com only)
2	MISE_GITHUB_TOKEN / GITHUB_API_TOKEN / GITHUB_TOKEN env vars
3	github_tokens.toml (per-host)	NEW
4	gh CLI token (from hosts.yml)
5	git credential fill	NEW (opt-in)

Key implementation details:

• *.githubusercontent.com and api.github.com hosts are normalized to github.com for token lookups
• is_gh_host() respects gh_cli_tokens setting — disabling gh CLI integration won't cause GHE hosts from hosts.yml to trigger git credential fill
• Env var tokens are trimmed (matching existing get_token() behavior in env.rs)
• Token masking hides short tokens (5-8 chars show ghp_… instead of full value)

Test plan

• Unit tests for github_tokens.toml parser (cargo test -- github::tests)
• Manual testing of all 5 token sources via mise github token --unmask
• Verified git credential fill works with system credential helpers
• E2E test in e2e/cli/test_github_token covering all sources, priority, masking, and settings
• test_settings_toml_is_sorted passes (setting in correct alphabetical position)
• CI passes

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches GitHub authentication header/token resolution logic and introduces an opt-in subprocess call to git credential fill, which could affect how API requests are authenticated across hosts.

Overview
Adds a new mise github token [--unmask] [HOST] command to display which GitHub token would be used (with masking by default), and wires it into the CLI/help/manpage/docs.

Refactors GitHub auth to centralize token lookup in github::resolve_token, expanding priority to include a per-host $MISE_CONFIG_DIR/github_tokens.toml file and an optional last-resort git credential fill fallback (cached per host), and updates HTTP header attachment logic accordingly. Also documents the new token sources and adds e2e + unit tests plus a new github.use_git_credentials setting/schema entry.

^{Written by Cursor Bugbot for commit e06d29b. This will update automatically on new commits. Configure here.}

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances mise's GitHub token management capabilities by introducing more flexible and robust methods for token discovery. It allows users to define host-specific tokens in a dedicated configuration file, integrates with system-wide git credential helpers for broader compatibility, and provides a new command-line tool for debugging token resolution. These changes aim to improve the developer experience by offering more options for authentication, especially in complex or restricted development environments, and by making it easier to understand how mise obtains GitHub tokens.

Highlights

• New GitHub Token Configuration File: Introduced github_tokens.toml ($MISE_CONFIG_DIR/github_tokens.toml) for managing per-host GitHub tokens. This file allows users to specify tokens for different GitHub instances without conflicting with gh CLI's hosts.yml, particularly useful in environments with restricted token scopes like Coder.
• Git Credential Helper Integration: Added support for git credential fill as a last-resort fallback for obtaining GitHub tokens. This leverages existing git credential helpers (e.g., macOS Keychain, Windows Credential Manager, Coder external auth) and is enabled by default. It operates non-interactively by setting GIT_TERMINAL_PROMPT=0 and caches results per host.
• New mise github token Command: Implemented a new CLI command, mise github token [host], to display which GitHub token mise would use for a given host and its source. A --unmask option is available to reveal the full token, aiding in debugging authentication issues.
• Updated GitHub Token Resolution Priority: Revised the order in which mise searches for GitHub tokens. The new priority is: MISE_GITHUB_ENTERPRISE_TOKEN (for GHE), standard MISE_GITHUB_TOKEN/GITHUB_API_TOKEN/GITHUB_TOKEN environment variables, github_tokens.toml, gh CLI's hosts.yml, and finally git credential fill.
• New Configuration Setting: Added a new setting, github.use_git_credentials (default: true), which can be configured via MISE_GITHUB_USE_GIT_CREDENTIALS environment variable or settings.toml to enable or disable the git credential fill integration.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request significantly enhances GitHub token management by introducing new token sources like github_tokens.toml and git credential fill, updating the token resolution priority, and adding a mise github token command for debugging. The documentation has been thoroughly updated to reflect these changes, and a new end-to-end test verifies the functionality. Feedback indicates two areas for improvement: the token resolution logic for standard environment variables needs to be refined to correctly handle empty values and ensure proper precedence, and the token masking logic requires adjustment to prevent full token exposure for certain token lengths (5-8 characters) to maintain security.

[gemini-code-assist]

The logic for resolving the token from standard environment variables and determining its source is incorrect. It uses env::GITHUB_TOKEN, which may have incorrect behavior with empty environment variables, and then separately tries to identify the source variable using std::env::var(...).is_ok(). This can lead to incorrect token resolution (e.g., not picking up a valid token if a higher-precedence one is empty) and reporting the wrong source.

To ensure correct behavior and precedence, I suggest replacing this block with explicit, ordered checks for each environment variable.

    if let Some(token) = std::env::var("MISE_GITHUB_TOKEN").ok().filter(|t| !t.is_empty()) {
        return Some((token, TokenSource::EnvVar("MISE_GITHUB_TOKEN")));
    }
    if let Some(token) = std::env::var("GITHUB_API_TOKEN").ok().filter(|t| !t.is_empty()) {
        return Some((token, TokenSource::EnvVar("GITHUB_API_TOKEN")));
    }
    if let Some(token) = std::env::var("GITHUB_TOKEN").ok().filter(|t| !t.is_empty()) {
        return Some((token, TokenSource::EnvVar("GITHUB_TOKEN")));
    }

[gemini-code-assist]

The current token masking logic can reveal the entire token for tokens with a length between 5 and 8 characters. For example, an 8-character token 12345678 would be displayed as 1234…5678, which is not masked at all. This could unintentionally expose sensitive information.

I recommend adjusting the logic to handle short tokens more securely.

fn mask_token(token: &str) -> String {
    let len = token.len();
    if len <= 4 {
        "*".repeat(len)
    } else if len <= 8 {
        format!("{}...", &token[..4])
    } else {
        format!("{}…{}", &token[..4], &token[len - 4..])
    }
}

[greptile-apps]

Greptile Summary

This PR adds three related features to mise's GitHub authentication system: a per-host github_tokens.toml config file, opt-in git credential fill integration, and a new mise github token [--unmask] [HOST] diagnostic command. The changes centralize previously scattered token resolution logic into a single resolve_token function with a clear 5-tier priority chain, which is a solid architectural improvement.

Key changes:

• New src/github.rs: resolve_token(host) centralizes the 5-tier priority lookup; is_gh_host updated to include github_tokens.toml; get_git_credential_token spawns git credential fill with caching
• New src/cli/github/{mod,token}.rs: mise github token command with token masking
• src/http.rs: simplified — removed inline gh_cli_tokens guard, now delegates to is_gh_host
• New settings.toml / schema/mise.json entries for github.use_git_credentials
• Docs, manpage, CLI completion files, and e2e tests all updated

Issues found:

• is_gh_host gap for GHE + git credentials (P1): is_gh_host in http.rs is the gate deciding whether get_headers is called for non-standard GitHub hosts. It checks MISE_GITHUB_TOKENS and GH_HOSTS but not git credentials. A GHE host with only git credentials (not in github_tokens.toml or gh_cli_hosts.yml) will never have auth headers attached, silently breaking the primary use-case of use_git_credentials for GHE.
• Blocking I/O under std::sync::Mutex in async context (P2): get_git_credential_token holds the cache mutex for the full subprocess duration and also has a race window where two threads can both spawn git credential fill for the same host before either inserts the result. This is opt-in and the TODO is acknowledged, but the mutex-across-spawn pattern is worth addressing.
• Misleading "failed to parse" debug log (P2): An empty github_tokens.toml logs "failed to parse" when it actually parsed successfully with no tokens.

Confidence Score: 4/5

• Safe to merge after addressing the is_gh_host gap for GHE + git credentials; all other changes are well-tested and non-breaking.
• The refactor is clean, the new features are opt-in, existing behavior is preserved, and test coverage is solid. One concrete bug (is_gh_host not accounting for use_git_credentials on GHE hosts) would silently break the primary GHE use-case of the new git credentials feature, but it doesn't affect existing users or github.com. The blocking-I/O and misleading-log issues are minor. Score reflects a PR that is nearly ready — one targeted fix remains before the advertised feature is fully correct.
• src/github.rs — specifically the is_gh_host function and get_git_credential_token mutex usage

Important Files Changed

Filename	Overview
src/github.rs	Core auth logic refactored into resolve_token with 5-tier priority. Two issues: is_gh_host omits the use_git_credentials path (breaking GHE auth via git credentials), and blocking subprocess I/O is held under a std::sync::Mutex in async context.
src/http.rs	Simplified: removed inline gh_cli_tokens guard; now delegates entirely to is_gh_host (which encapsulates the setting). Correct for github.com/api.github.com, but inherits the is_gh_host gap for GHE+git-credentials.
src/cli/github/token.rs	New mise github token command; clean implementation with masking logic. Token display and source attribution look correct.
src/cli/github/mod.rs	New CLI module wiring github subcommand; straightforward and correct.
e2e/cli/test_github_token	Comprehensive e2e test covering all 5 token sources, priority ordering, masking, and settings. Well-structured and isolated.
settings.toml	New github.use_git_credentials setting added correctly with env var, type, default, and documentation.
docs/dev-tools/github-tokens.md	Documentation updated to reflect new token sources and priority tables; clear and accurate.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[HTTP request] --> B{Standard GitHub host?\ngithub.com / api.github.com\n*.githubusercontent.com}
    B -- Yes --> D[resolve_token lookup_host]
    B -- No --> C{is_gh_host check:\nin github_tokens.toml\nor gh CLI hosts.yml?}
    C -- No --> Z[No auth headers - gap exists\nfor GHE with git credentials only]
    C -- Yes --> D

    D --> E{Enterprise token set\nand host is not github.com?}
    E -- Yes --> OUT[Return token + source]
    E -- No --> F{Standard env vars set?\nMISE_GITHUB_TOKEN etc.}
    F -- Yes --> OUT
    F -- No --> G{Host in\ngithub_tokens.toml?}
    G -- Yes --> OUT
    G -- No --> H{gh_cli_tokens enabled\nand host in hosts.yml?}
    H -- Yes --> OUT
    H -- No --> I{use_git_credentials\nenabled?}
    I -- Yes --> J[Spawn: git credential fill\ncached per host per session]
    J --> K{Password found?}
    K -- Yes --> OUT
    K -- No --> L[None - no auth]
    I -- No --> L

    OUT --> M[Attach Bearer token header]

    style Z fill:#f99,stroke:#c00
    style J fill:#ffe,stroke:#cc0

Loading

Comments Outside Diff (3)

1. src/github.rs, line 424-427 (link)

   is_gh_host silently breaks git credential fill for GHE hosts

   is_gh_host is used by http.rs as the gate that decides whether to call get_headers (and thus attach auth headers) for non-standard GitHub hosts. It currently checks only MISE_GITHUB_TOKENS and GH_HOSTS — the use_git_credentials path is not included:

   pub fn is_gh_host(host: &str) -> bool {
       MISE_GITHUB_TOKENS.contains_key(host)
           || (Settings::get().github.gh_cli_tokens && GH_HOSTS.contains_key(host))
       // git credential check is missing here
   }

   Consequence: a user with use_git_credentials = true and git credentials for a GHE host (e.g. github.mycompany.com) that is not already in github_tokens.toml or gh_cli_hosts.yml will get no auth headers at all — github_headers in http.rs never calls get_headers, so resolve_token (which would succeed) is never reached.

   This affects the primary advertised use-case of this feature: devcontainer / Windows / macOS environments where gh auth login --hostname github.mycompany.com stores the token in the system keyring rather than hosts.yml.

   For github.com this is fine (always matched by h == "api.github.com" || h == "github.com" || …), but GHE hosts rely entirely on is_gh_host to be included.

   A minimal fix would be to also trigger for use_git_credentials hosts when the credential is actually available, or at minimum add a documentation caveat that git credential fill only works for GHE hosts already registered via another source (e.g. github_tokens.toml with a placeholder).

2. src/github.rs, line 465-471 (link)

   Misleading "failed to parse" log for an empty or token-less file

   When parse_github_tokens returns None (e.g. the file exists but has no [tokens] section or is empty), the debug message printed is:

   failed to parse github_tokens.toml at …
   

   This is inaccurate: TOML parsing succeeded; there were simply no tokens. The misleading message could confuse users debugging their config. A clearer message would distinguish the two cases:

3. src/github.rs, line 549-589 (link)

   Blocking syscalls inside a std::sync::Mutex lock held across async context

   get_git_credential_token holds GIT_CREDENTIAL_CACHE (a std::sync::Mutex) for the entire duration of the git credential fill subprocess call, including wait_with_output(). This blocks the calling Tokio worker thread for the full subprocess duration — a worst-case of several seconds on slow systems or keyring prompts (even though GIT_TERMINAL_PROMPT=0 prevents interactive prompts, the helper itself may be slow).

   The TODO comment acknowledges this. Since this is opt-in (use_git_credentials defaults to false) the practical impact is limited, but it's worth noting that the mutex should be dropped before spawning the process and re-acquired only to write the result. That would at least avoid holding the lock across the I/O wait and allow concurrent requests to other hosts to proceed.

   // Drop lock before spawning:
   drop(cache);
   let result = // … spawn git credential fill …
   // Re-acquire to cache result:
   let mut cache = GIT_CREDENTIAL_CACHE.lock().expect("…");
   cache.entry(host.to_string()).or_insert(result.clone());
   result

   Note: the current code also doesn't handle the case where two threads race on the same host — both would spawn the subprocess before either inserts the result. The entry API or a "in-flight" marker could prevent the double-spawn.

_{Reviews (9): Last reviewed commit: "[autofix.ci] apply automated fixes" | Re-trigger Greptile}

[github-actions]

Hyperfine Performance

mise x -- echo

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.3.13 x -- echo	24.4 ± 0.7	23.6	31.2	1.00
mise x -- echo	25.3 ± 0.8	23.9	31.0	1.04 ± 0.04

mise env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.3.13 env	24.4 ± 0.8	23.1	30.0	1.00
mise env	24.7 ± 1.4	23.3	50.9	1.01 ± 0.07

mise hook-env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.3.13 hook-env	24.8 ± 0.4	23.8	26.7	1.00
mise hook-env	25.3 ± 0.7	24.1	29.8	1.02 ± 0.03

mise ls

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.3.13 ls	24.8 ± 1.1	23.5	39.5	1.00
mise ls	25.2 ± 0.6	23.7	27.2	1.01 ± 0.05

xtasks/test/perf

Command	mise-2026.3.13	mise	Variance
install (cached)	164ms	161ms	+1%
ls (cached)	85ms	85ms	+0%
bin-paths (cached)	89ms	88ms	+1%
task-ls (cached)	856ms	835ms	+2%

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}