gitfetch: skill directory fetch fails when GH_TOKEN is scoped to a different repo than the skill source

[ggallen]

What happens

When a config-registered agent (ADR-0058) references a skill directory in a different repository than the one the minted GH_TOKEN is scoped for, the git sparse checkout fetch fails with:

Error: loading harness: resolving URL-sourced resources: base skills[0]: fetching skill directory skills/issue-labels:
  gitfetch: git fetch: exit status 128: fatal: could not read Username for 'https://github.com': terminal prompts disabled

fetchBaseSkillDir in internal/harness/compose.go always passes opts.GitToken to FetchTree. When the token is an installation token scoped to repo A (e.g. ggallen-sandbox/integration-service) but the skill directory lives in repo B (e.g. fullsend-ai/agents), GitHub returns 401 — even though repo B is public. Sending an invalid-for-this-repo Authorization: Bearer header causes GitHub to reject the request instead of allowing anonymous access.

What should happen

Fetching skill directories from public repositories should succeed regardless of the GH_TOKEN scope. When an authenticated git fetch fails with an auth error, the fetch should retry without the token so that public repos remain accessible.

How to reproduce

1. Configure a config-registered agent whose harness references a skill directory in a public repo (e.g. fullsend-ai/agents)
2. Run the agent from an org where the minted GH_TOKEN is scoped to a different repo (e.g. ggallen-sandbox/integration-service)
3. The harness loading fails at the skill directory fetch step

Observed in workflow run 28487585922 in ggallen-sandbox/.fullsend (v0.25.0). The triage harness in fullsend-ai/agents references skills/issue-labels; the minted triage token is scoped to ggallen-sandbox/integration-service.

Context

Introduced by #2735 / PR #2736 (replaced GitHub Contents API with git sparse checkout). The previous ForgeClient-based approach used the GitHub REST API which handled token scoping differently.

This blocks testing config-driven agent registration (ADR-0058) for any agent whose skills live in a different repo than the target. Related: #2805, #2806 (URL-sourced resource resolution fixes, both merged and in v0.25.0).

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 2:07 AM UTC · Completed 2:10 AM UTC
Commit: e6b1ae3 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: High · Category: Bug (regression)

Problem

fetchBaseSkillDir() in internal/harness/compose.go unconditionally passes the minted GH_TOKEN to FetchTree(). When the token is scoped to repo A but the skill directory lives in public repo B, GitHub rejects the request because the Authorization: Bearer header carries a token without access to that repo — even though an unauthenticated request would succeed.

This regression was introduced by PR #2736, which replaced the GitHub Contents API with git sparse checkout. The related fixes #2805 and #2806 are already merged in v0.25.0 but do not address this token-scoping issue.

Root Cause Hypothesis

FetchTree() in internal/gitfetch/gitfetch.go sets Authorization: Bearer *** via GIT_CONFIG` env vars whenever a non-empty token is provided. There is no fallback to unauthenticated access when the authenticated fetch fails with an auth error.

Recommended Fix

Add an unauthenticated retry fallback when an auth error is detected. The cleanest approach is inside FetchTree() itself: detect exit status 128 with auth-related error messages, then retry the git fetch without the Authorization header. This protects all callers, not just skill fetches.

Proposed Test Case

Test: FetchTree retries without token on auth failure for public repos

Setup:
  - Mock or configure a git remote that rejects the provided token
    but allows unauthenticated access (simulating a public repo)

Case 1 (happy path - retry succeeds):
  - Call FetchTree with a valid-format but wrong-scope token
  - Verify the fetch succeeds via unauthenticated retry
  - Verify the returned tree contents are correct

Case 2 (both fail - private repo):
  - Configure remote to reject both authenticated and unauthenticated
  - Verify the original auth error is returned (not the anon error)

Case 3 (non-auth error - no retry):
  - Simulate a network timeout or invalid ref error
  - Verify no unauthenticated retry is attempted

Impact

Blocks config-driven agent registration (ADR-0058) for any agent whose skills live in a different repo than the target — a core cross-org skill-sharing use case.

---

Labels: Bug in harness skill-fetching with high impact on cross-repo agent registration.

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 2:13 AM UTC · Completed 2:20 AM UTC
Commit: e6b1ae3 · View workflow run →