Auth wall detection closes browser but fails to open headed checkpoint

[avifenesh]

Problem

When goto detects an auth wall, it closes the headless browser and calls canLaunchHeaded(). On the first attempt, canLaunchHeaded() returns false even when a display is available, causing the auth flow to abort with:

{ "authWallDetected": true, "checkpointCompleted": false, "message": "Auth wall detected but no display for headed checkpoint." }

The user must then manually run checkpoint --vnc as a separate step to authenticate, which defeats the purpose of automatic auth wall handling.

Expected Behavior

When an auth wall is detected and a display is available, the headed checkpoint should open automatically in a single goto call - without requiring a separate checkpoint invocation.

Likely Cause

canLaunchHeaded() may be checking display availability too early or caching a stale result from the initial headless launch context. After the headless browser is closed, the display check should re-evaluate.

Workaround

Run checkpoint --vnc manually after the failed goto, then re-navigate.

Impact

Breaks the single-command auth flow. Users need 3 commands (goto, checkpoint, goto) instead of 1.

[avifenesh]

[DONE] Task Completed Successfully

PR: #70
Status: Merged to main
Commit: d511c0a

Summary

• Removed permanent _headedResult cache that prevented retry after transient failures
• Added retry logic (2 attempts, 500ms delay) to canLaunchHeaded() for resource contention
• Added 500ms settling delay between closeBrowser() and canLaunchHeaded() in goto auth wall path
• Added 8 new tests (5 source-inspection + 3 behavioral)
• 508/508 tests passing

---

This issue was automatically processed by AgentSys /next-task workflow.
Closing issue as the work has been completed and merged.