fix(code-execution): always send remote-write payloads as stdin_data

_remote_write branched on getattr(env, "_stdin_mode", "pipe") and only
passed stdin_data on pipe backends, echoing base64 into argv elsewhere.
BaseEnvironment.execute already embeds stdin_data as a heredoc for
heredoc-mode backends (modal/daytona/vercel), and managed_modal forwards
it as stdinData; _write_to_sandbox already relies on that for every
backend. The branch duplicated base-class logic, and its defensive
getattr default meant a fake env with neither _stdin_mode nor a
stdin_data parameter raised TypeError on every RPC response write. The
poll loop swallowed the error, so no res_* file appeared and
test_code_execution_file_rpc hung forever (it passes on base).

Collapse to one path that always passes stdin_data, and teach the
file-RPC Shell fake to accept it and feed it as input. ScriptedEnv no
longer needs its _stdin_mode stub.

tools/code_execution_rpc.py

@@ -40,34 +40,23 @@ def _private_dirs_cmd(mkdir_dirs, chmod_dirs) -> str:
     return f"umask 077 && mkdir -p {mkdir} && chmod 700 {chmod}"
 
 
-def _remote_write_cmd(env, remote_path: str, content: str, *, atomic: bool = False) -> tuple:
-    """Build ``(command, stdin_data)`` writing *content* owner-only to *remote_path*.
+def _remote_write(env, remote_path: str, content: str, *, atomic: bool = False,
+                  timeout: int = 30):
+    """Write *content* owner-only to *remote_path*; returns the execute() result.
 
-    Payload transport follows the backend's stdin capability: ``pipe`` mode
-    (ssh, docker, local, singularity — the real shared-host backends) gets the
-    base64 via real stdin so the content never enters argv, where a co-tenant
-    can read it via ``/proc/*/cmdline`` for the command's lifetime.
-    ``heredoc``/``payload`` modes (modal, daytona, vercel, managed_modal —
-    isolated sandboxes where Modal-family stdin delivery is also unreliable)
-    keep the base64 echo form: the argv window there is one short write rather
-    than the whole run."""
+    The base64 payload always travels as ``stdin_data``: pipe-mode backends
+    (ssh, docker, local, singularity: the real shared-host ones) deliver it on
+    real stdin, so it never enters argv where a co-tenant can read it via
+    ``/proc/*/cmdline``; ``BaseEnvironment.execute`` embeds it as a heredoc
+    for heredoc-mode backends (modal, daytona, vercel), and managed_modal
+    forwards it as ``stdinData``, the same contract ``_write_to_sandbox``
+    relies on."""
     encoded = base64.b64encode(content.encode("utf-8")).decode("ascii")
     target = shlex.quote(remote_path)
     write = (f"base64 -d > {target}.tmp && mv -f {target}.tmp {target}"
              if atomic else f"base64 -d > {target}")
-    if getattr(env, "_stdin_mode", "pipe") == "pipe":
-        return f"umask 077 && {write}", encoded
-    return f"umask 077 && echo '{encoded}' | {write}", None
-
-
-def _remote_write(env, remote_path: str, content: str, *, atomic: bool = False,
-                  timeout: int = 30):
-    """Execute an owner-only remote write; returns the execute() result."""
-    cmd, stdin_data = _remote_write_cmd(env, remote_path, content, atomic=atomic)
-    kwargs = {"cwd": "/", "timeout": timeout}
-    if stdin_data is not None:
-        kwargs["stdin_data"] = stdin_data
-    return env.execute(cmd, **kwargs)
+    return env.execute(f"umask 077 && {write}", cwd="/", timeout=timeout,
+                       stdin_data=encoded)
 
 
 def _rpc_token_ok(request: dict, rpc_token: str) -> bool:

tools/code_execution_tool.py

@@ -453,9 +453,8 @@ def _get_or_create_env(task_id: str):
 
 
 def _ship_file_to_remote(env, remote_path: str, content: str) -> None:
-    """Write *content* owner-only to *remote_path*. stdin-capable backends carry
-    the payload on stdin so it never appears in remote argv; the rest get the
-    base64 echo form (see _remote_write_cmd). Raises on write failure: the
+    """Write *content* owner-only to *remote_path*; the payload rides
+    ``stdin_data``, never an ``echo`` argv (see _remote_write). Raises on write failure: the
     caller ships secrets and code into dirs it believes are locked down, so a
     silent failure would run the next step against a missing or half-written
     file."""