CPU spins at 100% in Docker container on Colima/virtiofs due to unsupported copy_file_range syscall

Summary

Claude Code becomes unresponsive and consumes 100% CPU when started inside a Docker container running on Colima (macOS Docker alternative using virtiofs).

Environment

• Host OS: macOS (Darwin 24.6.0, Apple Silicon)
• Container Runtime: Colima with Docker
• Mount Type: virtiofs
• Claude Code Version: 2.0.76
• Container OS: Debian-based Linux

Problem

When launching claude inside a Docker container, it immediately spins at 100% CPU and never becomes responsive. The same claude command works perfectly on the host macOS.

Root Cause Analysis

Using strace, I traced the syscalls and found the following:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- -------------------
 47.42    3.102682         836      3711       478 futex
  6.65    0.435271           6     72268           sendfile
  6.42    0.419782           5     72269     72269 copy_file_range

Key finding: copy_file_range is called 72,269 times and fails every single time (72,269 errors).

The virtiofs filesystem used by Colima does not support the copy_file_range syscall. When this syscall fails, Claude Code appears to fall back to sendfile, but something in the retry/fallback logic causes a busy loop, resulting in 100% CPU usage.

Expected Behavior

Claude Code should gracefully handle the ENOSYS or EOPNOTSUPP error from copy_file_range and fall back to alternative file copy methods without spinning.

Steps to Reproduce

1. Set up Colima on macOS with virtiofs mount type:

``bash
colima start --mount-type virtiofs
``

1. Run a Docker container with Claude Code installed and project directory mounted

1. Inside the container, run claude

1. Observe 100% CPU usage and unresponsive CLI

Workaround

Currently, the only workaround is to use Claude Code on the host macOS instead of inside the container.

Additional Context

This issue likely affects any environment where:

• virtiofs is used (Colima, Lima, some QEMU setups)
• copy_file_range syscall is not supported by the filesystem

The fix would involve properly detecting when copy_file_range is unsupported and using a different file copy strategy without entering a retry loop.