403 "GitHub repo is not in the mise registry" from mise-versions for non-shortname tools

[scop]

Seems since some days (maybe a week) or so ago, anyway recently, mise-versions has started erroring out with 403 "GitHub repo is not in the mise registry" in mise up for tools that are not in the mise registry by their short name, but installed as fully qualified like aqua:owner/repo

For example,

mise WARN  mise-versions endpoint=github_release repo=go-semantic-release/semantic-release tag=latest outcome=failed status=403 fallback=true error="HTTP status client error (403 Forbidden) for url (https://mise-versions.jdx.dev/api/github/repos/go-semantic-release/semantic-release/releases/latest)"

This is not the best UX BTW because mise output only shows the 403, and not the error message (which is in the response body).

$ curl https://mise-versions.jdx.dev/api/github/repos/go-semantic-release/semantic-release/releases/latest
GitHub repo is not in the mise registry

Also, 404 would sound like a better status code for this than 403.

[chadlwilson]

There is no call to action here at all, either - nor a description of the consequences and whether it is preventing updates. Given the intent of using aqua's backend is to avoid having to have every tool in mise's own registry, the error message doesn't make any sense in context.

It doesn't seem to be happening for every such tool, as I noted at #10339 (didn't see this issue earlier).

[chadlwilson]

Probably due to #10127

[jdx]

I opened #10341 for the remaining pieces here.

The version detail matters: the GitHub backend had already been changed to skip mise-versions for non-registry tools, but #10339 showed the warning was still reproducible on 2026.6.2 through Aqua's separate GitHub release lookup path. That path was still using the unguarded release helper, so Aqua could ask mise-versions about repos that only exist in the Aqua registry.

The PR does two things:

• makes Aqua GitHub release metadata lookups skip mise-versions and go directly to GitHub
• includes a capped response body in mise-versions fallback warnings, so messages like GitHub repo is not in the mise registry are visible instead of being reduced to a bare 403 Forbidden

This comment was generated by an AI coding assistant.

[jdx]

Correction on the PR direction: the fix should not remove mise-versions from Aqua globally. Registry-backed Aqua tools still need the shared host to avoid unauthenticated GitHub rate limits.

I amended #10341 so Aqua release metadata is now registry-aware:

• shorthand/mise-registry Aqua backends still use mise-versions
• fully qualified non-registry Aqua backends skip mise-versions, since the client can tell locally that the service will reject them as not in the mise registry
• warnings from actual mise-versions failures remain visible, now with a capped response body

This comment was generated by an AI coding assistant.

[chadlwilson]

Thanks @jdx / AI coding assistant.

But I'm still not sure why aqua:aws/session-manager-plugin gives such warnings, yet aqua:getgauge/gauge does not. Is it because the former's binaries are outside GitHub (type: http), but the latter uses Github release artifacts/assets (type: github_release)? Both are qualified, neither are in the mise registry, but only the former gives a warning/403.

https://github.com/aquaproj/aqua-registry/blob/67b6483daa337d6b0300ad86da686d7cc3110b25/pkgs/aws/session-manager-plugin/registry.yaml

vs

https://github.com/aquaproj/aqua-registry/blob/67b6483daa337d6b0300ad86da686d7cc3110b25/pkgs/getgauge/gauge/registry.yaml

[scop]

This still happens for some tools, at least for snyk installed via the shortname, no fully qualified aqua.

mise WARN  mise-versions endpoint=github_release repo=snyk/cli tag=latest outcome=failed status=403 fallback=true error="HTTP status client error (403 Forbidden): GitHub repo is not in the mise registry"

$ mise tool snyk
Backend:            aqua:snyk/cli                                                         
Description:        Snyk CLI scans and monitors your projects for security vulnerabilities
Installed Versions: 1.1305.1                                                              
Active Version:     1.1305.1                                                              
Requested Version:  latest                                                                
Config Source:      ~/.config/mise/config.toml                                            
Tool Options:       [none]                                                                
Security:           checksum (sha256)                                                     

mise 2026.6.14

[chinkung]

I found same WARN from TomWright/dasel

mise WARN  mise-versions endpoint=github_release repo=TomWright/dasel tag=latest outcome=failed status=403 fallback=true error="HTTP status client error (403 Forbidden): GitHub repo is not in the mise registry"

$ mise tool dasel
Backend:            aqua:TomWright/dasel
Description:        Select, put and delete data from JSON, TOML, YAML, XML and CSV files with a single tool. Supports conversion b
                    etween formats and can be used as a Go package
Installed Versions: 3.11.1
Active Version:     3.11.1
Requested Version:  latest
Config Source:      ~/projects/personal/dotfiles/home/.config/mise/config.toml
Tool Options:       [none]
Security:           [none]

[chinkung]

Set this in global mise config fix the issue

[settings]
use_versions_host = false

[chadlwilson]

That’s a workaround, not a fix, because it disables it globally and is not equivalent.

That impacts all tools, including those which can more quickly and efficiently come from the mise versions proxy, so recreates the need to have a GITHUB_TOKEN which the proxy is intended to resolve/mitigate (for known tools).

https://mise.jdx.dev/configuration/settings.html#use_versions_host

[jdx]

Thanks for the follow-up reports. The remaining shortname cases should now be fixed.

What changed:

• fix(sync): include registry-only tools in metadata sync mise-versions#246 includes registry-only tools in the metadata sync
• fix(update): unskip stable version sync tools mise-versions#247 removed the audited stable tools from the hard skip list
• the next update run generated TOML data for the affected tools in jdx/mise-versions@ed175e8

That generated docs/snyk.toml and docs/dasel.toml, along with the other previously skipped tools. The D1 versions sync completed successfully and the follow-up deploy also succeeded.

I also checked the reported release endpoints directly:

• snyk/cli now returns 200
• TomWright/dasel now returns 200

So the use_versions_host = false workaround should no longer be needed for these shortname tools.

If anyone still sees a 403, please update mise to the latest version first, then share the exact warning plus mise tool <name> output.

The earlier fully-qualified non-registry Aqua case was handled separately in #10341.

This comment was generated by an AI coding assistant.

[risu729]

@chadlwilson I'm a human here; I added the warning: mise WARN semver ranges are not supported, but I have no idea why a path is treated as a version string.
I need more logs to investigate, at least mise doctor.

Also, ~-Projects-community-gocd-tmp-mise.toml seems like a path, so mise might have created it before from a wrong config, or due to a bug. AI agent suggested this command to find the problematic install path.

find "${MISE_DATA_DIR:-$HOME/.local/share/mise}/installs" \
  -name '~-Projects-community-gocd-tmp-mise.toml' \
  -exec ls -ld {} \;

If you find any, that's the cause. You should delete that directory. If it happens again, I guess it's a mise bug creating such a weird directory, but I didn't find any bugs for now.

Also, the responses are not automated. I (and jdx, I believe) generate comments using AI, but there's no automated system for resolving bugs.

[jdx]

@chadlwilson I have never once used automation to respond to issues on any project. I use it to author the content only.

I receive over 50 github notifications on a slow day, some days several hundred. I am doing the best I can.

[jdx]

@chadlwilson Following up on my earlier reply with the technical details after investigating these reports.

Maintaining mise is my full-time job, and GitHub authentication and API rate limits have been among the largest and most persistent problems I’ve worked on. The entire purpose of the recent mise-versions work is to reduce users’ dependence on GITHUB_TOKEN, especially in CI and containers where GitHub’s anonymous API limit makes otherwise normal installs unreliable.

This has required coordinated work across both repositories:

Building the shared GitHub metadata service

• mise-versions#201: added mirrored GitHub release and attestation metadata using the shared token pool
• mise-versions#202: added CDN caching and prevented error responses from being cached
• mise#10127: made mise use the mirror before calling GitHub directly, specifically to reduce rate-limit and token failures
• mise-versions#224: added negative caching for upstream release failures
• mise-versions#226: prevented stale cached releases from surviving an upstream 404
• mise-versions#256: added another edge-cache layer to reduce D1 and shared-token pressure

Restricting the service safely and fixing routing

• mise-versions#225: restricted the shared mirror to repositories associated with the mise registry
• mise#10240: fixed valid responses rejected because of canonical GitHub repository casing
• mise#10255: made non-registry GitHub tools bypass the shared service
• mise#10260: applied the same routing rules to attestations
• mise#10341: fixed Aqua routing so registry-backed tools retain the mirror benefit while Aqua-only repositories go directly to GitHub

Improving diagnostics and the reported UX

• mise#10254: made non-404 metadata fallback visible instead of silently falling through
• mise#10256: added structured endpoint, repository, tag/digest, outcome, status, and fallback fields
• mise#10341: included the capped response body so a bare 403 now explains the service policy that caused it

Fixing registry coverage and indirect repositories

• mise-versions#228: added the indirect Python attestation repository
• mise-versions#245: added indirect Erlang release repositories
• mise-versions#246: ensured registry-only tools are included in service metadata even without generated version files
• mise-versions#247: restored metadata generation for snyk, dasel, and other stable tools
• mise-versions#271: added the indirect Windows RubyInstaller release repository
• mise-versions#272: added the indirect precompiled Ruby attestation repository

The two Ruby warnings above had the same root cause. The registry identifies the tool as core:ruby, but Ruby uses additional GitHub repositories that cannot be inferred from that entry:

• Windows releases come from oneclick/rubyinstaller2
• precompiled Ruby attestations come from jdx/ruby

Cross-platform lock generation explains why the Windows RubyInstaller lookup occurred on macOS. Both exceptions have now landed, and I verified that the exact release and attestation endpoints reported here return 200.

The 403 was not a GitHub rate-limit response. It came from mise-versions, which understood the request but refused to proxy a repository absent from its allowlist. That restriction is necessary so the shared token pool does not become an unrestricted public GitHub proxy. A local GITHUB_TOKEN applies when mise contacts GitHub directly; it cannot change the shared service’s allowlist decision.

I do not view these as broad installation regressions. They are edge cases uncovered while getting to the bottom of a difficult problem involving registry identity, indirect repositories, Aqua metadata, attestations, caching, cross-platform locks, and direct GitHub fallback. The warnings made the mismatches visible, and the work above addresses them.

The semver warning is unrelated. The value resembles a filesystem path after mise’s install-directory sanitization replaced / with -. At that point mise only sees an on-disk directory and cannot determine whether it originally came from an environment variable, configuration value, command argument, or older bug. The diagnostic steps already posted above should identify the affected tool; if the directory returns after removal, we would need the configuration or reproduction that recreated it.

This comment was drafted with assistance from an AI coding assistant.

[chadlwilson]

@chadlwilson I have never once used automation to respond to issues on any project. I use it to author the content only.

I receive over 50 github notifications on a slow day, some days several hundred. I am doing the best I can.

I appreciate that it's tough, and certainly don't expect everything (or even anything) to be replied to. But whether the content is entirely generated by AI or automated in deciding what to respond to is somewhat a "distinction without a difference" from my PoV - if the response feels impersonal, mechanical or "imperial" as LLM responses tend to be.

The level of "LLM" and rate-of-change in this project is extremely high. Maybe I've been unlucky and this is probably confirmation bias, but my concern is that DX/UX is going backwards; notably in ways LLMs tend to totally ignore and are unable to adequately verify, because they are not humans - and with sub-optimal feedback loops that might be a risk to the project. It's not just that mise is technically great that is the reason I use mise (and have contributed a little bit), it's that it was intuitive to use, debug and generally "just works".

I merely intend to highlight that it may not be your intention, but this isn't the interactions some folks look to within OSS - especially when there aren't structured ways the project provides to find known issues; "won't fixes" etc. While intending to get control of the "noise" from such a large user bases, an unintentional side-effect may have been a loss of humanity in the rest.

@chadlwilson Following up on my earlier reply with the technical details after investigating these reports.

Maintaining mise is my full-time job, and GitHub authentication and API rate limits have been among the largest and most persistent problems I’ve worked on. The entire purpose of the recent mise-versions work is to reduce users’ dependence on GITHUB_TOKEN, especially in CI and containers where GitHub’s anonymous API limit makes otherwise normal installs unreliable.

Yup, understand the goal, and it is a worthy one. Just wish I wasn't seeing so many rough edges after mise upgrades in recent months, as I feel I've spent more time fighting the tool than should be necessary.

The two Ruby warnings above had the same root cause. The registry identifies the tool as core:ruby, but Ruby uses additional GitHub repositories that cannot be inferred from that entry:

* Windows releases come from `oneclick/rubyinstaller2`

* precompiled Ruby attestations come from `jdx/ruby`

Cross-platform lock generation explains why the Windows RubyInstaller lookup occurred on macOS. Both exceptions have now landed, and I verified that the exact release and attestation endpoints reported here return 200.

What does "Both exceptions have now landed" mean? Patches/fixes for the exceptional cases are released? Probably odd LLM grammar, but not sure what it means.

The 403 was not a GitHub rate-limit response. It came from mise-versions, which understood the request but refused to proxy a repository absent from its allowlist. That restriction is necessary so the shared token pool does not become an unrestricted public GitHub proxy. A local GITHUB_TOKEN applies when mise contacts GitHub directly; it cannot change the shared service’s allowlist decision.

OK, yes, but this is the same messy UX as noted in the original message to this discussion from June. The user is warned of something by displaying an HTTP error relating to internal machinery (mise-versions) which should be largely opaque to them, and which appears to have no explanation or call to action. Why warn a user if they can do nothing about it? Am I supposed to do something about it?

Fixing the root causes is of course valuable, but since these errors keep coming back due to the complexity, perhaps some work could go into avoiding conveying misleading messages with no ability to be understood by a human user, and no call to action (or call to no-action).

I do not view these as broad installation regressions. They are edge cases uncovered while getting to the bottom of a difficult problem involving registry identity, indirect repositories, Aqua metadata, attestations, caching, cross-platform locks, and direct GitHub fallback. The warnings made the mismatches visible, and the work above addresses them.

OK, your call, but I generally prefer warnings from my software to be understandable and actionable by users rather than nothing of their making, especially when there are no GitHub issues to track for a given issue and work is spread across many PRs, discussions etc.

If they are visible warnings because the project wants people to report them so you can address the "mismatches" - perhaps consider providing an appropriate statement of what the warning actually means to a user, and call to action e.g GitHub repo is not in the mise registry. <whatThisMeansForUser>. <callToAction>

• whatThisMeansForUser - Does it mean my tool couldn't be checked for updates or is stale? Does it mean nothing as the fallback was successful? How is it related to the command that I ran? Should I expect it to fix itself automatically after some time? Should I ignore it unless I was trying to do XYZ?
• callToAction e.g "This is possibly/likely a bug, please report at ...." or "try again later" or "You can ignore this if XYZ" What does the software want me to do with this warning?

The semver warning is unrelated. The value resembles a filesystem path after mise’s install-directory sanitization replaced / with -. At that point mise only sees an on-disk directory and cannot determine whether it originally came from an environment variable, configuration value, command argument, or older bug. The diagnostic steps already posted above should identify the affected tool; if the directory returns after removal, we would need the configuration or reproduction that recreated it.

Ack, noted that it's unrelated (just that was not obvious to me from the message).

$ find "${MISE_DATA_DIR:-$HOME/.local/share/mise}/installs" \
>   -name '~-Projects-community-gocd-tmp-mise.toml' \
>   -exec ls -ld {} \;
drwxr-xr-x@ 2 chad  staff  64 Mar 14 01:24 /Users/chad/.local/share/mise/installs/groovy/~-Projects-community-gocd-tmp-mise.toml

$ ls -al /Users/chad/.local/share/mise/installs/groovy/
total 0
drwxr-xr-x@  9 chad  staff   288 Apr 25 01:02 .
drwxr-xr-x  63 chad  staff  2016 Jun  2 12:04 ..
drwxr-xr-x@  2 chad  staff    64 Mar 14 01:24 ~-Projects-community-gocd-tmp-mise.toml
lrwxr-xr-x@  1 chad  staff    41 Apr 25 01:02 0 -> ./~-Projects-community-gocd-tmp-mise.toml
lrwxr-xr-x@  1 chad  staff    41 Apr 25 01:02 0.0 -> ./~-Projects-community-gocd-tmp-mise.toml
lrwxr-xr-x@  1 chad  staff     8 Apr 25 01:02 3 -> ./3.0.25
lrwxr-xr-x@  1 chad  staff     8 Apr 25 01:02 3.0 -> ./3.0.25
drwxr-xr-x@ 10 chad  staff   320 Mar 14 01:31 3.0.25
lrwxr-xr-x@  1 chad  staff     8 Apr 25 01:02 latest -> ./3.0.25

No idea how this got here, but perhaps another bug previously fixed it. I was last playing around with Groovy installs in April/May, but I don't know how the 0 and 0.0 entries got there. Possibly some latest detection problems with the asdf:groovy plugin?. Maybe #9143 or #9276 or #9383.

$ cat ~/Projects/community/gocd/tmp/mise.toml

[tools]
"groovy" = "3"
"aws-cli" = { version = "latest", symlink_bins = "true" }

From a UX/DX perspective it's worth noting that the warning did not display any relevant context - mise WARN semver ranges are not supported: ~-Projects-community-gocd-tmp-mise.toml, e.g. that it appears it was doing something with the groovy tool at the time even though I am explicitly running mise tool ruby (groovy was not an activated tool in the context I was running it, or in my global config). If it is necessary to warn the user about some issue with one particular tool (or ones overall mise installation) when running an unrelated command, it would be better if necessary context could be supplied, e.g mise WARN semver ranges are not supported when processing 'groovy' tool installations: ~-Projects-community-gocd-tmp-mise.toml - <whatThisMeansForUser> <callToAction> (or similar)

FWIW MISE_VERBOSE didn't help:

$ MISE_VERBOSE=1 mise tool ruby
DEBUG Version: 2026.7.7 macos-arm64 (2026-07-15)
DEBUG ARGS: /opt/homebrew/bin/mise tool ruby
DEBUG [vfox] Getting metadata for ant
DEBUG [vfox] Getting metadata for chromedriver
DEBUG [vfox] Getting metadata for vfox-mise-plugins-vfox-chromedriver
DEBUG [vfox] Getting metadata for vfox-mise-plugins-vfox-chromedriver
DEBUG [vfox] Getting metadata for yarn
DEBUG config: ~/.config/mise/config.toml
WARN  semver ranges are not supported: ~-Projects-community-gocd-tmp-mise.toml
Backend:            core:ruby
Installed Versions: jruby-9.2.21.0 jruby-9.3.15.0 jruby-9.4.13.0 jruby-9.4.14.0 jruby-9.4.15.0 jruby-10.0.5.0 jruby-10.0.6.0 jruby-10.1.0.0 2.7.8 3.1.7 3.2.9 3.3.11 3.4.8 4.0.6
Active Version:     4.0.6
Requested Version:  4.0
Config Source:      ~/.config/mise/config.toml
Tool Options:       [none]
Security:           checksum (sha256), github_attestations

Anyway, thanks, I've removed the directory and bad 0/0.0 version symlinks now, and will see if it happens again (probably not).

[risu729]

What does "Both exceptions have now landed" mean? Patches/fixes for the exceptional cases are released? Probably odd LLM grammar, but not sure what it means.

They're fixed on the mise-versions side. jdx/mise-versions#272 and jdx/mise-versions#272

If it is necessary to warn the user about some issue with one particular tool (or ones overall mise installation) when running an unrelated command, it would be better if necessary context could be supplied, e.g mise WARN semver ranges are not supported when processing 'groovy' tool installations: ~-Projects-community-gocd-tmp-mise.toml - (or similar)

I didn't think about it well because I didn't expect users to hit the warnings. The main reason I added it is that I found some users are using semver ranges in the version, which is not supported but sometimes works fine (for npm backends or such).
I made a PR to improve it: #11176