Routine: submit_secret opens a user password card when the browser origin has a stale agent-scripted mark #1357

Summary

In a scheduled routine, openbot_browser.submit_secret with a saved loginId did not fill the saved login. It marked the routine needs-attention and surfaced OpenBot's secure password card, so the unattended run waited until the user interrupted it.

This looks like a product bug rather than a password-manager problem. The saved login and 1Password service account were both healthy; the block came from OpenBot's browser-origin safety state.

Environment

• OpenBot 0.65.0 (hosted server)
• openbot_browser in a scheduled routine
• A saved login was available and passed as loginId
• No 1Password prompt; the test was against the OpenBot secure-input card

Actual behaviour

At 15:04:59 UTC the routine called submit_secret for a login form. At the same moment OpenBot emitted routine.run-needs-attention and showed the secure password card. The run stayed there until the user replied at 15:12 UTC.

The resulting browser message was:

OpenBot did not fill a saved login: a script that you ran with evaluate can still run in this page or in another open page of this site. Reload this page, and close or navigate each other tab where you ran evaluate on this site, before submit_secret.

The route did not actually call evaluate or run_script in that attempt. It used snapshot, click, type and wait_for. wait_for does not appear to set the mark, so this was most likely a stale origin mark from an earlier evaluate/run_script in the same persistent browser session.

Code path in 0.65.0

• AttentionRegistry.#fillFromVault skips the saved-login fill when pending.secret.agentScriptedOrigin !== false.
• It then returns false, and surfaceBrowserTakeover calls markNeedsAttention(turnId) and emits browser-takeover-requested.
• BrowserHost.#agentCodeCanRead derives that value from scriptedOrigins across tabs in the browser session, plus cache-tainted origins.
• markScriptedOrigin is set by #runEvaluation, so the mark can outlive the document/tab that ran the original evaluate and block a fresh tab on the same origin.

Expected behaviour

• submit_secret with a valid saved loginId should fill the saved login, or
• if the origin is genuinely unsafe, it should fail fast with a clear, structured error; and
• in a routine run, it should never surface a password card that nobody can answer.

Suggested fix

1. Scope the agent-scripted mark to the current tab/document and clear it on navigation/new tab; do not let a stale mark in another tab/session block a fresh page.
2. In routine runs, make submit_secret return a structured "manual sign-in required" failure instead of marking needs-attention and opening the card.
3. Include the tab/origin that set the mark in the error, so the stale state is diagnosable.
4. Consider a separate explicit "allow vault fill despite the origin mark" path only if the product wants that trade-off; do not make the default a blocking card.

Likely reproduction

1. Open a site in the OpenBot browser.
2. Run openbot_browser.evaluate on that origin (or run_script with an evaluate step).
3. Close the tab and open a fresh tab on the same origin.
4. Call submit_secret with a saved loginId for a password field.
5. Observe the secure-input card instead of a vault fill.

I did not re-run step 4 after closing the stale tab because it would pop the card again; the timestamps and the 0.65.0 code path match the observed failure.

Impact

Unattended routines that use saved logins can stall on a password card and require the user, even though the login is already in the vault. The user cannot tell from the card whether this is a credential problem, a 1Password problem, or a browser safety state.