^{Originally posted by JFenstermacher July 6, 2025}
I think the way GitHub token configurations are handled is incorrect. If I'm missing context, feel free to correct.

Expected Behavior

When MISE_GITHUB_TOKEN is set, I would expect that mise would use the GitHub Token specified to download tools using it to prevent rate-limiting. It would only be used during tool installation, and not impact other behaviors.

Actual Behavior

When mise runs, it tries to detect a valid GitHub Token configuration by checking the MISE_GITHUB_TOKEN, GITHUB_TOKEN, and GITHUB_API_TOKEN variables. If any are found, it then sets the all of the environment variables to the one found.

Downstream Consequences

When mise runs in CI it relies on the shims by default, this means that every tool call is setting the MISE_GITHUB_TOKEN to GITHUB_TOKEN, and this leads to unintuitive behavior.

Example Unexpected Behavior

Context

My day job has a GitHub token setup that allows tokens with different permissions to be requested based on OIDC JWT claims of a workflow. This allows us to have a terraform setup where plans can run with readonly permissions, and applies can run with mutation permissions based on an environment that has an approval.

We rely on the GITHUB_TOKEN configuration to be able to grant the permissions for the GitHub terraform provider. We must rely on the GITHUB_TOKEN environment variable, because if you pass the token into the plan explicitly (via a variable), then the plan will save that token in the state. Applies are always based on a written plan for us in CI, as to ensure we can inspect the plan prior to approval (this is best practice, and non-negotiable).

Additionally, we have an internal ASDF plugin I maintain. In order for mise to resolve our internal ASDF plugin I must provide mise a GITHUB_TOKEN with cross-repository read.

The problem

I would expect that when I set MISE_GITHUB_TOKEN, then mise would use that token to handle installations. I set that env variable to our cross-repo read token.

Unexpectedly, in a later step terraform applies are failing when provided a GITHUB_TOKEN environment configuration that would allow for writing, because mise is overwriting GITHUB_TOKEN with the MISE_GITHUB_TOKEN which is the cross-repo read token.

Shortest example

This would be the minimal example that would show off what I'm talking about:

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - name: checkout
         uses: actions/checkout@v4
      - name: set readonly
         run: echo "MISE_GITHUB_TOKEN=${{ secrets.READONLY_PAT }}" >> $GITHUB_ENV
      - uses: jdx/mise-action@v2
         with:
           install_args: terraform
      - run: terraform init
      # Assuming the terraform is using the GitHub provider, and makes a call to `github_repository_file` resource
      # This would fail, because `MISE_GITHUB_TOKEN` set prior takes precedence
      # I would not expect a shim to pollute the tool run environment with it's own configurations
      - run: terraform apply 
         env:
           GITHUB_TOKEN: ${{ github.token }}

Conclusion

I believe that the MISE_GITHUB_TOKEN configuration should be explicitly set prior to tool installation calls, and not set at the beginning of mise. Shim calls should not pollute the runtime environment.

I think mise is a fantastic tool, and it's use is expanding in the company I work for in no small part due to me pushing it, but this behavior is requiring me to create workarounds I'd rather not have to.

If you think this makes sense, and is possible, I'm up for doing the work to address it. I'd appreciate some general guidance in what parts of the codebase will need to change.