fix(skills): work past the read-only git config #210

Merged

claudiomaradonna merged 3 commits from fix/git-config-readonly into main 2026-11-10 15:24:28 +01:00

Conversation 0 Commits 3 Files changed 5 +124 -13

motoko commented 2026-11-10 15:14:20 +01:00

Collaborator

Copy link

Why

Claude Code keeps a repository's .git/config read-only inside its
sandbox, which the source's settings turn on, and no project setting
opens it. Since adb02f0 moved git push inside the sandbox, an agent's
first push of a branch lands without recording an upstream, and
deliver then finds no remote for the branch's later folds. In a
freshly adopted repository, the first worktree open-worktree opens
fails on the same lock and leaves its branch behind, so the same command
run again outside the sandbox fails too. The README named neither case.

Set aside: dropping -u, which loses the upstream outside the sandbox
as well; and excluding the push or the worktree command from the
sandbox, which gives each full access and a prompt again.

What changed

A fold of a pushed branch now goes to the remote its remote-tracking ref
names, which the sandbox lets the push write. The first push keeps -u,
and deliver says to go on after its upstream error. When several
remotes hold the branch, the agent asks which.

A repository's first worktree that fails on the config's lock is run
again outside the sandbox, a change's on the branch the failed attempt
left. This happens once in a repository and may prompt once.

The README names writes to .git/config and .git/hooks among what
falls to a retry outside the sandbox, with the two messages git prints
and the way on for an unrecorded upstream and for the section a deleted
branch leaves.

How to verify

1. Run bash tests/agent-config/real-source.sh: all 6 tests pass. With
   the same file copied over main's, the two new tests fail, the first
   with git config branch.<branch>.remote names '' and the second with
   the worktree on ''.
2. In a Claude Code session under the source's settings, push a new
   branch with git push -u origin <branch>: it exits 0 after
   error: unable to write upstream branch configuration. Then
   git for-each-ref --format='%(refname:lstrip=2)' 'refs/remotes/*/<branch>'
   prints origin/<branch>. This branch's own push went that way.

Checks run on the tip: bash tests/verify-agent-config.sh, with all 245
tests passing, .agents/hooks/shellcheck.sh repo,
prettier --check '**/*.md', scripts/verify-agent-config.sh, and
git diff --check main. Not tried: a first worktree in a real sandboxed
session, since this source already holds the setting it writes, so the
tests simulate the lock with a .git/config.lock; and macOS.

Considerations

Two low findings of the documentation review's second round are set
aside, as later-round low findings are: the README gives the worktree's
retry as "without -b" and leaves the start point to open-worktree,
and its retry paragraph grew denser.

## Why Claude Code keeps a repository's `.git/config` read-only inside its sandbox, which the source's settings turn on, and no project setting opens it. Since adb02f0 moved `git push` inside the sandbox, an agent's first push of a branch lands without recording an upstream, and `deliver` then finds no remote for the branch's later folds. In a freshly adopted repository, the first worktree `open-worktree` opens fails on the same lock and leaves its branch behind, so the same command run again outside the sandbox fails too. The README named neither case. Set aside: dropping `-u`, which loses the upstream outside the sandbox as well; and excluding the push or the worktree command from the sandbox, which gives each full access and a prompt again. ## What changed A fold of a pushed branch now goes to the remote its remote-tracking ref names, which the sandbox lets the push write. The first push keeps `-u`, and `deliver` says to go on after its upstream error. When several remotes hold the branch, the agent asks which. A repository's first worktree that fails on the config's lock is run again outside the sandbox, a change's on the branch the failed attempt left. This happens once in a repository and may prompt once. The README names writes to `.git/config` and `.git/hooks` among what falls to a retry outside the sandbox, with the two messages git prints and the way on for an unrecorded upstream and for the section a deleted branch leaves. ## How to verify 1. Run `bash tests/agent-config/real-source.sh`: all 6 tests pass. With the same file copied over `main`'s, the two new tests fail, the first with `git config branch.<branch>.remote names ''` and the second with the worktree on `''`. 2. In a Claude Code session under the source's settings, push a new branch with `git push -u origin <branch>`: it exits 0 after `error: unable to write upstream branch configuration`. Then `git for-each-ref --format='%(refname:lstrip=2)' 'refs/remotes/*/<branch>'` prints `origin/<branch>`. This branch's own push went that way. Checks run on the tip: `bash tests/verify-agent-config.sh`, with all 245 tests passing, `.agents/hooks/shellcheck.sh repo`, `prettier --check '**/*.md'`, `scripts/verify-agent-config.sh`, and `git diff --check main`. Not tried: a first worktree in a real sandboxed session, since this source already holds the setting it writes, so the tests simulate the lock with a `.git/config.lock`; and macOS. ## Considerations Two low findings of the documentation review's second round are set aside, as later-round low findings are: the README gives the worktree's retry as "without `-b`" and leaves the start point to `open-worktree`, and its retry paragraph grew denser.

motoko added 3 commits 2026-11-10 15:14:26 +01:00

fix(skills): find a fold's remote without config ... e2e3b08b62

Claude Code's sandbox keeps .git/config read-only, so the first push's
-u lands the branch and records no upstream, and the later fold push
found no remote in the config. The remote-tracking ref, which the
sandbox lets the push write, names it instead; -u stays for the
upstream it records where the config is writable.

fix(skills): open a first worktree past the lock ... 8ce1791640

Claude Code's sandbox keeps .git/config read-only, so a repository's
first worktree with relative links, which writes the extension there,
fails and leaves its branch, and the same command run again outside the
sandbox then fails on that branch. The skill now gives the command that
opens the worktree on the branch left.

docs: name git's config writes under the sandbox ... e20f9e92f4

Claude Code keeps .git/config read-only inside its sandbox, which the
README's list of what falls to a retry left out, as it did the two git
commands that pass there without writing it. The open-worktree page
says where a first worktree may ask.

claudiomaradonna merged commit e20f9e92f4 into main 2026-11-10 15:24:28 +01:00

claudiomaradonna deleted branch fix/git-config-readonly 2026-11-10 15:24:31 +01:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

claudiomaradonna/agent-foundry!210

No description provided.