`gh aw init` fails with "not in a git repository" on macOS ARM64 (Apple Silicon)

[anthonymastreanvae]

Description

gh aw init and gh aw add-wizard fail with "not in a git repository" on macOS ARM64 (Apple Silicon M5 Max). The error occurs in every git repository, including freshly created ones.

Environment

• OS: macOS (Apple Silicon M5 Max, arm64)
• gh version: gh from /usr/local/bin/gh
• gh-aw version: v0.71.5
• git version: 2.50.1 (Apple Git-155)
• Binary architecture: gh-aw binary is Mach-O 64-bit executable x86_64 (running under Rosetta)
• GHE instance: *.ghe.com

Reproduction

# In any valid git repo
cd /tmp && git init test-repo && cd test-repo
git commit --allow-empty -m "init"
git remote add origin https://github.com/octocat/Hello-World.git

# Fails
gh aw init

# Also fails with GHE
GH_HOST=itpie.ghe.com gh aw init

Observed behavior

🚀 Welcome to GitHub Agentic Workflows!

This tool will initialize your repository for GitHub Agentic Workflows.

ℹ Setting up repository...

✗ not in a git repository

Expected behavior

gh aw init should detect the git repository and proceed with setup.

Investigation

• git rev-parse --git-dir returns .git successfully
• .git/ is a real directory (not a worktree file)
• git status shows a valid repo on branch main
• The failure reproduces in every git repository, including fresh git init repos
• The gh-aw binary is x86_64-only, running under Rosetta 2 on arm64
• No native ARM64 build is distributed

Likely cause

The binary embeds the string not in a git repository or git command failed: %w, suggesting it uses an embedded Go git library (likely go-git) rather than shelling out to /usr/bin/git. Something in the git detection path fails silently under Rosetta or on macOS ARM64 specifically.

Related

• P1: Smoke macOS ARM64 — 100% failure since 2026-02-20 (76+ days) #30775 — P1: Smoke macOS ARM64 100% failure since 2026-02-20 (76+ days)
• fix: macOS compatibility for copilot CLI install + FAQ on macOS runners #16970 — PR (closed) attempting macOS ARM64 compatibility fixes

---

Generated with GitHub Copilot

[pelikhan]

/scout research if a go package implements git instead of relying on git executable

[github-actions]

🔭 Recon complete! Scout has charted the territory. Map ready! 🗺️

[github-actions]

🔍 Scout Research Report

Triggered by @pelikhan

Executive Summary

Yes — github.com/go-git/go-git/v5 is a well-established, actively maintained pure Go implementation of git that does not require the git executable at all. It covers the most common operations (clone, push, pull, commit, log, status) and supports HTTP, SSH, and Git protocol transports. It has some feature gaps relative to full git, but is widely used in production.

Click to expand detailed findings

Research Findings

go-git (github.com/go-git/go-git/v5)

The primary answer to the question. go-git is a pure Go git implementation that has been actively developed since 2015.

Key characteristics:

• Written entirely in Go — zero dependency on the git binary
• Supports both high-level (porcelain) and low-level (plumbing) operations
• Multiple storage backends: filesystem, in-memory (storage/memory), or custom via the Storer interface
• Transport protocols: HTTP, SSH, Git protocol (plumbing/transport)
• Used at scale by Keybase, Gitea, and Pulumi

Installation:

go get github.com/go-git/go-git/v5

Minimal clone example:

import git "github.com/go-git/go-git/v5"

r, err := git.PlainClone("/tmp/foo", false, &git.CloneOptions{
    URL: "https://github.com/go-git/go-git",
})

In-memory clone (no disk I/O, no git binary):

import (
    git "github.com/go-git/go-git/v5"
    memory "github.com/go-git/go-git/v5/storage/memory"
)

r, err := git.Clone(memory.NewStorage(), nil, &git.CloneOptions{
    URL: "https://github.com/go-git/go-git",
})

Supported Operations

Porcelain (high-level): Clone, Pull, Push, Commit, Status, Log, Add, Checkout, Branch, Tag, Fetch, Reset

Transports: HTTP (basic auth, token), SSH (key-based, password), local filesystem

Known Limitations

• Not all git features are implemented (git is enormous). The project maintains a compatibility document listing gaps.
• Forgejo (a Gitea fork) dropped go-git support in 2025, citing that the optional TAGS=gogits build flag was rarely used — this reflects that production git servers still prefer the native git binary for full compatibility, though the library itself works fine for programmatic use.
• Two CVEs patched in 2024: path traversal/RCE (GO-2024-2456) and DoS (GO-2024-2466) — ensure you're on the latest v5 release.

Other Pure-Go Alternatives (minor)

• "Gogit" — minimal "just enough git to push" toy project (not production-ready)
• No other serious pure-Go git library exists; go-git is the clear standard

Recommendations

• Use github.com/go-git/go-git/v5 — it is the definitive answer. It is production-ready, actively maintained, and does not require git installed.
• Pin to the latest v5 release to pick up 2024 security patches.
• Review the compatibility docs if you need edge-case git features.
• For advanced scenarios (e.g. large-repo performance), test against your workload — the library trades full feature parity for pure Go portability.

Key Sources

• go-git/go-git on GitHub
• [pkg.go.dev reference]((pkg.go.dev/redacted)
• [Git SCM book — embedding git with go-git]((gitscm.com/redacted)
• In-memory push example (Gist)

Suggested Next Steps

1. Add github.com/go-git/go-git/v5 as a dependency.
2. Replace exec.Command("git", ...) calls with the equivalent go-git API calls.
3. Verify coverage against the compatibility doc for any non-standard git operations in use.

References:

• go-git/go-git
• §25515750847

🔭 Intelligence gathered by Scout · ● 101.6K · ◷

[github-actions]

🍪 Issue Monster selected this for Copilot

I've identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.

If assignment succeeds, the Copilot coding agent will analyze the issue and create a pull request with the fix.

Om nom nom! 🍪

🍪 Om nom nom by Issue Monster · ● 89.1K · ◷