[BUG] apm install --frozen reports locked private Git dependency as missing

[chrisbanes]

Describe the bug

apm install --frozen reports a private Git dependency as missing from apm.lock.yaml, even though the dependency is present in the lockfile and regular apm install resolves it successfully.

To Reproduce

Manifest:

dependencies:
  apm:
    - git: git@git.example.com:org/private-skills.git
      ref: 2026.06.10

Generated lockfile:

dependencies:
- repo_url: org/private-skills
  name: private-skills
  host: git.example.com
  resolved_commit: abcdef1234567890abcdef1234567890abcdef12
  resolved_ref: 2026.06.10
  version: 2026.6.10
  package_type: marketplace_plugin

$ apm install --frozen --no-policy

[>] Installing dependencies from apm.yml…
- frozen: apm.lock.yaml is out of sync with apm.yml.
- org/private-skills is declared in apm.yml but missing from apm.lock.yaml
[i] Tip: run ‘apm outdated’ to see what changed, then ‘apm update’.
[!] Install interrupted after 0.0s.

Expected behavior

apm install --frozen should accept the lockfile because the private Git dependency is present and resolved in apm.lock.yaml.

Environment (please complete the following information):

• APM version: 0.23.1
• Platform: macOS arm64
• Install source: Homebrew
• Command: apm install --frozen --no-policy

Additional context

• apm install --no-policy succeeds and installs this dependency from cache.
• apm outdated also sees the dependency.
• Rewriting the manifest dependency from SSH to HTTPS did not fix the frozen validation failure.
• Regenerating apm.lock.yaml with APM 0.23.1 did not fix the frozen validation failure.
• apm install --frozen --dry-run appears to pass, but the real frozen install fails.

[github-actions]

Triage decision

accept

Proposed labels

theme/governance
area/lockfile
type/bug
status/accepted
priority/high

Milestone

null -- open milestones could not be confirmed; this blocks CI and is patch-worthy.

Suggested next action

Investigate the SSH URL to normalized lockfile entry matching logic in the --frozen install validator to identify why git@host:org/repo.git is not matched against repo_url: org/repo, host: host in the lockfile.

Suggested issue comment

Thanks for the detailed report, @chrisbanes! The manifest, lockfile content, exact error output, and diagnostic observations (dry-run vs. real install, SSH vs. HTTPS test) make this straightforward to analyze.

Confirmed: `apm install --frozen` is reporting a private Git dependency as missing from the lockfile even though it is clearly present with a pinned `resolved_commit`. This is a false positive in the frozen install validator that breaks CI for private SSH-based dependencies.

The likely root cause is a URL normalization mismatch: the manifest declares `git@git.example.com:org/private-skills.git` (SSH URL) but the lockfile stores it as `repo_url: org/private-skills, host: git.example.com` (normalized form). The frozen validator appears to compare the raw manifest URL against the lockfile without accounting for this normalization, producing a false "missing from lockfile" result.

The dry-run passing while the real install fails is a useful diagnostic -- it suggests the mismatch occurs in the actual validation path, not the dry-run path.

We will investigate and fix the matching logic in the frozen install validator. This is `priority/high` because it breaks CI for a supported and common configuration. If you have a minimal reproducible case you can share, that would help, but we can proceed from the information provided.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The frozen install flag is APM's primary reproducibility guarantee for CI -- "lockfile is canonical" is a core mental model APM commits to. A false positive that breaks CI for private SSH-based dependencies violates this guarantee. The error message ("run apm outdated to see what changed") is misleading: there is nothing to update because the lockfile is not out of sync. The dry-run vs. real-install discrepancy makes diagnosis harder. From a composability lens (CI must work without extra flags), this is a blocking bug for affected users.

Supply Chain Security Expert -- Risk-Surface Reviewer

The --frozen flag is the lockfile integrity gate. A false positive (rejecting a valid lockfile) is bad UX; a false negative (accepting a tampered lockfile) would be a security vulnerability. This bug is a false positive: the validator is too strict and rejects a valid lockfile entry. The fix must correct the URL normalization matching without weakening the validation -- it must not allow tampered lockfiles to pass by normalizing too aggressively. The lockfile stores entries in normalized form (repo_url + host); the validator must normalize the manifest URL before comparison. area/lockfile and theme/governance apply -- the frozen install is a governance mechanism for reproducibility and audit.

OSS Growth Hacker -- Contributor-Tone Reviewer

Author chrisbanes has author_association: NONE. The report is thorough: minimal manifest, exact lockfile, error output, and careful diagnostic context (dry-run vs. real, SSH vs. HTTPS test, apm outdated observation). This contributor has done careful debugging. The reply should confirm the bug, give a technical diagnosis of the likely root cause (URL normalization mismatch), and signal this will be fixed promptly since it breaks CI.

Python Architect -- Architecture Reviewer

Not activated -- the bug is a URL matching/normalization logic error in the frozen install validator; no cross-cutting design decision is required. The fix should normalize the manifest SSH URL (strip git@, parse host/path, strip .git) to the repo_url + host form before comparison against the lockfile entry.

Doc Writer -- Documentation Reviewer

Not activated -- bug fix in the frozen install validator; no new user-facing documentation surface is implied.

APM CEO -- Triage Arbiter

A broken --frozen flag for private SSH dependencies is a CI blocker for enterprise customers. The frozen install is APM's reproducibility guarantee -- it must work for all supported dependency configurations. The diagnosis (SSH URL normalization mismatch in the frozen validator) is plausible and bounded. Accept with priority/high and assign to the lockfile governance surface. The fix must be careful not to weaken the integrity validation while correcting the false positive.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/governance",
  "areas": ["area/lockfile"],
  "type": "type/bug",
  "status": "status/accepted",
  "priority": "priority/high",
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Investigate the SSH URL to normalized lockfile entry matching logic in the --frozen install validator to fix the false-positive missing-dependency report.",
  "comment_markdown": "Thanks for the detailed report, @chrisbanes! The manifest, lockfile content, exact error output, and diagnostic observations make this straightforward to analyze.\n\nConfirmed: `apm install --frozen` is reporting a private Git dependency as missing from the lockfile even though it is clearly present with a pinned `resolved_commit`. This is a false positive in the frozen install validator that breaks CI for private SSH-based dependencies.\n\nThe likely root cause is a URL normalization mismatch: the manifest declares `git@git.example.com:org/private-skills.git` (SSH URL) but the lockfile stores it as `repo_url: org/private-skills, host: git.example.com` (normalized form). The frozen validator appears to compare the raw manifest URL against the lockfile without accounting for this normalization, producing a false \"missing from lockfile\" result.\n\nThe dry-run passing while the real install fails is a useful diagnostic -- it suggests the mismatch occurs in the actual validation path, not the dry-run path.\n\nWe will investigate and fix the matching logic. This is `priority/high` because it breaks CI for a supported configuration."
}

---

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 · 210.7 AIC · ⌖ 13.5 AIC · ⊞ 9.2K · ◷