[Bug] Harness Browser: Live View "Take control"/"Release" breaks the agent's automation on SSO handback (workaround: interact without Take control + reconnect)

[timwukp]

Summary (corrected after further testing)

On a managed AgentCore Harness with the built-in Browser tool, you can let a human complete an interactive SSO login (e.g. IAM Identity Center / a federated QuickSight console where the OTP arrives by email) in Live View and then have the agent continue in the same authenticated session — but only if you avoid the Live View "Take control" / "Release control" toggle.

• Broken path: human clicks Take control, completes the SSO+OTP login, clicks Release control, then the agent resumes. → The agent's automation context is destroyed. Every subsequent automation call returns Target page, context or browser has been closed, and shortly after the backend reports it is gone (not initialized / "all sessions are gone"). The authenticated session is unrecoverable. Reproduced across 3 orchestration strategies (concurrent polling, blind hands-off, signal-gated hands-off where the agent provably never touched the browser during the human's control).
• Working path (workaround): human interacts in Live View without clicking Take control (types the OTP / completes login directly), then the agent, on resume, does NOT reuse its pre-login page handle — it reconnects / re-reads the current page (e.g. via evaluate / re-navigate). → The authenticated state carries over; the agent lands on the authenticated console and proceeds normally. Verified end to end against a real QuickSight Enterprise console.

So the issue is specifically: the documented Live View take-over/release-control feature does not cleanly hand control back to the managed-harness agent's automation (it tears down the automation context), even though the dev guide presents take/release control as a feature ("interactive controls to take over or release control from automation").

Environment

• boto3 1.43.29 (bedrock-agentcore-control + bedrock-agentcore), managed Harness (CreateHarness/InvokeHarness), browser aws.browser.v1, networkMode: PUBLIC, region us-east-1.
• Tools: agentcore_browser + agentcore_code_interpreter + inline functions; allowedTools: ["*"].

Repro (both paths)

1. Harness with agentcore_browser; invoke a task that navigates to an SSO-gated console URL. Agent lands on the sign-in page (expected).
2. Open the session's Live View.
   • (broken) Click Take control → complete SSO+OTP → Release control → agent resumes → context dead.
   • (works) Do not click Take control; complete the login directly in the stream → then the agent reconnects (re-reads the page rather than reusing the old handle) → authenticated session carries over.

Asks

1. Is the Take control → Release control path intended to hand control back to the harness agent's automation? If so, the teardown is a bug; if not, please document that interacting without Take control (plus an automation reconnect) is the supported human-assisted-auth pattern.
2. Could the automation context survive a take/release cycle so the documented feature works for the managed harness?
3. Separately: the harness agentcore_browser tool config only accepts browserArn (no profileConfiguration), so a pre-saved authenticated browser profile cannot be attached as an alternative to interactive login. A profileConfiguration passthrough would help.

Happy to share CloudWatch DEFAULT-log-group traces for both the broken and working runs.

[timwukp]

Update: refined this report after further testing. The human-assisted SSO handback does work on the managed harness if you avoid the Live View "Take control"/"Release control" toggle and have the agent reconnect (re-read the current page) instead of reusing its pre-login page handle. The remaining defect is that the documented Take control → Release path tears down the agent's automation context on handback. Title/body updated accordingly; keeping it open as the take/release path still appears broken for the managed harness.