Recover from browser journey errors
A shared decision path for wrong-client states, expired sessions, interrupted jobs, provider errors, and uncertain completion.
Job to be done
Successful outcome
A safe recovery that avoids duplicate paid actions and preserves the user’s authenticated context.
Prerequisites
- Capture the visible status, current URL, selected client, and error message without exposing secrets.
Inputs
- Current URL
- Visible status
- Selected client name
- Displayed error message
- Whether the action may already have started
Browser procedure
Numbered journey
Stop repeated submission
Do not click the primary action again while completion is uncertain.
Expected: A duplicate paid run is avoided.
Check client and session
Confirm the selected client and whether login, MFA, or permissions require user intervention.
Expected: Identity and authorization are known.
Inspect persistent state
Use the current result URL, module history, or visible status to find an existing run.
Expected: The agent knows whether a job exists.
Classify the failure
Distinguish validation, authentication, configuration, provider, processing, and no-data states.
Expected: The recovery action matches the failure.
Retry safely or report
Retry only when the interface shows no existing run and the user approves any renewed cost risk.
Expected: The user receives either a recovered result or an exact blocker.
Approval boundaries
- Before retrying a possibly paid action
- Confirm that no completed or running job exists and ask the user to approve the retry.
Outputs
- Failure classification
- Existing job or artifact URL
- Safe retry decision
- Exact blocker when recovery needs the user
Recovery
- Validation error: correct only the invalid input and resubmit through the normal preparation flow.
- Expired session or MFA: hand control to the user, then resume at the existing URL.
- Running job after refresh: wait or reopen history; do not create another run.
- Provider failure: preserve the message, check for an existing job, and ask before retrying.
- No-data or unavailable module: report the state; never replace it with preview data.
Stop conditions and guardrails
- Never use repeated clicks as a polling mechanism.
- Never hide or paraphrase away a material error code.
- Never claim success from an animation or optimistic notification alone.
- Never expose cookies, tokens, credentials, or internal identifiers in the recovery report.
Ready to delegate
Copyable agent prompt
Recover the current GrowthOS browser journey safely. Do not resubmit the main action. Record the current URL, visible status, selected client, and error text without exposing secrets. Check module history or the result URL for an existing job. Classify the failure and either resume the existing job, hand authentication to me, or explain why a retry is safe. Ask before retrying anything that may consume credits.