FoundationAgents/OpenManus · error · RuntimeError

Failed to verify file creation: {dst_path}

Error message

Failed to verify file creation: {dst_path}

What it means

Raised as RuntimeError by DockerSandbox.copy_to (app/sandbox/core/sandbox.py:370) as a post-write verification failure: the tar was uploaded with put_archive and then `test -e <resolved_dst>` inside the container failed, so the file is not where it was expected. Common root causes: resolved_dst differing from where the tar actually landed (put_archive extracts relative to the parent dir), the uploaded member name not matching resolved_dst's basename, or the file being created then removed by a hook. Note the verification swallows the underlying exception from run_command (e.g. error 25's 'Sandbox not initialized' also surfaces here).

Source

Thrown at app/sandbox/core/sandbox.py:370

                        # Add single file to tar
                        tar.add(src_path, arcname=os.path.basename(dst_path))

                # Read tar file content
                with open(tar_path, "rb") as f:
                    data = f.read()

                # Upload to container
                await asyncio.to_thread(
                    self.container.put_archive,
                    os.path.dirname(resolved_dst) or "/",
                    data,
                )

                # Verify file was created successfully
                try:
                    await self.run_command(f"test -e {resolved_dst}")
                except Exception:
                    raise RuntimeError(f"Failed to verify file creation: {dst_path}")

        except FileNotFoundError:
            raise
        except Exception as e:
            raise RuntimeError(f"Failed to copy file: {e}")

    @staticmethod
    async def _create_tar_stream(name: str, content: bytes) -> io.BytesIO:
        """Creates a tar file stream.

        Args:
            name: Filename.
            content: File content.

        Returns:
            Tar file stream.
        """
        tar_stream = io.BytesIO()

View on GitHub (pinned to 52a13f2a57)

Solutions

1. Make dst_path a clean absolute container path with a real basename: strip trailing '/', avoid '..' (error 32).
2. Ensure the destination directory was actually created (the mkdir -p ran without error) and the mount is rw.
3. After the failure, inspect: run_command(f"ls -la {dirname}") to see what name actually landed.
4. If sandbox terminal was never initialized, fix the lifecycle (error 25) — the verifier depends on run_command.

Example fix

# before
await sandbox.copy_to(host_src, "data/")  # trailing slash -> empty basename

# after
await sandbox.copy_to(host_src, "/workspace/data/input.json")  # clean absolute path with basename

dst = "/" + os.path.normpath(dst_path).lstrip("/")
assert not dst.endswith("/") and ".." not in dst.split("/") and os.path.basename(dst)

try:
    await sandbox.copy_to(src, dst)
except RuntimeError as e:
    if "Failed to verify" in str(e):
        listing = await sandbox.run_command(f"ls -la {os.path.dirname(dst)}")
        log.error("landed files: %s", listing)  # find the real name and fix dst
        raise

When it happens

Trigger: dst_path whose basename differs from the tar member name used for the upload; trailing-slash or normalization differences between resolved_dst and the extracted path; put_archive writing to os.path.dirname(resolved_dst) while test -e checks a symlinked/aliased path; container FS overlay quirks; terminal is None so the verification command itself fails.

Common situations: Copying to a dst that ends with '/' (empty basename in tar); dst inside a read-only mount where extraction silently fails; resolved path going through _safe_resolve_path changing the expectation (relative -> work_dir join) while the caller checks the raw path.

Related errors

• Failed to write file: {e}
• Source file is empty: {src_path}
• Source path is a directory but destination is a file: {src_p
• Failed to extract file: {src_path}
• Source file not found: {src_path}

AI-assisted analysis of FoundationAgents/OpenManus@52a13f2a57 (2026-08-15). Data as JSON: /api/errors/2b146390d236872f. Report an issue: GitHub.