Installer and self-update ignore token env vars for GitHub release lookup

[ErrevsSungam]

Summary

I cannot reliably install or update APM while connected through my company VPN, because APM does the GitHub releases/latest lookup anonymously even when I provide GITHUB_TOKEN or GITHUB_APM_PAT.

That means APM can fail on GitHub's shared anonymous/IP-based quota even though gh auth status is healthy and my authenticated GitHub API quota is not exhausted.

Observed with APM CLI 0.14.0.

Symptom

With the anonymous GitHub API quota exhausted:

export GITHUB_TOKEN="$(gh auth token)"
curl -sSL https://aka.ms/apm-unix | sh

can fail with:

Error: Invalid API response received
GitHub API Error:
API rate limit exceeded for .

The authenticated quota can still be healthy at the same time:

gh api rate_limit --jq '.resources.core'

What seems to be happening

In install.sh, the token env vars are resolved before release lookup, but APM still makes the first releases/latest request without auth:

• install.sh resolves GITHUB_APM_PAT / GITHUB_TOKEN into AUTH_HEADER_VALUE.
• The first https://api.github.com/repos/$APM_REPO/releases/latest call is made without that header.
• The script only retries with auth for curl failure, empty response, or "Not Found".
• A GitHub rate-limit response is valid JSON but has no tag_name, so the installer exits as Invalid API response received.

apm self-update appears to have the same issue one step earlier: it calls get_latest_version_from_github() before running the installer, and that helper also requests releases/latest without auth headers.

Expected behavior

If GITHUB_APM_PAT or GITHUB_TOKEN is set, APM should not start with an anonymous release lookup. It should either:

• use it for the first releases/latest request, or
• retry with auth when GitHub returns an anonymous rate-limit response.

Workaround

Pin the version using authenticated gh, which lets the installer skip releases/latest:

VERSION="$(gh api repos/microsoft/apm/releases/latest --jq .tag_name)"
curl -sSL https://aka.ms/apm-unix | VERSION="$VERSION" GITHUB_TOKEN="$(gh auth token)" sh

Related context

I searched existing issues/PRs and did not find this exact case already tracked.

Related but distinct:

• feat: make install.sh configurable for air-gapped environments #660 added VERSION pinning, which is the current workaround.
• feat: CDN-first download for unauthenticated github.com virtual files #322 handled unauthenticated GitHub API limits for dependency file downloads, but not installer release metadata.
• Multi-host dependency support: lockfile identity, token resolution consistency, error clarity #773 mentions GitHub API rate-limit wording in dependency download/error paths, but not the installer or self-update path.

Small repro note

This form does not pass the token to the installer process:

GITHUB_TOKEN="$(gh auth token)" curl -sSL https://aka.ms/apm-unix | sh

The env assignment only applies to curl, not the sh process. The repro above uses export so the installer receives the token.

[svemageng]

This issue was discovered during an APM package upgrade I was performing for the team. I cloned the APM repo, used my findings with Copilot to find the bug.

[github-actions]

Triage Panel Verdict

Thank you for the thorough write-up, @ErrevsSungam. The root cause is well-identified and the workaround is clearly documented.

Summary

When GITHUB_APM_PAT or GITHUB_TOKEN is set, both install.sh and apm self-update still issue the first releases/latest API call anonymously. If the anonymous quota is exhausted (common on shared IPs, corporate VPNs, or CI runners), this results in an opaque error even though a valid token is available. The token is resolved early in the script but not forwarded to the release-metadata fetch.

---

Panel findings

DevX UX Expert
The user expectation is simple: if I provided a token, use it. The current behavior -- silently falling back to anonymous for the release lookup while claiming to honor the token -- is deeply confusing, and the resulting error message ("Invalid API response received") gives no indication that auth is involved. The workaround is documented in the issue but should not be necessary.

Supply Chain Security Expert
Making an unauthenticated request for release metadata when a token is available means the release lookup is subject to anonymous rate limiting and, in theory, more susceptible to response manipulation on shared network paths. The fix (always include the auth header when the token is present) closes both the reliability and the integrity gap. There is no credential-leakage risk since the token is already in the environment.

Auth expert view (panel):
This is a classic auth-plumbing bug: the token is resolved at the top of the script but the first downstream call ignores it. The fix in install.sh is to pass AUTH_HEADER_VALUE (or an equivalent -H "Authorization: Bearer $TOKEN" flag) to the releases/latest curl call unconditionally when the value is non-empty. apm self-update needs the same treatment in get_latest_version_from_github(). The retry-on-failure path already has auth, so this is a one-line fix per call site.

APM CEO (arbiter)
Enterprise and VPN users are a target audience for APM. A tool that fails to use a provided token for its very first network call erodes trust and creates friction in exactly the environments where APM's governance features are most valuable. Accepting as high-priority.

---

Decision

Dimension	Value
Type	type/bug
Area	area/cli
Theme	theme/security
Priority	priority/high
Milestone	Next patch release (confirm with maintainer)
Status	status/triaged

Suggested next action: Fix install.sh to include AUTH_HEADER_VALUE in the first releases/latest curl invocation when the value is non-empty. Apply the same fix to get_latest_version_from_github() in the self-update code path. Add a test (or at least a manual repro note in the PR) covering the rate-limited anonymous quota case.

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · sonnet46 1.4M · ◷