[matthewnanas]

Stack: 1 of 2. This PR is the base; #42 (repo-wide Prettier formatting) sits on top of it.

Summary

• Browser session: CAPTCHA gating moves to server/browser/captcha-gate.ts and the Browserbase launch/reattach/release flow moves to server/browser/browserbase-launch.ts. All page work, including withHostedPage and secureLogin, now shares one operation lock.
• CAPTCHA transitions: these are reported through a single onCaptchaTransition callback. The runtime queues them and applies them to task state inside the running operation, so they always land on the turn that's running.
• Database: advisory locking is one shared withAdvisoryLock helper in server/postgres.ts, used by the link, 1Password, and private-browser callers. Watch SQL moves onto MonitorStore.
• Personal-browser mode: this now requires the ONEPASSWORD_ENABLED rollout flag. The private-browser quarantine check and the reattach metadata check still run when the flag is off but the extension is configured. With the flag off, a saved personal session gets replaced instead of reattached.

Behavior notes

• Cancellation is checked again after taking the browser operation lock and before starting the browser, so a cancelled call never launches a session.
• secureLogin start and CAPTCHA-gate failures stay redacted ("Secure login failed") and record a vault.login error trace.
• markDispatchUnresolved now runs its two updates in one transaction, so the status change and the reconcile update succeed or fail together.

Testing

• pnpm lint and pnpm typecheck pass, apart from a local install missing standardwebhooks, which Add Parallel public-web search #37 added.
• pnpm test: 393 passed, 61 skipped. New tests cover:
  • CAPTCHA events landing on the running turn
  • cancellation while waiting for the lock
  • redacting secure-login start failures
  • the private-browser guard with the rollout flag off
  • replacing a personal browser with the flag off
• The database-backed suites and the monitor tests (tests/monitors.test.ts, tests/monitor-http.test.ts) did not run locally. They need a database and a fresh pnpm install.

🤖 Generated with Claude Code

[shriyatheunicorn]

can we give each replacement browser a fresh CAPTCHA transition queue here and in selectBrowserContext?

if a CAPTCHA starts and errors between tool calls, createBrowserContext closes the old browser but passes its pending events into the replacement. the next snapshot succeeds on the new browser, then draining the old queue marks the task waiting_for_user for a challenge in the closed browser.

i reproduced this locally; the regression test passes at the merge base and fails on this PR. replacing the queue when replacing the browser also keeps late callbacks from the retired browser out of the new queue.