Control subprocesses and network effects in sandbox jobs

Isolation does not remove external effects

A program running in an isolated sandbox can still make network requests when the environment allows them. Fetching a public dependency, submitting a record and sending an email have very different effects even if all are initiated by a shell command. Define the allowed destinations and operations before execution. Lupin's public container API does not expose a general egress-policy configuration, so do not claim the workload is network-restricted merely because it is hosted. Keep command authority aligned with the user's task and use application-level controls for operations that reach external systems.

Use structured subprocess arguments where possible

Inside your own script, invoke subprocesses with explicit argument arrays rather than building a shell command from untrusted text. Shell syntax is useful when deliberately needed, but it also interprets metacharacters, substitutions and redirections. A filename or source-page string should not become executable syntax. Set the subprocess working directory and environment explicitly when the program supports that control. The top-level Lupin run endpoint still accepts a command string, so quote that boundary carefully and prefer executing a reviewed script over repeatedly assembling complex inline commands in agent prompts.

Bound child work as well as parent work

A timeout on the parent command is not a universal guarantee that every descendant process or remote request stopped. Use a process-management approach appropriate to the runtime, keep process identifiers or job state where necessary and design a shutdown path. The Boat adapter bounds command timeouts and provider request waiting independently, which can leave an unknown outcome after a client disconnect. A backgrounded child may continue even if the synchronous request returned. Inspect actual process and artifact state before launching a replacement, especially if the work can create external side effects.

import subprocess
result = subprocess.run(
    ["python", "-c", "print(1 + 1)"],
    capture_output=True, text=True, timeout=10, check=False,
)
print(result.returncode, result.stdout, result.stderr)

Make network retries intentional

Give outbound operations their own timeouts and retry rules. A safe retry for reading an immutable public file is different from repeating a payment, message or database mutation. Use the external service's idempotency mechanism when it exists and the user authorized the operation. Do not rely on Lupin's command idempotency to deduplicate every HTTP request a script might make internally. It guards command acceptance at the API boundary; your program remains responsible for its own side-effect protocol. Log sanitized destination and outcome information rather than request bodies containing credentials or personal data.

Verify and clean up the whole workload

After the main command finishes, check whether child processes remain, whether files are complete and whether external operations have a known outcome. Save the relevant artifact and diagnostic summary, then stop unneeded services and the sandbox. A public preview port creates an additional reachable surface and needs authentication before private data is served. If a network or process outcome is uncertain, report that boundary precisely instead of calling the entire task failed or successful. This makes the next authorized attempt a controlled recovery step, with evidence about which work already happened and which effects still need reconciliation.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

• docs.python.org · 3 · library · subprocess.html ↗Checked 2026-11-05
• docs.boat.dev · long-running-tasks · background-commands ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.