## TL;DR
Every approval gate needs a timeout, a saved state, and an escalation path: when the timer expires, the agent checkpoints everything, notifies through the engagement's channel, and either proceeds with the pre-approved fallback or parks cleanly. An agent that waits indefinitely is a run that fails silently at 3 AM.

```text
agent timed out waiting for tester approval; the run failed to proceed on authorized engagement
```

## Use this when
- The engagement has human-in-the-loop gates (scope changes, intrusive tests, report release).
- The agent stalled at a gate and the run died with no saved state.
- You need gates that survive the tester being asleep.

## Not for this skill when
- The phase should be fully autonomous. Then remove the gate instead of timing it out.
- The tester actively denied the request. A denial is an answer; handle it as a scope decision, not a timeout.
- You are operating outside an authorized engagement. Stop.

## Steps
1. List every gate in the run plan and assign each a timeout and a fallback: proceed-with-limits, park-and-notify, or abort. Verify: no gate has an infinite wait.
2. Before requesting approval, checkpoint full run state: completed work, queue, and findings ledger. Verify: the checkpoint alone is enough to resume.
3. Send the approval request with context the tester can decide on quickly: what is being asked, why, and what happens on timeout. Verify: the request names its own timeout.
4. On timeout, execute the fallback: park cleanly with state saved, or proceed within the pre-approved limits. Verify: the run never sits in an undecided state.
5. Log the gate event with timestamps: requested, timed out, fallback taken. Verify: the engagement record shows the full gate history.

## Variant phrasings
### agent stuck waiting for human approval
Common phrasing.
### human in the loop gate timeout pentest agent
Workflow phrasing.
### approval gate deadlock agent run
Symptom-level search.

Compatibility: any agent run with approval gates. The pattern is about run control, not tooling.

## Why it happens
Approval gates are designed as if the tester is watching, but testers sleep and context-switch. The agent's plan has a "wait for approval" step with no bound, so the run hangs until something external kills it, usually without saving state.

## Edge cases / pitfalls
- The fallback for intrusive-test gates must be conservative: park, never auto-proceed. Auto-proceeding past a denied-by-silence gate is how unauthorized testing happens.
- Batch approval requests instead of dripping them one at a time. Ten separate pings get ignored; one summary gets answered.
- If the tester is unreachable for the whole engagement window, that is an engagement problem, not an agent problem. Escalate to the engagement lead.

## Provenance

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