Local-code scans fail on Windows Docker Desktop during sandbox workspace materialization (ExecTransportError / WorkspaceArchiveWriteError)

[rodrmoura]

Environment

• OS: Windows 11 host, Docker Desktop (Linux containers)
• strix-agent: 1.0.4
• openai-agents SDK: 0.14.6 (pinned by strix-agent; see runtime/docker_client.py)
• Python: 3.13
• Sandbox image: ghcr.io/usestrix/strix-sandbox:1.0.0

Summary

Scanning any non-trivial local target hangs the TUI on "Loading..." and then
fails while copying the target into the Docker sandbox (workspace
materialization), before the agent starts. A single-file target succeeds; multi-
file targets fail non-deterministically at a different file and with a
different error each run, which indicates a timing race rather than a bad path
or a size limit.

Observed across three target sizes on the same machine:

• 1 file -> succeeds (agent reaches Calling LLM / turn N).
• ~660 files (clean git export, 4.8 MB) -> fails.
• ~52k files / 840 MB (repo incl. node_modules) -> fails.

Reproduction

1. On a Windows host with Docker Desktop, run a local-code scan of a repo with a
   few hundred+ files: strix --target <repo>.
2. Watch strix_runs/<run>/strix.log: it stops after
   docker_client: Sandbox container created and never logs Caido bootstrap.
3. The run errors after copying begins.

Observed tracebacks (two variants, same run reproduced twice)

Variant A (parallel mkdir path validation):

agents.sandbox.errors.ExecTransportError: exec transport error
  ... base_sandbox_session.py:697 _validate_remote_path_access
  ... artifacts.py:354 _copy_local_dir_file -> session.mkdir(...)

Variant B (per-file archive write), different file, same input on retry:

agents.sandbox.errors.WorkspaceArchiveWriteError: failed to write archive for path: /workspace/<repo>/tests/web
  ... docker.py:732 write -> cp inside container
  ... artifacts.py:355 _copy_local_dir_file -> session.write(...)

Both originate from session.start() -> _start_workspace -> _apply_manifest
-> manifest_application._apply_entry_batch -> artifacts._copy_local_dir_file.

Analysis (strongly indicated, not confirmed by upstream)

Materialization copies LocalDir files concurrently:

• manifest_application._apply_entry_batch gathers with
  max_concurrency = _max_manifest_entry_concurrency (default
  DEFAULT_MAX_MANIFEST_ENTRY_CONCURRENCY = 4).
• artifacts.apply gathers per-file with
  _max_local_dir_file_concurrency (default
  DEFAULT_MAX_LOCAL_DIR_FILE_CONCURRENCY = 4).

Under this concurrency the first batch of workers each call
_ensure_runtime_helper_installed(RESOLVE_WORKSPACE_PATH_HELPER) and then
self.exec(helper ...). _validate_remote_path_access raises
ExecTransportError specifically when the helper exec returns OK but empty
stdout -- consistent with a race installing/reading the helper before it is
fully written. On Windows Docker Desktop docker exec is comparatively slow,
which widens the race window; on a native Linux daemon it is not observed.

The non-determinism (different failing file and different error type per run) is
the key signal that this is concurrency/transport-timing, not a deterministic
path/size bug.

Suggested fixes

1. Install/warm the runtime helper (RESOLVE_WORKSPACE_PATH_HELPER) once,
   serially, before starting the parallel materialization batch.
2. Make it robust to a transient empty/failed exec with a bounded retry, as
   caido_bootstrap._login_as_guest already does for its readiness probe.
3. Expose SandboxConcurrencyLimits (manifest_entries / local_dir_files) through
   the Strix runtime backend (strix/runtime/backends.py::_docker_backend passes
   none today) or an env var, so operators on slower daemons can serialize.

Workaround

Run the strix CLI inside WSL2 (WSL-integrated Linux Docker CLI path), where
docker exec is fast. On our Windows 11 host 2026-07-04, two WSL2 --clean
multi-file scans materialized cleanly (Sandbox ready then normal agent turns, no
ExecTransportError / WorkspaceArchiveWriteError) -- supporting WSL2 as a
workaround for the Windows Docker Desktop materialization failures seen on earlier
multi-file local scans. Also export only tracked files (git archive HEAD) to
avoid copying node_modules.