Git worktree commits did not sync

[tregusti]

Hi, cohorting with you in 4 right now. Thnak you!

During the night I ran an AFk agent in sandcastle that created two commits in the git worktree. But they were not synced over. I just tried to set this up (with claude), and the setup seems corrrect.

I asked claude to look into the problem, and it said there is a bug:

can you help me? I just ran ralph loop in sandcastle, and it made two commits in the sandcastle remote. As I understand it, sandcastle should move those over to my head since I have the merge to head branch strategy. That did not happen, though. Is there some configuration missing, or how is this supposed to work?

log @.sandcastle/logs/sandcastle-20260610-222625-cf4548.log

Answer:

Read .sandcastle/logs/sandcastle-20260610-222625-cf4548.log (368 lines)

Let me look at the Sandcastle config and current git state to understand what's set up.

Searched for 6 patterns, read 1 file, ran 11 shell commands

Now I have the full picture. Here's what happened:

Timeline:
- 22:25:46 — e3ea376 was HEAD when Sandcastle started
- 22:26:25 — Sandcastle run began
- 22:33/22:39 — Agent committed both refactors on the sandcastle branch in Docker, pushed them to origin/sandcastle/...
- ~22:40 — Sandcastle run completed (2 iterations, agent signaled NO MORE TASKS)
- 22:51:17 — We committed f1049fa in this session (AFTER the run)

Why the merge didn't happen:

The log has "Syncing 1 commit to host done (0.0s)" for both iterations — completing in 0 seconds is the tell. The syncOut function uses git format-patch + git am --3way to apply the sandbox's commits onto the host-side worktree. It appears the patches weren't applied, so hasNewCommits came back 0 and the "Merging to main" step was skipped entirely. There's no "Merging to main" line anywhere in the log to confirm.

This looks like a bug in the Sandcastle SDK's merge-to-head flow with Docker — the sync completed too fast and silently skipped the git am step. The config in main.ts is correct.

Your current state: The two branches have diverged from e3ea376. The sandcastle branch has the two refactors; main has our combat-log fix. Both touch game_state.rs, so a straight git merge sandcastle/20260610-222625-cf4548 will conflict.

Want me to do the merge and resolve the conflicts, or would you prefer to handle it manually?

A truncated log file, filtering out most of claude implementing stuff:

--- Run started: 2026-06-10T20:26:26.565Z ---
Iteration 1/5
Setting up sandbox
Setting up sandbox done (0.8s)
Expanding shell expressions
  gh issue list --state open --label agent:implement --json number,title,comments → ~47 tokens
Expanding shell expressions done (1.2s)
Agent started
I'll start by reading the details of both issues to pick the right task.
Bash(gh issue view 29)
Bash(gh issue view 27)

...

Bash(git log --oneline -5)
Bash(git commit -m "$(cat <<'EOF'
...
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
EOF
)")
Pre-commit hooks ran the check and all 60 tests — everything passed. Now push:
Bash(git push)
Bash(git push --set-upstream origin sandcastle/20260610-222625-cf4548)
Bash(git remote -v)
Bash(gh auth status 2>&1)
Bash(gh auth setup-git && git push --set-upstream origin sandcastle/20260610-222625-cf4548)
Pushed. Now create the QA issue:

...

All 60 tests pass. Commit pushed, QA issue created (#31), issue #29 closed.
Agent stopped
Syncing 1 commit to host
Syncing 1 commit to host done (0.0s)
Collecting commits
Collecting commits done (0.0s)
Iteration 2/5
Setting up sandbox
Setting up sandbox done (0.8s)
Expanding shell expressions
  gh issue list --state open --label agent:implement --json number,title,comments → ~28 tokens
Expanding shell expressions done (0.6s)
Agent started
I'll work on issue #27
...

Bash(git commit -m "$(cat <<'EOF'
...
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
EOF
)")
Commit succeeded (pre-commit hooks ran tests — all 60 pass). Now let me push and handle the post-implementation steps.
Bash(git push)
Now create the QA issue.

...

All 60 tests pass unchanged, no warnings, no behavior changes. QA issue created.

<promise>NO MORE TASKS</promise>
Agent stopped
Syncing 1 commit to host
Syncing 1 commit to host done (0.0s)
Collecting commits
Collecting commits done (0.0s)
Agent signaled completion after 2 iteration(s).
Run complete: agent finished after 2 iteration(s).

And finally the main.ts:

import { createWorktree, claudeCode } from "@ai-hero/sandcastle";
import { docker } from "@ai-hero/sandcastle/sandboxes/docker";

await using wt = await createWorktree({
  branchStrategy: { type: "merge-to-head" },
});

await wt.run({
  agent: claudeCode("claude-opus-4-6"),
  sandbox: docker(),
  idleTimeoutSeconds: 900,
  promptFile: "./.sandcastle/prompt.md",
  maxIterations: 5,
  completionSignal: "<promise>NO MORE TASKS</promise>",
});

[github-actions]

Triage — read-only first pass

Root cause (one-line)

createWorktree accepts branchStrategy but never propagates it to wt.run() / wt.interactive() / wt.createSandbox() — those three always pass branch: worktreeInfo.branch, which SandboxLifecycle interprets as "explicit-branch" mode and skips the merge-to-host step.

What actually happened in your run

1. createWorktree({ branchStrategy: { type: "merge-to-head" } }) created a worktree on a fresh sandcastle/20260610-222625-cf4548 branch (WorktreeManager.ts:317-326).
2. wt.run(...) forwarded branch: worktreeInfo.branch into orchestrate (createWorktree.ts:647) and on into withSandboxLifecycle({ branch, ... }) (Orchestrator.ts:357).
3. In SandboxLifecycle.ts:197-205, because branch is truthy, hostCurrentBranch is set to null.
4. The agent committed inside the docker sandbox. applyToHost → syncOut shipped the patches onto the worktree (so the temp branch did advance) and bumped refs/sandcastle/sync-base.
5. After sync, the lifecycle reached the merge block — but because hostCurrentBranch === null (SandboxLifecycle.ts:404), it skipped the entire if (hostCurrentBranch !== null) { ... Merging to ${hostCurrentBranch} ... } block and jumped straight to "Collecting commits" via git rev-list "${baseHead}..refs/heads/${targetBranch}". The commits landed on the temp branch but were never merged onto your main.

The contrast that makes the bug obvious: in the top-level run() flow, src/run.ts:597-600 deliberately sets branch: undefined for merge-to-head so the lifecycle takes the merge path. createWorktree.ts skips that step.

Claims, verified

Claim	Verdict
The user's main.ts config is correct	True — bug is API-side, not config-side.
Commits ended up on sandcastle/<TS> but not on HEAD	True — confirmed by reading the lifecycle's "explicit branch" path.
The cited assistant's diagnosis ("git format-patch + git am --3way silently skipped, hasNewCommits came back 0")	Misdiagnosis. countCommitsToSync (syncOut.ts:175-210) returned 1, so the sandbox really was ahead. A git am failure prints a recovery message via buildRecoveryMessage (syncOut.ts:423-431) — the user did not report one. The 0.0s sync time is consistent with a single small patch on a fast host; the real smoking gun is the missing "Merging to main" line, which is gated on hostCurrentBranch !== null.

Relevant files

• src/createWorktree.ts:216-224 — branchStrategy is extracted only for branch/baseBranch, then discarded.
• src/createWorktree.ts:393-401 (worktreeInteractive) and :647 (worktreeRun) — both unconditionally pass branch: worktreeInfo.branch.
• src/createSandbox.ts:339 (createSandboxFromWorktree → orchestrate) — same pattern.
• src/SandboxLifecycle.ts:197-205 — gate where the bug becomes invisible (!branch ⇒ null).
• src/SandboxLifecycle.ts:404-497 — the merge block that gets skipped, including the temp-branch teardown at :425 (git checkout --detach) and :465-469 (git branch -D).
• src/run.ts:597-600 — the correct precedent for routing branch based on strategy.

Open questions for the implementer

1. Semantics of wt.run() + merge-to-head: merge after every iteration (A), or merge only at wt.close() / via an explicit wt.merge() (B)? The README ("changes are merged back to HEAD when done. The temp branch is cleaned up after merge.") leans toward (A), but the createWorktree contract says "worktree persists" — so option (A) needs to keep the source branch alive.
2. wt.interactive() and wt.createSandbox() carry the same gap. interactive is a single session so the timing question is simple; createSandbox is open-ended.
3. Storage: capture branchStrategy in closures over the three method bodies (cleanest, no public-API change) vs. re-derive from branch-name shape (fragile).
4. Concurrency caveat from README L892 — merge-to-head is not safe for concurrent fan-out because of git merge racing HEAD. Any new merge-from-worktree path inherits that.
5. Re-runs: if the user calls wt.run() twice across the same worktree, the second call may attempt to re-merge already-merged commits. git merge should no-op, but the new test should pin this down.

Possible approach

1. Close over options.branchStrategy inside createWorktree and read it from worktreeRun / worktreeInteractive / worktreeCreateSandbox.
2. When branchStrategy.type === "merge-to-head", pass branch: undefined to orchestrate. The lifecycle then resolves hostCurrentBranch from hostRepoDir and the worktree's branch from the sandbox, exactly like top-level run() does today.
3. Add a keepSourceBranch?: boolean flag (default false) to SandboxLifecycleOptions. When set, skip git checkout --detach (SandboxLifecycle.ts:425) and git branch -D (:465-469). Pass true from the three createWorktree callers — without this, iteration 1 would detach the worktree and delete the branch, breaking iteration 2 and the post-run() worktree contract.
4. Test gap: createWorktree.test.ts describe("worktree.run()", ...) (:585+) covers only { type: "branch" }. Add a { type: "merge-to-head" } test that (a) makes a commit in the agent, (b) asserts host's current branch advanced, (c) asserts the worktree's temp branch still exists for reuse, (d) ideally runs two iterations to catch the detach/delete regression.
5. Docs: README L380-432 should clarify the merge-on-each-wt.run() semantics (assuming approach A).
6. Changeset: patch (bug fix).

Difficulty

Low–moderate. The routing change is small and well-localized. The non-trivial piece is reconciling the existing lifecycle's post-merge cleanup (detach + branch delete, designed for the top-level run() where each iteration gets a fresh worktree) with the createWorktree contract that the worktree's branch must survive. A keepSourceBranch flag is the cleanest path; an alternative would be to refactor the merge step into a smaller helper that both call sites use with different post-merge policies.