GSD quick isolated executor starts from stale HEAD after pre-dispatch plan commit

[electroheadfx]

Pre-submission checklist

• I have searched existing issues and this bug has not already been reported

GSD Version

1.4.5

Runtime

Claude Code

Operating System

macOS

Node.js Version

v24.15.0

Shell

/bin/zsh

Installation Method

npx @opengsd/gsd-core@latest (fresh run)

What happened?

GSD quick isolated executor starts from stale HEAD after pre-dispatch plan commit

What did you expect?

/gsd:quick --discuss solidify phase 36.1 ...

GSD config appears to have workflow.use_worktrees=true.

What happened

GSD quick mode created the quick plan and committed it before executor dispatch:

69923cf docs(260615-c4t): pre-dispatch plan for solidify phase 36.1

Then the isolated executor was spawned with a guard expecting that plan commit:

Expected HEAD: 69923cf551fa85c0645a3b41e66e0e65739f98a3

But the executor worktree was created from the previous commit:

Actual HEAD: 778c92c8c2b23d71b1281d6c1fa73aba8e4e1666

The executor halted correctly because it could not see the pre-dispatch plan commit.

I retried by spawning a fresh isolated executor after confirming main was ahead by the plan commit, but the new worktree again started from 778c92c instead of 69923cf.

Steps to reproduce

/gsd:quick --discuss solidify phase 36.1 ...

GSD config appears to have workflow.use_worktrees=true.

What happened

GSD quick mode created the quick plan and committed it before executor dispatch:

69923cf docs(260615-c4t): pre-dispatch plan for solidify phase 36.1

Then the isolated executor was spawned with a guard expecting that plan commit:

Expected HEAD: 69923cf551fa85c0645a3b41e66e0e65739f98a3

But the executor worktree was created from the previous commit:

Actual HEAD: 778c92c8c2b23d71b1281d6c1fa73aba8e4e1666

The executor halted correctly because it could not see the pre-dispatch plan commit.

I retried by spawning a fresh isolated executor after confirming main was ahead by the plan commit, but the new worktree again started from 778c92c instead of 69923cf.

Error output / logs

GSD warming

- No code edits were made.
- The only change so far is the pre-dispatch plan commit: 69923cf docs(260615-c4t): pre-dispatch plan for solidify phase 36.1.
- The isolated executor refused to run because Claude Code created its worktree from 778c92c instead of 69923cf.
- Because of your saved preference, I should not silently fall back to executing on main.

The safest option is to retry isolated after making sure the worktree starts from the plan commit.

GSD Configuration

GSD State (if relevant)

Runtime settings.json (if relevant)

How often does this happen?

Every time (100% reproducible)

Impact

Moderate — Feature is broken but I have a workaround

Workaround (if any)

No response

Additional context

No response

Privacy Checklist

• I have reviewed all pasted output for PII (usernames, paths, API keys) and redacted where necessary

[github-actions]

Branch fix/1265-gsd-quick-isolated-executor-starts-from- created.

git fetch origin && git checkout fix/1265-gsd-quick-isolated-executor-starts-from-

[trek-e]

This was generated by AI during triage.

Triage Notes

Thanks for the detailed report — this is a real bug. We've confirmed the mechanism by code trace but need a couple of specifics from your environment to pin the exact failing configuration before we write the fix brief (the fix has a design fork that your config will settle).

What we've established so far:

• Confirmed via code trace (high confidence on the ordering; the harness-timing half is medium confidence and is the reason for the questions below). In the quick-mode workflow, the EXPECTED_BASE SHA used by the worktree-base guard is captured after the pre-dispatch plan commit, so it equals the plan-commit SHA (your 69923cf).
• But under Claude Code's isolation=worktree dispatch, the executor's worktree is branched from the HEAD as it stood before the model made the plan commit — i.e. the parent commit (778c92c). So the guard's exact-equality check (worktree HEAD == EXPECTED_BASE) fails and the executor correctly halts. Retrying doesn't help because the harness re-resolves the same pre-commit base.
• Net: quick mode commits the plan expecting the about-to-be-created worktree to inherit it at its branch HEAD, but the Claude Code runtime doesn't branch from the post-commit HEAD. That's a genuine gsd-core bug — fixable in the quick workflow — but the fix choice (embed the plan inline in the executor prompt vs. have the executor read it from the committed tree) depends on your exact setup, hence the questions.

What we still need from you (@electroheadfx):

• Your GSD config, specifically the workflow.use_worktrees and the worktree base-ref setting (e.g. worktree.baseRef). The issue's GSD Configuration block was empty. gsd-tools query config.json (redact anything sensitive) is ideal.
• Does it still reproduce on the current @next RC (1.5.0-rc.4)? You reported 1.4.5; the quick-mode worktree path has changed recently, so confirming on the latest RC tells us whether this is already partly addressed.
• Your .planning/STATE.md frontmatter at the time of failure, plus — if you still have them — confirmation that the worktree's actual HEAD (778c92c) is the direct parent of the plan commit (69923cf). git log --oneline -2 69923cf would show it.
• Any git hooks (e.g. a pre-commit hook) configured in that repo? Unlikely to matter, but it would rule out a commit-timing interaction.

Once we have these we can move this to a fix brief with the right approach selected.

[electroheadfx]

Thanks for the reply, its a great tool.
I worked and got this issue severals time on this repo: https://github.com/electroheadfx/efx-motion-editor

https://github.com/electroheadfx/efx-motion-editor

here are the specifics from my environment.

GSD config

Project config from .planning/config.json:

{
  "mode": "yolo",
  "parallelization": true,
  "commit_docs": true,
  "model_profile": "quality",
  "workflow": {
    "research": true,
    "plan_check": true,
    "verifier": true,
    "_auto_chain_active": false
  },
  "granularity": "fine"
}

I do not see explicit workflow.use_worktrees or worktree.baseRef entries in this project config. So if worktrees were enabled, it may have been coming from defaults/runtime behavior rather than an explicit config value.

Project-local GSD version file:

.claude/gsd-core/VERSION = 1.4.5

The installed gsd-tools --version currently reports:

gsd-sdk v1.50.0-canary.0

but the failure I reported happened on the project-local 1.4.5 setup. I have not yet confirmed reproduction on 1.5.0-rc.4.

STATE.md frontmatter at/around failure

From .planning/STATE.md:

---
gsd_state_version: 1.0
milestone: v0.8.0
milestone_name: Standalone Physics Paint
status: executing
stopped_at: Phase 36.1 UI-SPEC approved
last_updated: "2026-06-15T07:32:20.000Z"
last_activity: 2026-06-15 -- Completed quick task 260615-iui: Phase 36.1 Consolidation play canvas brush cache fix
progress:
  total_phases: 5
  completed_phases: 3
  total_plans: 30
  completed_plans: 27
  percent: 60
---

The body later showed the current activity as:

Last activity: 2026-06-15 -- Completed quick task 260615-c4t: solidify phase 36.1

Commit parentage

Confirmed: the executor’s actual stale HEAD was the direct parent of the plan commit.

69923cf docs(260615-c4t): pre-dispatch plan for solidify phase 36.1
778c92c docs(260615-pdt): record play duration toast debug

And:

69923cf^ = 778c92c8c2b23d71b1281d6c1fa73aba8e4e1666
778c92c  = 778c92c8c2b23d71b1281d6c1fa73aba8e4e1666

Git hooks

No active custom hook path appears configured.

git config --get core.hooksPath resolves to:

/Users/lmarques/Dev/efx-motion-editor/.git/hooks

The repo only has the default sample hooks in .git/hooks:

pre-commit.sample
commit-msg.sample
pre-push.sample
...

I did not find an active Husky/Lefthook/pre-commit setup in the repo. So hooks seem unlikely to be involved.

Summary

So the clearest reproduction context is:

• GSD project-local version: 1.4.5
• Config does not explicitly set workflow.use_worktrees or worktree.baseRef
• Quick mode created plan commit 69923cf
• Isolated executor worktree started from direct parent 778c92c
• No custom app code changes occurred before the halt
• No active Git hooks appear to be involved
• Not yet retested on 1.5.0-rc.4

[electroheadfx]

I agree this is not the same stale-HEAD failure as before.

On 1.5.0-rc.4, the isolated executor appears to have run, so the original worktree-base issue did not reproduce in this attempt.

However, this seems to expose a separate GSD safety/workflow issue:

• the isolated executor overreached the requested scope
• I chose not to merge that worktree
• the proposed recovery path was to continue directly on the main checkout

That feels unsafe for a workflow where workflow.use_worktrees=true / isolated execution is expected. If an isolated executor overreaches, GSD should probably stop and ask for explicit confirmation, or create a fresh narrowly-scoped isolated worktree, rather than falling back to editing main directly.

So I would classify this as a separate GSD executor-scope / unsafe-recovery issue, not the original stale-HEAD worktree-base bug.