Docker Sandbox file sync corrupts git index, causing git segfault

[OneRedOak]

Bug report

When using Docker Sandboxes with Claude Code, the file sync mechanism corrupted my git repository's index file, causing git status to segfault.

Environment:

• macOS (Sequoia 15.7.3)
• Docker Desktop version: 29.1.5, build 0e6fee6
• Sandbox template: claude-code (https://docs.docker.com/ai/sandboxes/)

Steps to reproduce:

1. Set up ANTHROPIC_API_KEY in ~/.zshrc and restart Docker Desktop
2. Create a sandbox for an existing git repository:
   docker sandbox run claude ~/Engineering/dashboard
3. Work in the sandbox (or even just start it)
4. Attempt to run git status on the host machine in the same directory

Expected behavior: git status should work normally on the host, showing any changes made by the sandbox agent.

Actual behavior:

git status
[1]    89564 segmentation fault  git status

• git log still works (object database intact)
• git status crashes with segfault
• GitHub Desktop also fails with: Command failed: git --no-optional-locks status --untracked-files=all --branch --porcelain=2 -z

Workaround: Removing and rebuilding the git index fixes the issue:

rm .git/index
git reset

Analysis: The git index (.git/index) is a binary file that tracks working directory state. The bidirectional file sync between host and sandbox VM likely caused:

• A race condition with concurrent writes
• A partial/interrupted write during sync
• Metadata inconsistency that crashes git when stat'ing files

Additional notes:

• Also encountered sync credentials: sync credentials failed: status 404: {"message":"Not Found"} errors during sandbox creation (unrelated, caused by no Anthropic API key present, but worth noting)
• The sandbox otherwise created and ran successfully

Platform

macOS

Version information

Client:
 Version:           29.1.5
 API version:       1.52
 Go version:        go1.25.6
 Git commit:        0e6fee6
 Built:             Fri Jan 16 12:47:44 2026
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.58.1 (217134)
 Engine:
  Version:          29.1.5
  API version:      1.52 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       3b01d64
  Built:            Fri Jan 16 12:48:37 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Client:
 Version:    29.1.5
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.17.1
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.30.1-desktop.2
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.1
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.2.0
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-desktop
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.35.0
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-mcp
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.0.7
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-model
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.41
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-offload
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.0.22
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-pass
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.10.1
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-sandbox
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.19.0
    Path:     /Users/patrickellis/.docker/cli-plugins/docker-scout

Server:
 Containers: 20
  Running: 14
  Paused: 0
  Stopped: 6
 Images: 81
 Server Version: 29.1.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.65-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 6.277GiB
 Name: docker-desktop
 ID: 82a7e331-89e9-48c7-8cbd-f2abf5421d64
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/patrickellis/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Diagnostics ID

FFB2FD8B-A6F1-4D3F-AE7A-869B1E80809F/20260203024616

[jnehlmeier]

Yeah that is pretty annoying. Especially if using something like Gradle build tool and a plugin that reads the current build version from GIT whenever you use Gradle. Basically unusable then, because Gradle fails with an error saying that some files are corrupt.

I assume that source code files created by the agent can become broken as well.

[mimakaev]

I'm having random corruption issues with large file operations inside claude sandbox too. Like files working normally and getting truncated just a secon dlater.

[anton-matosov]

I'm see the same issue with Docker Desktop 4.63.0 on macOS.

docker sandbox run shell . 
curl -Lk 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-arm64' --output vscode_cli-sandbox.tar.gz
tar -xf vscode_cli-sandbox.tar.gz

file is corrupted in 100% of cases. doing the same operation from /home/agent/ works just fine. This is obviously a hypervisor file sync corruption issue

[jaskaransinghdr6j]

Can we have an update on this? We're facing the same issue.

[ruohola]

In regular day to day work, Docker Sandboxes are almost unusable inside git repos as the .git directory (especially the index file) gets corrupted extremely easily when the filesystem sync seemingly isn't atomic enough and cannot keep up.

Facing corruption doesn't even require concurrent git access from both the sandbox and host. Just running this type of a demo script in a single shell in a git repo directory within a sandbox that is mounted on the host:

touch foo.txt
while true; do git add . ; git restore --staged . ; done

will within seconds start throwing errors:

fatal: index file corrupt
error: bad signature 0x00000000
fatal: index file corrupt
error: bad signature 0x00000000

or

fatal: .git/index: index file smaller than expected
fatal: .git/index: index file smaller than expected

Similarly, I've seen .git/refs/ corruption, but haven't reproduced that consistently.

My current workaround is to have this in my template Dockerfile:

# Keep a separate Git index to prevent corruption from host-VM
# filesystem mount not syncing writes reliably.
# (Staged changes won't get synced between the sandbox and host.)
RUN mv /usr/bin/git /usr/bin/git.real
COPY git-sandbox-index /usr/bin/git

git-sandbox-index:

#!/bin/bash

# Offloads the .git/index file to a tempdir, which is never mounted on the host filesystem.

global_args=()
cmd=''
value_for_global_flag=false

for arg in "$@"; do
    if "$value_for_global_flag"; then
        value_for_global_flag=false
        if [ -z "$cmd" ]; then
            global_args+=("$arg")
        fi
        continue
    fi

    case "$arg" in
        -C|--git-dir|--work-tree|--namespace)
            value_for_global_flag=true
            ;;
    esac

    if [[ -z "$cmd" && "$arg" =~ ^[a-z]([a-z-]*[a-z])?$ ]]; then
        cmd="$arg"
    elif [ "$cmd" = 'worktree' ]; then
        cmd="worktree $arg"
    elif [ -z "$cmd" ]; then
        global_args+=("$arg")
    fi
done

creates_tree=false
case "$cmd" in
    clone|init|init-db|'worktree add')
        creates_tree=true
        ;;
esac

if "$creates_tree"; then
    # Protects child processes from inheriting an incorrect location.
    unset GIT_INDEX_FILE
else
    git_dir_path="$(/usr/bin/git.real "${global_args[@]}" rev-parse --absolute-git-dir 2> /dev/null)"

    if [ -n "$git_dir_path" ]; then
        mkdir -p "/var/tmp${git_dir_path}"
        export GIT_INDEX_FILE="/var/tmp${git_dir_path}/index"

        if [ ! -f "$GIT_INDEX_FILE" ]; then
            /usr/bin/git.real "${global_args[@]}" read-tree HEAD 2> /dev/null
        fi
    fi
fi

exec /usr/bin/git.real "$@"

Also, I call git reset in my launch script to recreate the sandboxed index to match the working tree whenever a Claude session boots up, as otherwise the git status could look very confusing:

docker sandbox run "$name" -- -c 'git reset > /dev/null 2>&1 && exec claude --dangerously-skip-permissions "$@"' _ "$@"

---

Have not yet faced any .git dir corruption when running this. Safe to say that I don't like the hackiness of this workaround, and I'd love to see a better syncing/mounting solution be implemented.

[widdowson]

in the time it has taken docker not to prioritize engineering a solution for this, I have both migrated on to docker desktop and migrated off into a custom-built multi-agent container-based solution. I'm shocked that such a primary use case suggested by docker desktop is completely broken. for such a long amount of time. I will not be returning to docker desktop because the signal I am getting is that it is simply not a serious product.

…

On Thu, Apr 2, 2026, 12:33 PM Eero Ruohola ***@***.***> wrote: *ruohola* left a comment (docker/desktop-feedback#62) <#62 (comment)> In regular day to day work, Docker Sandboxes are almost unusable inside git repos as the .git directory (especially the index file) gets corrupted extremely easily when the filesystem sync seemingly isn't atomic enough and cannot keep up. Facing corruption doesn't even require concurrent git access from both the sandbox and host. Just running this type of a demo script in a single shell in a git repo directory within a sandbox that is mounted on the host: touch foo.txtwhile true; do git add . ; git restore --staged . ; done will within seconds start throwing errors: fatal: index file corrupt error: bad signature 0x00000000 fatal: index file corrupt error: bad signature 0x00000000 or fatal: .git/index: index file smaller than expected fatal: .git/index: index file smaller than expected Similarly, I've seen .git/refs/ corruption, but haven't reproduced that consistently. *My current workaround is to have this in my template Dockerfile*: # Keep a separate Git index to prevent corruption from host-VM# filesystem mount not syncing writes reliably.# (Staged changes won't get synced between the sandbox and host.)RUN mv /usr/bin/git /usr/bin/git.realCOPY git-sandbox-index /usr/bin/git git-sandbox-index: #!/bin/bash # Offloads the .git/index file to a tempdir, which is never mounted on the host filesystem. global_args=() cmd='' value_for_global_flag=false for arg in "$@"; do if "$value_for_global_flag"; then value_for_global_flag=false if [ -z "$cmd" ]; then global_args+=("$arg") fi continue fi case "$arg" in -C|--git-dir|--work-tree|--namespace) value_for_global_flag=true ;; esac if [[ -z "$cmd" && "$arg" =~ ^[a-z]([a-z-]*[a-z])?$ ]]; then cmd="$arg" elif [ "$cmd" = 'worktree' ]; then cmd="worktree $arg" elif [ -z "$cmd" ]; then global_args+=("$arg") fidone creates_tree=falsecase "$cmd" in clone|init|init-db|'worktree add') creates_tree=true ;;esac if "$creates_tree"; then # Protects child processes from inheriting an incorrect location. unset GIT_INDEX_FILEelse git_dir_path="$(/usr/bin/git.real "${global_args[@]}" rev-parse --absolute-git-dir 2> /dev/null)" if [ -n "$git_dir_path" ]; then mkdir -p "/var/tmp${git_dir_path}" export GIT_INDEX_FILE="/var/tmp${git_dir_path}/index" if [ ! -f "$GIT_INDEX_FILE" ]; then /usr/bin/git.real "${global_args[@]}" read-tree HEAD 2> /dev/null fi fifi exec /usr/bin/git.real "$@" Also, I call git reset in my launch script to recreate the sandboxed index to match the working tree whenever a Claude session boots up, as otherwise the git status could look very confusing: docker sandbox run "$name" -- -c 'git reset > /dev/null 2>&1 && exec claude --dangerously-skip-permissions "$@"' _ "$@" ------------------------------ Have not yet faced any .git dir corruption when running this. Safe to say that I don't like the hackiness of this workaround, and I'd love to see a better syncing/mounting solution be implemented. — Reply to this email directly, view it on GitHub <#62?email_source=notifications&email_token=ABMG7SHADISPM66BQRNRMLD4T2W7JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJXHE3TAMZWG42KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4179703674>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMG7SHJL6JODTOQ4KE3FFT4T2W7JAVCNFSM6AAAAACTYLYVFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNZZG4YDGNRXGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jnehlmeier]

Given that Codex and Claude have OS-level sandbox support there isn't a compelling reason using broken docker sandbox with them. Except maybe if your agent needs docker access or you want to use an agent harness without proper sandboxing support. But at least for docker access you could also just run a second docker in a self-managed VM and tell the agent to use docker --context agent-docker <cmd>

Or go a step further and use coder and let it create agent workspaces based on your own terraform templates.

[imunis-kev]

The corruption issues here are really problematic, this should be getting a higher priority.

We added a CSS file pulled from a CDN (for self hosting) which Claude downloaded via wget. Given that it was a minified file, it wasn't obvious to spot that chunks of the file were blanked out.

Random silent file corruption isn't really something you expect to watch out for.

[bsousaa]

We released Docker Sandbox as a separate binary. You can read more at https://www.docker.com/products/docker-sandboxes/ and https://docs.docker.com/ai/sandboxes.

Please give it a try on the latest sbx release and report any issue in the dedicated tracker https://github.com/docker/sbx-releases/issues