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

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.

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