code executors: collect() corrupts binary output files by decoding with replacement

[quan020406]

What version of tRPC-Agent-Python are you using?

Current main branch.

Repository code search confirmed this on commit 735721732eab81b089e9fa25234f3d2798a4d365.

What operating system and Python version are you using?

OS: Windows 11
Python: not version-specific; this is about binary output materialization in the shared code executor file collection path.

What did you do?

I reviewed the workspace output collection path for code executors and noticed that binary files collected through collect() are materialized as CodeFile.content: str.

The shared implementation currently decodes every collected file as UTF-8 with replacement:

content=data.decode("utf-8", errors="replace")

Code location:

• trpc_agent_sdk/code_executors/_base_workspace_runtime.py
• BaseWorkspaceFS._build_code_files()

The repository already contains an xfail regression probe for this behavior:

• tests/code_executors/cube/test_bug_hunt.py
• test_bug9_collect_preserves_binary_bytes

What did you expect to see?

Collecting a binary output file should not silently corrupt the bytes.

Possible acceptable behaviors could include preserving binary content through bytes/base64, exposing binary files only through artifact references, rejecting inline binary collection with a clear error, or documenting/enforcing that collect() is text-only.

What did you see instead?

collect() decodes raw bytes with errors="replace".

For non-UTF-8 bytes, Python inserts U+FFFD replacement characters. Re-encoding the returned string no longer produces the original bytes, so downstream consumers cannot recover the file.

This can affect generated images, PDFs, archives, model artifacts, and other binary outputs from code executor workspaces.

Duplicate check

Before opening this issue, I searched repository issues and PRs for:

• collect() binary errors="replace"
• CodeFile.content binary
• binary output collect code executor
• replacement decoded binary output

I did not find an existing public issue or PR covering this specific problem.

Suggested next step

If maintainers agree this is a bug, I would like to work on a small PR that makes binary output handling explicit while keeping existing text-file behavior unchanged.