fix(backend): resolve remote versions with each request's own options

[JamBalaya56562]

When a tool lists several versions, each entry is meant to resolve with its own options. An option that only the first entry sets leaked into the later ones:

[tools]
"github:zed-industries/zed" = [
  { version = "latest", prerelease = true },
  { version = "1", bin = "zed" },
]

The second entry does not ask for prereleases, but 1 resolved to 1.25.0-pre. Written on its own, the same entry resolves to 1.24.2. A bare string entry such as "1" after the first one was affected the same way.

Version resolution looked up options through the config, which takes the first entry's options for the whole tool and layers the request's own options over them. Any key the request leaves unset came from the first entry. Resolution now passes each request's own options when it lists matching remote versions, for prefix requests, exact pins and the date-filter fallback, and when it answers them from the mise-versions index. The latest lookup already did so.

This takes over the core of #11720 by @risu729, which pr-closer closed after 7 days without contributor activity. They are credited as co-author. #11720 also reworked mise latest, mise upgrade and the backend's option wrappers. Those parts are left out, and so are the lookups that have no request to take options from (sub-N: bases and the date-filter error message), which still use the config.

Validation

• New e2e/backend/test_github_multi_entry_options, against a local stand-in for the GitHub API that serves v1.0.0 and a prerelease v1.1.0-pre:
  • Alone, 1 resolves to 1.0.0.
  • After { version = "latest", prerelease = true }, 1 still resolves to 1.0.0, and latest to 1.1.0-pre.
• In a Linux rust:1 container, the test fails with the released 2026.10.10 (expected '1.0.0' in the multi-entry case, where only 1.1.0-pre is listed) and passes with this branch. test_github_ls_remote_skips_assetless and test_github_ls_remote_inline_opts also pass.
• cargo clippy --workspace --all-features --all-targets -- -D warnings passes.
• With mise 2026.10.8 on Windows, MISE_TRACE=1 mise ls showed the zed case above resolving the second entry to 1.25.0-pre, and the entry alone to 1.24.2. A bare "1" after the first entry also resolved to 1.25.0-pre.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5-5; version: unavailable.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Version resolution now uses the effective settings for each request when checking exact versions, resolving remote versions, looking up indexed versions, and matching version prefixes.
  • Stable versions resolve correctly when another entry allows prereleases, while that entry can still resolve to the latest prerelease.
  • When resolving multiple entries together, each result reflects the options configured for its own request, rather than being affected by another entry’s settings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)
• Review profile: CHILL
• Plan: Advanced
• Run ID: 6d7ef4e0-2af3-4a45-a9a2-5468549a2e1f

📥 Commits

Reviewing files that changed from the base of the PR and between 1ec808a and fe9b56e.

📒 Files selected for processing: 1

• src/toolset/tool_version.rs

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📝 Walkthrough

Version resolution now passes each request’s selection options to backend version-listing calls. An end-to-end test checks stable and prerelease resolution for single and multiple entries.

Changes: Version resolution

Layer / File(s)	Summary
Propagate selection options through version resolution src/toolset/tool_version.rs, e2e/backend/test_github_multi_entry_options	Exact-version checks, remote resolution with and without a date cutoff, and prefix matching use the request’s selection options. The end-to-end test checks stable and prerelease results across entries.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: jdx, risu729

Merge Risk: ⚪ Minimal · up to fe9b5

No actionable merge-blocking issue is established; merge after normal checks.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly summarizes the main change: remote version lookups use each request’s own options.

• Fix all pre-merge checks with AI

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no blocking issues were found.

Summary

Remote version matching now uses each request’s own options instead of inheriting unset options from the first configured entry.

• Each tool entry resolves remote versions with its own options.

_{Reviews (3) · Last reviewed commit: "fix(backend): resolve remote versions wi..." · Reviewed by Greptile}

[JamBalaya56562]

@jdx Thanks for enabling auto-merge on this!

untrusted / unit-macos fails here for a reason unrelated to this PR: the test binary no longer links on the GitHub-hosted macos-14 runner.

ld: B/BL out of range 134930212 (max +/-128MB) from ... ctor13priority_ctor ... (bin "mise" test)

The binary's __text is now about 133 MB. The ctor priority constructor lives in __text_startup after it, so its branch into __text is past the ±128 MB arm64 range. Trusted runs on the Namespace macOS runner still link (for example main at 0ff2519a), so this only shows up on untrusted runs.

Other untrusted PRs hit the same error since about 01:40 UTC today: #14487, #14483 and #14454. This PR's last three runs failed the same way. Earlier untrusted runs, such as #14426 at 01:21, still linked.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5-5; version: unavailable.