## TL;DR
Shared output paths plus parallel execution guarantee corruption: two scanners write the same file, the last finisher wins, and the other's results vanish or interleave into nonsense. Namespace every run's outputs by engagement, tool, target, and run id, write to a temporary name and rename on completion, and have importers read only from the run's own directory.

```text
agent's concurrent scans overwrote each other's output files
```

## Use this when
- Results for one authorized target contain another target's data, or a completed scan's output is missing after a parallel run.
- The run log shows two tool invocations given the identical output path.

## Not for this skill when
- The output is a shared database the tool itself manages with locking, such as a Burp project used by one instance. The rule targets plain files written by concurrent processes.
- A single scan was rerun and overwrote its own earlier output on purpose. That is a versioning question, covered by batch handling.

## Steps
1. Inspect the run configuration and list every output path the parallel workers receive, marking the ones that are identical across workers. Verify: Verify: the collisions are enumerated, not suspected.
2. Define the output layout: a directory per run batch, with files named for tool, target, and run id, created by the runner, never by a default in a shared working directory. Verify: Verify: two simultaneous runs cannot produce the same path by construction.
3. Change tools to write to a temporary filename inside their run directory and rename to the final name only on successful completion. Verify: Verify: a killed run leaves a clearly temporary file and no half-written final file.
4. Point each importer at its own run's directory and have it verify that the file's recorded target matches the target it is importing for. Verify: Verify: a deliberately misplaced file is rejected with a target mismatch error.
5. Run a parallel smoke test over two authorized lab targets and reconcile both result sets against sequential reference runs. Verify: Verify: parallel and sequential results agree, and both files survive intact.

## Variant phrasings
### parallel scans same output file overwrite agent
The symptom phrasing.
### per run output directory namespace tool target run id
The layout phrasing.
### write temp file rename atomic scanner output
The atomic-write phrasing.

Compatibility: Compatibility: any agent harness running tools concurrently; run ids can be timestamps plus a short random suffix generated by the runner.

## Why it happens
Tools assume they own their output file; schedulers that parallelise without rethinking paths break that assumption invisibly, because the surviving file is valid output, just for the wrong target or only half the targets. The failure looks like missing findings or odd cross-target data, far from its cause, which is why the fix is structural namespacing rather than retries.

## Edge cases / pitfalls
- Shared summary files appended by many workers need the same treatment: per-worker parts merged later, never concurrent appends to one report file.
- Disk quotas bite faster with per-run directories; add retention that archives superseded runs instead of letting operators delete at random.
- Timestamps alone collide when runs start in the same second; include the run id, not just the time.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_se8JLoxiV-6cIOHEQdIYHA