Problem
On macOS with Docker Desktop (VirtioFS), bind-mount deployments break silently after
every container restart. All git operations inside the container fail with:
fatal: detected dubious ownership in repository at '/.archon/workspaces/…'
To add an exception for this directory, call:
git config --global --add safe.directory /.archon/workspaces/…
This blocks every Archon workflow that touches a project — including simple chat
messages routed to a codebase — because the Claude subprocess runs git commands
in the workspace directory.
Root Cause
Git 2.35.2+ (CVE-2022-24765) refuses to operate in a directory whose owner differs
from the running user. On macOS bind mounts, the host filesystem UID (typically 501
for the first macOS user account) doesn't translate to the container's appuser UID
(1001 in the Archon image). The chown -Rh appuser:appuser /.archon line in
docker-entrypoint.sh fixes the ownership at startup, but the gitconfig file
that stores safe.directory entries lives at /home/appuser/.gitconfig, which is
not inside the mounted volume. On every container restart that gitconfig is
fresh — all prior safe.directory entries are gone, and the ownership error
reappears.
Named volumes are not affected: Docker copies the image-layer content (including any
RUN git config entries) into the volume on first use, so gitconfig persists.
Bind mounts mount the host directory as-is and no image-layer gitconfig is applied.
Why worktrees are especially hard-hit: The Dockerfile can only register fixed
known paths (e.g. /.archon/workspaces) at build time. Worktrees are created by the
running server under arbitrary subdirectories like
/.archon/workspaces/owner/repo/worktrees/feature-branch/. These deeper paths are
unknown at image-build time and are never in the baked-in gitconfig.
Fix
Dynamically register every repository found under /.archon at container startup,
after the chown block:
# Register all git repositories under /.archon as safe directories for appuser.
# Git 2.35.2+ (CVE-2022-24765) rejects repos where the directory owner differs
# from the running user. On macOS bind mounts (VirtioFS), host-side UIDs (e.g. 501)
# don't map to the container's appuser (1001), so git prints "dubious ownership"
# and refuses all operations. The Dockerfile RUN-layer only registers fixed paths;
# worktrees are nested arbitrarily deep and must be discovered at runtime.
find /.archon -name ".git" 2>/dev/null | while read -r git_dir; do
$RUNNER git config --global --add safe.directory "$(dirname "$git_dir")"
done
This runs on every container start, is idempotent (duplicate safe.directory entries
are harmless), and correctly handles:
- Main source clones under /.archon/workspaces/owner/repo/source/
- Git worktrees at any nesting depth
- The non-root case (--user flag or Kubernetes, where RUNNER="")
▎ Note on safe.directory = *: The wildcard form is supported only in git 2.35.3+
▎ and is not universally available in Docker images. The find-based approach works on
▎ all git versions that have the safe.directory feature.
Reproduction Steps
1. Configure Archon with a bind mount: ARCHON_DATA=/path/on/host
2. Register a project and perform a workflow run (this creates a workspace clone and
possibly a worktree under /.archon/workspaces/).
3. docker compose down && docker compose up -d
4. Send any message that involves the project — Archon will time out or silently fail.
5. docker exec -it archon git -C /.archon/workspaces/owner/repo/source status
→ reproduces the "dubious ownership" error.
Impact
Affects all macOS bind-mount deployments with any registered project, on every
container restart. Named volume deployments on Linux are unaffected.
---
Problem
On macOS with Docker Desktop (VirtioFS), bind-mount deployments break silently after
every container restart. All git operations inside the container fail with:
This blocks every Archon workflow that touches a project — including simple chat
messages routed to a codebase — because the Claude subprocess runs git commands
in the workspace directory.
Root Cause
Git 2.35.2+ (CVE-2022-24765) refuses to operate in a directory whose owner differs
from the running user. On macOS bind mounts, the host filesystem UID (typically 501
for the first macOS user account) doesn't translate to the container's
appuserUID(1001 in the Archon image). The
chown -Rh appuser:appuser /.archonline indocker-entrypoint.shfixes the ownership at startup, but the gitconfig filethat stores
safe.directoryentries lives at/home/appuser/.gitconfig, which isnot inside the mounted volume. On every container restart that gitconfig is
fresh — all prior
safe.directoryentries are gone, and the ownership errorreappears.
Named volumes are not affected: Docker copies the image-layer content (including any
RUN git configentries) into the volume on first use, so gitconfig persists.Bind mounts mount the host directory as-is and no image-layer gitconfig is applied.
Why worktrees are especially hard-hit: The Dockerfile can only register fixed
known paths (e.g.
/.archon/workspaces) at build time. Worktrees are created by therunning server under arbitrary subdirectories like
/.archon/workspaces/owner/repo/worktrees/feature-branch/. These deeper paths areunknown at image-build time and are never in the baked-in gitconfig.
Fix
Dynamically register every repository found under
/.archonat container startup,after the
chownblock: