deliver: a first push from the sandbox errors and sets no upstream #219

New issue

Closed

opened 2026-11-11 20:53:02 +01:00 by motoko · 0 comments

motoko commented

2026-11-11 20:53:02 +01:00

Collaborator

Defect

A branch's first push from Claude Code's sandbox ends with a git error
and leaves the branch without an upstream, although deliver treats it
as a success to walk past.

Location

.agents/skills/deliver/land.md, first item, "Push a branch the first time with
git push -u <remote> <branch>", as seeded at b04e778.

Evidence

Seen twice on 2026-11-11, in a repository seeded from b04e778, with
git 2.53.0, pushing a new branch from its worktree under .worktrees/:

error: could not lock config file /workspace/.git/config: File exists
error: unable to write upstream branch configuration
hint:
hint: After fixing the error cause you may try to fix up
hint: the remote tracking information by invoking:
hint:   git branch --set-upstream-to=origin/refs/heads/<branch>

The push itself lands: git ls-remote origin refs/heads/<branch>
shows the pushed commit.
git config --local --get-regexp '^branch\.<branch>' prints nothing
afterwards, so the branch has no upstream.
land.md foresees unable to write upstream branch configuration
and says to go on, but names neither the first line, could not lock config file … File exists, nor the missing upstream.
.git/config.lock is on disk as an empty file of mode 0444, and
shows from outside the sandbox too. Whether the sandbox puts it there
on purpose, and whether it outlives the session, was not checked; if
it does, the user's own git config, git push -u and
git branch -u in that checkout fail the same way until it is gone.

Scenario

An agent delivers a branch through a pull request. The push prints two
errors that read as a failure, so the agent has to confirm the push by
other means before going on, and the user who later works in that
worktree finds a branch whose git status and git pull know no
upstream.

Smallest fix

In land.md, push a branch the first time without -u when the
sandbox is on, git push <remote> <branch>, which writes no
configuration and prints no error; the later folds already find the
remote from refs/remotes/*/<branch>, not from the upstream. Then say
that such a branch has no upstream, with the command the user runs
outside the sandbox to set it. Or keep -u and quote both error lines,
so that an agent recognises them.

Worth settling in the same work: whether the leftover
.git/config.lock is the sandbox's own guard, and what the skills
should tell the user when it stays behind.

## Defect A branch's first push from Claude Code's sandbox ends with a git error and leaves the branch without an upstream, although `deliver` treats it as a success to walk past. ## Location `.agents/skills/deliver/land.md`, first item, "Push a branch the first time with `git push -u <remote> <branch>`", as seeded at b04e778. ## Evidence Seen twice on 2026-11-11, in a repository seeded from b04e778, with git 2.53.0, pushing a new branch from its worktree under `.worktrees/`: ``` error: could not lock config file /workspace/.git/config: File exists error: unable to write upstream branch configuration hint: hint: After fixing the error cause you may try to fix up hint: the remote tracking information by invoking: hint: git branch --set-upstream-to=origin/refs/heads/<branch> ``` - The push itself lands: `git ls-remote origin refs/heads/<branch>` shows the pushed commit. - `git config --local --get-regexp '^branch\.<branch>'` prints nothing afterwards, so the branch has no upstream. - `land.md` foresees `unable to write upstream branch configuration` and says to go on, but names neither the first line, `could not lock config file … File exists`, nor the missing upstream. - `.git/config.lock` is on disk as an empty file of mode 0444, and shows from outside the sandbox too. Whether the sandbox puts it there on purpose, and whether it outlives the session, was not checked; if it does, the user's own `git config`, `git push -u` and `git branch -u` in that checkout fail the same way until it is gone. ## Scenario An agent delivers a branch through a pull request. The push prints two errors that read as a failure, so the agent has to confirm the push by other means before going on, and the user who later works in that worktree finds a branch whose `git status` and `git pull` know no upstream. ## Smallest fix In `land.md`, push a branch the first time without `-u` when the sandbox is on, `git push <remote> <branch>`, which writes no configuration and prints no error; the later folds already find the remote from `refs/remotes/*/<branch>`, not from the upstream. Then say that such a branch has no upstream, with the command the user runs outside the sandbox to set it. Or keep `-u` and quote both error lines, so that an agent recognises them. Worth settling in the same work: whether the leftover `.git/config.lock` is the sandbox's own guard, and what the skills should tell the user when it stays behind.

motoko referenced this issue from a commit

2026-11-12 15:28:12 +01:00

fix(deliver): name both first-push errors

motoko referenced this issue from a pull request that will close it,

2026-11-12 15:28:30 +01:00

fix(deliver): name both first-push errors #222