Bound command output before it reaches the agent

Define the output you need

Before executing a noisy command, decide which result the agent actually needs: a pass or fail status, a few diagnostic lines, a structured summary or a generated artifact. Dumping a complete dependency installation or build log into the model is rarely the best evidence. Lupin returns stdout and stderr from synchronous commands, but the current public contract does not specify a universal truncation behavior across provider output. Bound output at the workload level rather than assuming the API will select the useful portion. A small deliberate summary is easier to inspect and less likely to disclose unrelated information.

Preserve failure status while reducing logs

Redirect verbose streams to named files and capture the command's actual exit status before printing a summary. A shell pipeline can otherwise report the status of its last utility instead of the program that failed. Use shell features only after confirming the environment supports them; an explicit script that stores and returns the relevant status is often clearer. Keep stdout and stderr separate when their meaning matters. A warning on stderr can coexist with success, and a friendly line on stdout can coexist with failure. The summary should carry both the outcome and enough context to explain it.

Choose focused diagnostic windows

For a compiler failure, the first relevant error and nearby context may be more useful than thousands of repeated lines. For a data conversion, print input count, output count and validation failures rather than every record. For a long-running process, write timestamped health information to a file and read a bounded tail only when needed. Do not assume that a final log line proves the whole job completed. Pair the diagnostic window with an explicit completion marker or artifact check. When full logs are necessary, retain them in an approved artifact location rather than repeatedly returning them to every agent step.

{
  "command": "python -c 'import os; print({\"cwd\": os.getcwd()})'",
  "timeout_seconds": 30
}

Keep the transfer and privacy limits visible

The container file route uses base64 transport with a roughly two-megabyte limit, so a large log may not be downloadable through that interface. Plan a suitable approved storage path or reduce the log at its source. Logs can include secrets, private paths, request bodies and dependency credentials. Avoid printing environment variables or verbose authentication traffic as a routine diagnostic. Command history can retain command strings even when you did not preserve the original response, so putting a secret directly in the command creates another exposure path. Redact before retaining a diagnostic excerpt for the task record.

Verify the final artifact separately

A concise output summary should not hide whether the requested artifact exists and is valid. Check its format, relevant content and expected size using a bounded verification step. Save the actual artifact and the sanitized diagnostic result outside the resource before stopping it. If a command response was lost, reconcile history and files rather than claiming that the output was inspected. Record exactly which checks ran. Good output control makes evidence smaller while preserving meaning; it does not replace process status, semantic validation or honest reporting of an uncertain execution outcome.

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 · command-history ↗Checked 2026-11-05

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