Raw LLM output persisted in error files — PII-bearing prompt context written to disk on step failure

[ooloth]

Why

When an agent step produces unparseable output, the raw LLM text is written to {step}-error.json in .logs/. That text may reproduce fragments of the issue body context injected into the failing prompt — including PII from log-scan analysis such as email addresses or hostnames.

Current state

loops/common/step.py lines 43–50:

error_detail = {"output": exc.output, ...}
write_step(ctx.run_dir, f"{name}-error", error_detail)

exc.output is the unprocessed text returned by the agent before JSON parsing failed, which can include issue body content that was part of the prompt context.

Ideal state

• The error detail file records the step name, error type, and exit code only.
• Raw agent output is not persisted to disk; PII-bearing prompt context cannot accumulate in error files.

Starting points

• loops/common/step.py lines 43–50 — the error_detail dict construction and write_step call

QA plan

1. Trigger a step failure (e.g., by making the agent return non-JSON output) with a known sentinel string in the prompt context.
2. Open the resulting {step}-error.json — confirm the sentinel string does not appear.
3. Confirm the step name, error type, and exit code are still recorded for debugging.

Done when

{step}-error.json contains no raw agent output text — only the step name, error type, and exit code.