Conductor gstack template fails on new project creation with build exit code 128

[pyx900]

Summary

Creating a new project in Conductor with the gstack template fails after cloning the template with:

Failed to create repo: error: script "build" exited with code 128

Repro

1. Open Conductor.
2. Choose the gstack template in Quick start.
3. Create a brand-new repo/project.
4. Conductor clones .claude/skills/gstack into the new project.
5. The install/build step fails with exit code 128.

What I verified

• GitHub auth can succeed and the template clone step completes.
• The failure happens after clone, during the template build script.
• origin/main currently contains this in package.json:

"build": "... && git rev-parse HEAD > browse/dist/.version && git rev-parse HEAD > design/dist/.version && git rev-parse HEAD > make-pdf/dist/.version && ..."

Likely root cause

In a freshly created repo before the first commit exists, git rev-parse HEAD exits with code 128.

That makes the template fail in bootstrapping flows that run before the initial commit is created.

Suggested fix

Use a fallback when HEAD does not exist yet, for example:

(git rev-parse HEAD 2>/dev/null || echo unknown) > browse/dist/.version
(git rev-parse HEAD 2>/dev/null || echo unknown) > design/dist/.version
(git rev-parse HEAD 2>/dev/null || echo unknown) > make-pdf/dist/.version

This fixed the local reproduction when testing the template outside an initialized repo with commits.

[Cloverings1]

I opened a PR that should address this: #1177

The fix makes the build tolerate generated repos before their first commit exists by falling back to unknown when git rev-parse HEAD cannot resolve yet.

[Cloverings1]

Small update: I confirmed this locally in Conductor.

A temporary local workaround that made only git rev-parse HEAD return unknown for an unborn repo allowed the GStack Quick Start to complete. That matches the fix in #1177: make GStack's build tolerate missing HEAD during fresh repo bootstrapping instead of exiting 128.

I also verified the PR against current main: focused tests pass, and bun run build succeeds in a fresh Git repo with no commits.

[nadeemamdev]

Upvote

[adhithyasash1]

I confirm this, thanks!

[leadfatherio]

i confirm

[gustavogarci]

Confirmed

[stiansando]

upvote

[sene1337]

Confirming with a captured process trace from Conductor on macOS today (2026-05-01). The failure isn't from an unborn HEAD — Conductor's quickstart explicitly removes the .git directory before running setup:

GIT_TERMINAL_PROMPT=0 git clone https://github.com/garrytan/gstack.git \
  .claude/skills/gstack \
  && cd .claude/skills/gstack \
  && rm -rf .git \
  && ./setup --host claude \
  && ./setup --host codex

So git rev-parse HEAD exits 128 with fatal: not a git repository, not unknown revision. The fix in #1177 still resolves it (the 2>/dev/null || echo unknown catches both cases), but it might also be worth pinging Conductor to drop the rm -rf .git since it's the proximate cause.

[darbsllim]

sene1337's lobster meat here ... can confirm I worked with claude code opus 4.7 to try trace this problem this morning.

[Cloverings1]

Quick update after the newer confirmations here:

• @sene1337's trace usefully narrows the Conductor path: setup is running after .git is removed, so git rev-parse HEAD can fail as fatal: not a git repository, not only as an unborn-HEAD case.
• Fix gstack build when Conductor creates a repo with unborn HEAD #1177 has been updated against current main and now explicitly covers both failure modes:
  • a fresh Git repo before the first commit exists
  • a checkout where Git metadata is not present

Focused validation on the updated PR passes locally:

bun test test/write-build-version.test.ts test/setup-codesign.test.ts
# 9 pass, 0 fail

The same fallback handles both observed paths by writing unknown instead of letting the build exit 128, while preserving the real commit SHA when HEAD resolves normally.