[Bug]: VTCode install on Windows starts with broken native installer before Cargo fallback

[Drswith]

What went wrong?

qtx install vtcode on Windows first runs the upstream VTCode PowerShell installer. The installer currently fails before Quantex's Cargo fallback can complete, producing confusing failure output and then continuing into cargo install vtcode.

Based on the captured logs and current upstream release metadata, there are two separate failure modes:

1. The upstream Windows installer constructs this asset URL for latest version 0.105.7:
   https://github.com/vinhnx/vtcode/releases/download/0.105.7/vtcode-0.105.7-x86_64-pc-windows-msvc.zip

   GitHub returns Not Found. The latest release assets currently include macOS/Linux tarballs and scripts/checksums, but no Windows x86_64-pc-windows-msvc.zip asset.

2. Retrying hits the GitHub unauthenticated API rate limit inside the upstream installer:
   API rate limit exceeded for 18.162.60.238

   Setting HTTP_PROXY / HTTPS_PROXY did not avoid the observed rate limit, presumably because the installer still reached GitHub from the same public egress IP or without authenticated API headers.

Quantex then falls through to the second Windows install method, cargo install vtcode. That is visible from the subsequent Cargo output. The command was then interrupted with SIGINT, so Quantex ended with Failed to install VTCode.

Reproduction steps

1. On Windows with Quantex CLI 0.17.0, run qtx install vtcode.
2. Let the native PowerShell installer run first.
3. Observe either the missing Windows release asset (Not Found) or GitHub API rate-limit failure.
4. Observe Quantex continue into the Cargo fallback.
5. Interrupt the long Cargo build with Ctrl+C.

Expected behavior

Quantex should avoid presenting the broken upstream native installer as the preferred Windows path when it is known to fail, or should make fallback behavior explicit enough that the user can tell the first failure is non-terminal.

Possible fixes to consider:

• Prefer managed/cargo before unmanaged/script for VTCode on Windows while upstream does not publish a Windows release asset.
• Keep the script method but add clearer fallback/progress messaging when an install method fails and Quantex is trying the next method.
• If Quantex wants to keep native installer first, document that the current upstream Windows installer depends on unauthenticated GitHub API and a Windows asset that is currently absent.

Actual behavior

Captured session excerpt:

PS C:\Users\drs> qtx install vtcode
INFO: Creating installation directory: C:\Users\drs\.local\bin
VT Code Native Installer (Windows)

INFO: Fetching latest VT Code release from GitHub...
INFO: Latest version: 0.105.7
INFO: Downloading binary from GitHub...
INFO: URL: https://github.com/vinhnx/vtcode/releases/download/0.105.7/vtcode-0.105.7-x86_64-pc-windows-msvc.zip
- Failed to download binary
- Error: Not Found
    Updating crates.io index
Command cancelled by SIGINT.                   ] 1 complete; 1 pending
PS C:\Users\drs> Failed to install VTCode.

Second attempt:

PS C:\Users\drs> qtx install vtcode
VT Code Native Installer (Windows)

INFO: Fetching latest VT Code release from GitHub...
- Failed to fetch release info from GitHub API
- Error: {"message":"API rate limit exceeded for 18.162.60.238. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}

    Updating crates.io index
Command cancelled by SIGINT.                   ] 1 complete; 1 pending
Failed to install VTCode.

Third attempt after setting proxy still hit the same API limit first, then Cargo fallback continued:

PS C:\Users\drs> $env:HTTP_PROXY="http://127.0.0.1:7897"; $env:HTTPS_PROXY="http://127.0.0.1:7897"
PS C:\Users\drs> qtx install vtcode
VT Code Native Installer (Windows)

INFO: Fetching latest VT Code release from GitHub...
- Failed to fetch release info from GitHub API
- Error: {"message":"API rate limit exceeded for 18.162.60.238. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}

    Updating crates.io index
  Downloaded vtcode v0.105.7
  Downloaded 1 crate (1.3MiB) in 1.26s
  Installing vtcode v0.105.7
    Updating crates.io index
     Locking 738 packages to latest compatible versions
      Adding agent-client-protocol v0.10.4 (available: v0.11.1)
      Adding agent-client-protocol-schema v0.11.4 (available: v0.11.7)

Diagnostics collected

• Platform: Windows x64
• Quantex CLI: 0.17.0
• qtx inspect vtcode --json reports Windows install methods in this order:

[
  {
    "command": "irm https://raw.githubusercontent.com/vinhnx/vtcode/main/scripts/install.ps1 | iex",
    "label": "unmanaged/script",
    "type": "script"
  },
  {
    "command": "cargo install vtcode",
    "label": "managed/cargo",
    "type": "cargo"
  }
]

• qtx capabilities --json reports cargo.available: true on this machine.
• Checked current upstream latest release through authenticated GitHub CLI: vinhnx/vtcode latest tag is 0.105.7; assets include install.ps1, install.sh, checksums, macOS tarballs, and Linux tarballs, but no Windows zip asset.
• Current upstream scripts/install.ps1 hard-codes Windows platform x86_64-pc-windows-msvc and filename vtcode-$ReleaseTag-$Platform.zip.
• Checked docs/runbooks/quantex-troubleshooting.md before filing.

Linked artifacts

• src/agents/definitions/vtcode.ts
• openspec/specs/agent-catalog/spec.md
• docs/runbooks/quantex-troubleshooting.md
• Archived change that introduced VTCode support: openspec/changes/archive/2026-05-10-add-vtcode-support/

Checklist

• I checked the canonical troubleshooting runbook first.
• I included enough detail for an agent to reproduce or continue debugging.