apm install: FQDN monorepo subpath on GHES fails; hoping for CLI-only install without manual apm.yml edit

[KomTak001]

Summary

On our private GHES host, we would like to install an APM package from a monorepo subpath with apm install <ref> only — similar to GitHub:

apm install github/awesome-copilot/skills/review-and-refactor --target copilot

We confirmed that the same style of command works on github.com.

On GHES, the equivalent command does not seem to work for us.

Reproduction

• Host: ghe.example.com
• Repo: my-org/agent-skills-monorepo
• Package path: packages/skill-alpha

apm install "ghe.example.com/my-org/agent-skills-monorepo/packages/skill-alpha"

[x] ghe.example.com/my-org/agent-skills-monorepo/packages/skill-alpha -- not accessible or doesn't exist

With --verbose, git ls-remote appears to target a URL that includes the subpath:

fatal: repository 'https://ghe.example.com/my-org/agent-skills-monorepo.git/packages/skill-alpha/' not found

The same result with an HTTPS URL that embeds the subpath:

apm install "https://ghe.example.com/my-org/agent-skills-monorepo.git/packages/skill-alpha"

Repo root without subpath validates, but installs the wrong manifest (bundle with local path: deps):

apm install --dry-run "ghe.example.com/my-org/agent-skills-monorepo"

What we hoped for

apm install ghe.example.com/my-org/agent-skills-monorepo/packages/skill-alpha

…would update apm.yml and install packages/skill-alpha, e.g.:

dependencies:
  apm:
    - git: "https://ghe.example.com/my-org/agent-skills-monorepo.git"
      path: packages/skill-alpha
      ref: main

If FQDN shorthand is hard to support on GHES, CLI flags such as --git / --path / --ref would also help.

Workaround we use today

We add object form to apm.yml manually, then run apm install. This works, but we were hoping to avoid editing apm.yml by hand.

Environment

• OS: macOS
• APM version: 0.18.0
• Auth: gh auth login --hostname ghe.example.com (HTTPS clone works)

Related

• [BUG] Skills subpath for GitLab monorepo is not working #610 — similar symptom on GitLab; closed with manual apm.yml edit
• Support installing individual skills/agents from monorepo packages (including private repo support) #872 — monorepo subpath on GitHub
• ADO: full https:// URL with sub-path rejected by parser (shorthand and object form work) #1128 — ADO URL with embedded subpath (fixed)
• [BUG] Artifactory + GitLab subgroups: apm install fails for 3+ segment project paths #1498 / fix(artifactory): deterministic boundary probe for nested GitLab paths #1472 — boundary probe for nested GitLab paths

Suggestion

• Install-time boundary probe for GHES / generic git hosts (like fix(artifactory): deterministic boundary probe for nested GitLab paths #1472 for Artifactory)
• Or apm install --git / --path / --ref to write object form to apm.yml
• Clearer error when subpath is embedded in the git URL (mentioned in Support installing individual skills/agents from monorepo packages (including private repo support) #872)

[github-actions]

Triage decision

accept

Proposed labels

theme/portability
area/enterprise
area/distribution
area/docs-site
type/bug
status/accepted
priority/high

Milestone

null (no open milestones verified)

Suggested next action

Apply the GHES boundary-probe pattern from #1472 (GitLab) to generic git hosts: probe with git ls-remote at progressively shorter path segments to find where the repository ends and the subpath begins.

Suggested issue comment

Thanks for the clear reproduction and the related-issue references, @KomTak001 -- linking #610, #872, #1128, and #1472 gives good context on the pattern of work already done here.

The root cause is that APM's FQDN parser currently treats ghe.example.com/my-org/repo/packages/skill-alpha as a git URL with the subpath embedded, and git ls-remote cannot resolve that. GitHub.com works because APM has special-cased github.com to parse owner/repo/subpath correctly; GHES and other generic git hosts do not yet get that treatment.

The fix pattern already exists for GitLab (#1472) and ADO (#1128): a boundary probe that uses git ls-remote at progressively shorter path segments to find where the repository ends and the subpath begins. Extending this to GHES (and generic git hosts with a custom hostname) would fix your case.

In the meantime, the workaround you already use (adding the object form to apm.yml manually) is correct:

dependencies:
  apm:
    - git: "(ghe.example.com/redacted)
      path: packages/skill-alpha
      ref: main

This will also be the output format once GHES subpath parsing is fixed.

We are accepting this as a high-priority portability bug. If you can test a fix against your GHES instance, that would be very valuable.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The error message (-- not accessible or doesn't exist) is misleading -- the repository exists and is accessible; the issue is URL parsing. A better error would say "Subpath in FQDN install refs is not yet supported for GHES; use the object form in apm.yml instead." The parity gap between GitHub.com and GHES is a significant usability issue for enterprise users: the same mental model should work on both hosts.

Supply Chain Security Expert -- Risk-Surface Reviewer

The "repo root without subpath installs the wrong manifest" behavior is a correctness issue, not a security issue -- the correct repo is accessed, just the wrong package within it. The boundary-probe pattern (#1472) must include host-validation to ensure the probed GHES URL is the same host the user specified. No theme/security needed; theme/portability + area/enterprise is correct.

OSS Growth Hacker -- Contributor-Tone Reviewer

KomTak001 (NONE association) did thorough research including related issues and a clear workaround. The reply acknowledges the related issue history to show these are known gaps being tracked, and offers the boundary-probe fix pattern as a concrete next step. Inviting them to test a fix against their GHES instance turns a bug report into a potential contribution.

Python Architect -- Architecture Reviewer

The GHES case maps cleanly onto the boundary-probe pattern from #1472. The resolver needs to: (1) detect non-github.com hosts, (2) apply a boundary probe (try git ls-remote with progressively shorter paths), (3) split the result into repo URL + subpath. This is a contained change in the URL resolver/parser, similar to the GitLab fix. status/accepted is appropriate; no new design needed given the existing pattern.

Doc Writer -- Documentation Reviewer

The install docs should document GHES subpath syntax once supported, and the object-form workaround should be documented now for GHES users. area/docs-site rides as a secondary label. The related-issue references in the report suggest the docs have a gap on GHES support coverage.

APM CEO -- Triage Arbiter

GHES subpath support is a high-value enterprise portability feature. The fix pattern exists (GitLab, ADO). Enterprise users blocked by this have a workaround but need the FQDN shorthand to work for broader adoption. Strategic: GHES support is a key differentiator for enterprise APM adoption; gaps here slow enterprise rollout. theme/portability + area/enterprise + priority/high is correct.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/portability",
  "areas": ["area/enterprise", "area/distribution", "area/docs-site"],
  "type": "type/bug",
  "status": "status/accepted",
  "priority": "priority/high",
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Apply the GHES boundary-probe pattern from #1472 to generic git hosts: probe with git ls-remote at progressively shorter path segments to find repo boundary vs subpath."
}

---

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 6.5M · ◷

[KomTak001]

Thank you for accepting the issue.

Yes, we will help you confirm the operation in the GHES environment for the correction.

Thank you for your help