# remediation agent crashed editing minified bundle output - how to fix it

## TL;DR

Never patch build output: the agent should map the violation back to source files and patch those, then rebuild. Minified bundles are single-line megabyte files that crash editors and get overwritten on the next build anyway. One line of why: the bundle is a render artifact, and patching artifacts is work that evaporates.

## The error, verbatim

```text
RemediationAgentError: crashed editing bundle output
    file: dist/assets/index-abc123.js (1.8MB, 3 lines)
    cause: editor OOM on single-line file

```

## Fix it step by step

### Step 1: Reproduce the crash

```bash
node agent/remediate.js | rg -i 'crash|bundle|OOM' | head -5
```

Expected: The agent tries to edit the minified bundle and dies.

### Step 2: Map bundle to source

```bash
rg -n 'sourcemap|sources' dist/assets/index-abc123.js.map | head -3; ls src/ | head -10
```

Expected: Source maps or the src tree show where the code really lives.

### Step 3: Restrict the agent to source

```bash
rg -n 'dist/|bundle' agent/remediate.js | head -10
```

Expected: Add: exclude dist, build, and minified files from patch targets; resolve to source first.

### Step 4: Re-run remediation

```bash
node agent/remediate.js | tail -4
```

Expected: Agent patches source files and the rebuild carries the fix into the bundle.

### Step 5: Add a regression probe

```bash
node agent/run-audit.js --smoke | tail -3
```

Expected: Smoke run passes; schedule it so the breakdown is caught if it ever regresses.

## When to use this skill

- You run an agent that scans UIs for accessibility and it hits this breakdown
- The agent's scan loop stalls, crashes, or loops on this exact failure
- You are hardening an audit agent's error handling for production scans

## When NOT to use this skill

- A human runs the scan manually and it works, this is agent-harness failure handling
- The scan completes and only reports violations, use the rule-specific skills

## Compatibility

Remediation agent with source-map aware file targeting. The build step regenerates the bundle. Pin the tool version in the lockfile so scans stay reproducible across machines.

## Variant phrasings

### agent editing minified js crash

Same crash, same source-only rule.

### remediation patch dist folder

Practitioner phrasing for the anti-pattern.

### the breakdown hits other routes too

Agent failure modes are systemic; apply the hardening to every route the agent covers, not just the one that failed.

## Why it happens

Agents locate violations in the served page and trace them to files, and the served files are often minified bundles. Editing a 2MB single-line file crashes most editor tooling, and even a successful edit is wiped by the next build. The correct pipeline is violation to source via source maps or component tracing, patch the source, rebuild, re-scan. Agents need an explicit rule: never write to dist, build, or *.min.* files. Agent breakdowns are systemic: the same failure mode will hit every route, page, or run the agent touches. Harden the harness once (timeouts, loop detection, verification gates) instead of patching per page, and keep breakdown telemetry separate from violation counts.

## Edge cases

- Keep source maps available in the agent's environment, without them the bundle-to-source mapping is guesswork.
- Generated files (GraphQL codegen, protobuf stubs) are also patch-the-source territory.
- If the violation is in third-party bundle code, the fix is a version bump or a vendor ticket.
- Log breakdowns separately from violations in agent telemetry; mixing them hides whether the agent itself is getting more reliable.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HYjdqpba2ukp95Kul059EA