[comp] Production Deploy

[github-actions]

This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.

---

Summary by cubic

Production release for browser automations: adds credential-backed auto sign-in via 1Password, a smart connect flow with live sign-in, multi-step automations with per-step evidence and live streaming, and an org-level Connections page. Also safeguards scheduled runs from changing tasks marked not_relevant.

• New Features

  • Auto re-login using credentials stored per org in 1Password; supports extra fields and TOTP; secrets never logged (totpSeed/totpCode redacted).
  • Smart connect flow: vendor login analysis, method chooser (password or SSO), automated sign-in with a live step timeline and takeover when needed; smaller live viewport for readability.
  • Connections page: list all connections with status and automation count; reconnect, rename/change login, or remove.
  • Multi-step automations: ordered steps across vendors; per-step runs with full-page and focused screenshots; rolled-up verdict; live run streaming with step timeline and live-view switching between vendors.
  • Drafts: autosave and resume in-progress automations; finalize on save.
  • Task UX: “Browser evidence” header with task-wide cadence, compact run-history ledger, improved composer and test runs; sharper captures and resilient navigation model fallback.
  • Scheduler guard: scheduled runs no longer overwrite tasks marked not_relevant; enforced via atomic conditional updates.

• Migration

  • Required for browser automations: set BROWSERBASE_API_KEY and BROWSERBASE_PROJECT_ID.
  • Optional to enable password sign-in and unattended re-login: set OP_SERVICE_ACCOUNT_TOKEN; runtime uses @1password/sdk (loaded lazily).
  • Optional model overrides: BROWSERBASE_CUA_MODEL (navigation) and BROWSERBASE_STAGEHAND_MODEL (reading/verdicts).
  • No breaking changes if 1Password is not configured; flows fall back to manual/SSO.

^{Written for commit 99393e5. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
comp-framework-editor (staging)	Ready	Preview, Comment	Jul 27, 2026 4:36am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
app (staging)	Skipped		Jul 27, 2026 4:36am
portal (staging)	Skipped		Jul 27, 2026 4:36am

[cubic-dev-ai]

39 issues found across 157 files

Confidence score: 2/5

• In InstructionComposer.tsx and useBrowserExecution.ts, cancel/switch races can leave in-flight Browserbase runs alive, then attach stale results to the wrong step or keep executing after the user canceled; this is a direct regression risk for task correctness and evidence integrity — tie responses to a request generation and propagate cancelation through execute-live end-to-end.
• apps/app/src/app/api/vendor-logo/route.ts currently permits unauthenticated outbound fetches, which can be abused as a public proxy and bypass expected RBAC boundaries — apply the shared request/auth guard on this route before exposing it.
• In browser-auth-profile.service.ts and browser-instruction-test.service.ts, profile deletion/status handling can make tests pass while saved automations later run under a different or invalid account, creating silent account drift and misleading success signals — preserve unresolved bindings and enforce the same profile-status gate in test execution.
• browser-credential-storage.service.ts and browser-evidence-execution.ts introduce persistence/replay hazards: credential re-saves can orphan old 1Password items, and broad instruction retries after partial side effects can duplicate submissions — reuse or delete superseded vault items and restrict retries to known-safe failure classes.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useBrowserExecution.ts">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useBrowserExecution.ts:133">
P1: Canceling the live view does not cancel the background automation: it only closes the current Browserbase session, while `execute-live` can continue into later vendor steps and persist evidence after the user canceled. A cancellation path for the Trigger run and/or the persisted automation run would keep canceled actions from continuing.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/settings/browser-connection/components/BrowserConnectionClient.tsx">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/settings/browser-connection/components/BrowserConnectionClient.tsx:41">
P2: Users with `integration:create` but without `integration:update` can open this connect flow, but it cannot complete after credentials are entered because the required save/sign-in/verification calls are update-protected. Derive `canConnect` from both permissions (or otherwise gate the flow to the permissions it requires) so custom RBAC roles are not offered an action they cannot finish.

(Based on your team's feedback about RBAC permission checks.) [FEEDBACK_USED].</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/InstructionComposer.tsx">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/InstructionComposer.tsx:308">
P2: Moving an inactive step changes which step is active. Because `handleMove` always sets `activeIndex` to the moved step's destination, swapping an inactive step with the active step leaves the formerly inactive step selected and makes the test pane target the wrong instruction. The active index can remain unchanged for unrelated moves, and should swap indices only when the active step is one of the two moved steps.</violation>

<violation number="2" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/InstructionComposer.tsx:336">
P1: Cancelling or switching steps while the test-start request is in flight can leak a Browserbase session and attach the stale run to the wrong step. The returned handle needs to be tied to a request generation/mounted state; stale handles should be closed immediately instead of being committed to component state.</violation>

<violation number="3" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/InstructionComposer.tsx:348">
P2: Editing an automation drops its saved path-level target URL. The composer discards `BrowserAutomationStep.targetUrl` during initialization and rebuilds every target from the connection origin on save, so an edit can make the automation start at the wrong page. Preserve each step's target URL (and the first step's top-level URL) through the editable state.</violation>
</file>

<file name="apps/api/src/browserbase/onepassword-credential-vault.adapter.ts">

<violation number="1" location="apps/api/src/browserbase/onepassword-credential-vault.adapter.ts:98">
P2: A 1Password outage or authentication failure is silently converted into an absent username/password, so automated sign-in falls back as if the profile had no credentials and the actual vault failure is hidden. Handling only a known missing-field error as optional and rethrowing other failures would preserve outage visibility and retry/error behavior.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/BrowserAutomations.tsx">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/BrowserAutomations.tsx:86">
P2: Editing while the initial draft POST is in flight drops the newer payload, leaving the server draft stale after the request completes. Queue the latest payload and update the created draft once its ID is available instead of returning without retrying.</violation>

<violation number="2" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/BrowserAutomations.tsx:208">
P2: Creating new evidence on an existing task can select the wrong vendor: any GitHub profile is preferred because `authUrl` defaults to GitHub, even when the task's automations use another host. The just-connected branch should only be considered when `justConnected` is true, then fall back to the task's existing connection.</violation>
</file>

<file name="apps/api/src/browserbase/browser-login-navigation.ts">

<violation number="1" location="apps/api/src/browserbase/browser-login-navigation.ts:8">
P2: With multiple tabs open, redirect settling can watch the newest tab instead of the tab Stagehand is actively operating, so extraction or credential filling may begin while the acted-on page is still navigating. Reading `context.activePage()` keeps the URL hint aligned with Stagehand's action target.</violation>
</file>

<file name="apps/api/src/browserbase/browserbase.service.ts">

<violation number="1" location="apps/api/src/browserbase/browserbase.service.ts:300">
P2: A transient Browserbase lookup failure is reported as a successful close while the live session can remain running until its timeout. The close path could tolerate only a confirmed missing-session response and rethrow availability/transport errors so callers can retry and cleanup failures remain visible.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useBrowserProfiles.ts">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useBrowserProfiles.ts:20">
P1: On first load, an API or network error leaves `profiles` as `[]` — indistinguishable from "no connections yet." The in-line comment recognizes this masking problem but doesn't solve it for the initial-load case. Add an `error` / `isError` state so consumers can render a distinct error/retry UI instead of showing an empty list. See `useTaskAutomations` and `useTask` for the established pattern.</violation>
</file>

<file name="apps/api/src/browserbase/browser-credential-signin.service.ts">

<violation number="1" location="apps/api/src/browserbase/browser-credential-signin.service.ts:228">
P2: When a vendor opens the sign-in or landing page in a new tab, a successful run can return the original tab's URL as `homeUrl`, causing the connect flow to save a URL that still leads to login on future runs. Selecting the newest active page here would keep the returned target consistent with the page used for classification and live-view updates.</violation>
</file>

<file name="apps/api/src/browserbase/browser-auth-profile.service.ts">

<violation number="1" location="apps/api/src/browserbase/browser-auth-profile.service.ts:75">
P2: Automation dependency counts are incorrect for multiple identities and multi-step automations: host-only counting assigns the same total to every same-host connection and misses profiles used by later steps. Counting the actual step/profile bindings would keep the settings table and deletion warnings accurate.</violation>

<violation number="2" location="apps/api/src/browserbase/browser-auth-profile.service.ts:283">
P2: Changing a connection to another hostname leaves it unable to reconnect: the new URL is stored while the profile's hostname remains the old one, and the sign-in guard later rejects that URL. Reject cross-host edits or create a new profile instead of persisting a URL that cannot pass the profile guard.</violation>

<violation number="3" location="apps/api/src/browserbase/browser-auth-profile.service.ts:308">
P1: Deleting a connection can silently switch an automation to another account: the step binding is nulled by the profile delete, then execution falls back to a verified profile with the same hostname. Preserving an unresolved binding or preventing deletion while steps reference the profile would make the automation stop until explicitly reconnected.</violation>
</file>

<file name="apps/api/src/browserbase/browser-mfa-instructions.service.ts">

<violation number="1" location="apps/api/src/browserbase/browser-mfa-instructions.service.ts:154">
P2: Cache misses can trigger duplicate and attacker-chosen numbers of Firecrawl/Claude requests because in-flight generations are not deduplicated or rate-limited. Tracking pending promises per hostname and applying endpoint-level cost/rate controls would prevent a permitted caller from turning this endpoint into a provider-cost or availability drain.</violation>

<violation number="2" location="apps/api/src/browserbase/browser-mfa-instructions.service.ts:289">
P2: Malformed `host` values are silently accepted and fed into both web search and model generation, allowing request text to poison the generated and cached guidance. Invalid hostnames/URLs should be rejected at the API boundary instead of falling back to the raw query string.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useInstructionTest.ts">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useInstructionTest.ts:41">
P2: Navigating away while the test-start request is in flight can leak the newly created Browserbase session: this hook returns the handle after the caller's cleanup has already run, so no subsequent `closeTestSession` call is made. An abort/unmount-aware cleanup path would ensure a late response closes `sessionId` instead of leaving the `keepAlive` session open.</violation>
</file>

<file name="apps/api/src/browserbase/browser-automation-step-results.ts">

<violation number="1" location="apps/api/src/browserbase/browser-automation-step-results.ts:110">
P2: Multi-step runs drop every step's focused screenshot from the rolled-up result. `finishRun` persists `result.focusScreenshotKey`, so the parent run has no focused proof even though each step produced one; carry the selected step's focus fields through the roll-up.</violation>
</file>

<file name="apps/api/src/browserbase/browser-automation-crud.service.ts">

<violation number="1" location="apps/api/src/browserbase/browser-automation-crud.service.ts:202">
P2: Legacy edits to `targetUrl`, `instruction`, or `evaluationCriteria` return a stale first step. The parent update loads `steps` before the mirror `updateMany`, so callers must refetch to see the change; updating the step first or re-reading the automation before returning would keep the response consistent.</violation>
</file>

<file name="apps/api/src/browserbase/browser-credential-storage.service.ts">

<violation number="1" location="apps/api/src/browserbase/browser-credential-storage.service.ts:75">
P1: Re-saving credentials leaves the previous 1Password item orphaned while retaining its username, password, and TOTP seed in the organization vault. Updating/reusing the existing item, or deleting the superseded item after a successful reference update with failure-safe cleanup, would prevent stale secret retention.</violation>

<violation number="2" location="apps/api/src/browserbase/browser-credential-storage.service.ts:306">
P2: A crafted extra-field label can inject instructions into the Stagehand action used during automated sign-in while `%value%` carries a stored secret, potentially redirecting where that secret is entered or what the agent clicks. Treat labels as constrained data or avoid interpolating untrusted labels into the model prompt before using this credential path.</violation>
</file>

<file name="apps/api/src/browserbase/browser-credential-login.ts">

<violation number="1" location="apps/api/src/browserbase/browser-credential-login.ts:114">
P2: Profiles with a TOTP are submitted twice after any failed auth check, including invalid credentials or a human challenge, not just an expired code. Gating this retry on a 2FA-specific outcome would avoid unnecessary submissions and reduce account-lockout or challenge side effects.</violation>

<violation number="2" location="apps/api/src/browserbase/browser-credential-login.ts:215">
P2: Evidence runs can try to fill a homepage instead of the vendor's login form and then report `needs_reauth`: this helper calls `performCredentialLogin` immediately, unlike the connect flow, which first calls `navigateToSignIn`. Starting each attempt by navigating to the sign-in form would cover target URLs that show only a Sign in link.</violation>

<violation number="3" location="apps/api/src/browserbase/browser-credential-login.ts:325">
P2: The rotation-boundary retry replays the entire username/password flow on the existing 2FA page instead of submitting only the refreshed code. Providers that expose only a code field can reject or restart these actions, turning a recoverable OTP retry into an exception or `unknown` result; the retry should target the current code prompt or explicitly restart navigation.</violation>
</file>

<file name="apps/api/src/browserbase/browser-evidence-execution.ts">

<violation number="1" location="apps/api/src/browserbase/browser-evidence-execution.ts:57">
P2: Setting `BROWSERBASE_CUA_MODEL` to a non-OpenAI, non-Anthropic provider causes CUA authentication to use the Anthropic key and fail before navigation. Provider selection should resolve the matching credential (or leave the key unset for Stagehand's provider-specific environment resolution) instead of treating every non-OpenAI model as Anthropic.</violation>

<violation number="2" location="apps/api/src/browserbase/browser-evidence-execution.ts:268">
P1: A navigation failure after a side effect now replays the entire instruction from the partially modified browser state, which can duplicate submissions or other mutations. Fallback would be safer only for errors known to occur before actions or for explicitly retry-safe failures.</violation>
</file>

<file name="apps/api/src/browserbase/browserbase-session.service.ts">

<violation number="1" location="apps/api/src/browserbase/browserbase-session.service.ts:32">
P2: Setting `BROWSERBASE_STAGEHAND_MODEL` to a non-Anthropic model makes Stagehand `extract()`/`act()` calls authenticate with `ANTHROPIC_API_KEY`, so the configured model fails unless the keys happen to match. Provider-key resolution should follow the model prefix, or the override should be restricted to `anthropic/*`.</violation>
</file>

<file name="apps/app/src/app/api/vendor-logo/route.ts">

<violation number="1" location="apps/app/src/app/api/vendor-logo/route.ts:12">
P1: This customer-facing API route allows unauthenticated callers to use the app as an outbound DuckDuckGo proxy, bypassing the repository's RBAC contract and enabling unrestricted request abuse. Applying the shared `requireApiPermission` check (for example, `vendor:read`) before parsing or fetching would enforce the active organization permission without hardcoded role checks.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useTotpStatus.ts">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useTotpStatus.ts:29">
P2: A vault read failure is presented as "Automatic 2FA off" rather than unknown, because this fallback treats the API's failure sentinel `{ configured: false }` as a confirmed disabled state. Preserving an explicit unknown/error result from the status endpoint would prevent users from being offered a setup flow that can replace an existing key.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/AutomationItem.tsx">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/AutomationItem.tsx:82">
P2: Keyboard users cannot reliably activate nested controls: Enter/Space events bubble to the row, which expands history and prevents the child button's default action. Restrict row keyboard handling to events whose target is the row itself (or stop key propagation from each nested control).</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/connect-capture-fields.ts">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/connect-capture-fields.ts:22">
P2: Required fields such as `Email domain` or `Login domain` can be classified as the identifier because the regex matches any `e-mail`/`login` substring, causing the actual username field to be rendered as an extra or omitted and `username` to receive the wrong value. A constrained whole-label match or detector-provided identifier metadata would avoid promoting arbitrary site-specific fields.</violation>

<violation number="2" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/connect-capture-fields.ts:63">
P1: Sites whose detected order is `[identifier, extra]` can fail automated sign-in because the extra is filled before the identifier, even though this form displays it after the identifier. Removing the promoted identifier from the ordered list and sending the remaining fields through `extraFields` loses its position; preserving order requires an ordered runtime contract or a corresponding backend change.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/ConnectCaptureForm.tsx">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/ConnectCaptureForm.tsx:21">
P2: Passwords containing leading or trailing spaces are silently stripped before they reach the sign-in flow, so valid credentials can be rejected and the stored secret is incorrect. The password value should be validated for non-whitespace content without using a transforming `.trim()` schema.</violation>

<violation number="2" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/ConnectCaptureForm.tsx:102">
P1: Vendor-controlled field labels are allowed to become instructions in the Stagehand prompt, which can make automated sign-in perform unintended page actions. Field targeting should use a structured/allow-listed representation, or labels should be sanitized and kept out of the model instruction text.</violation>
</file>

<file name="apps/api/src/browserbase/browser-instruction-test.service.ts">

<violation number="1" location="apps/api/src/browserbase/browser-instruction-test.service.ts:72">
P1: A test can report success for a blocked or unverified connection even though the corresponding saved automation will not run. Applying the same profile-status gate used by `BrowserAutomationStepRunnerService` before invoking the evidence runner would keep the preview result consistent with unattended execution.</violation>
</file>

<file name="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/ConnectMethodChooser.tsx">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/ConnectMethodChooser.tsx:71">
P2: When `analysis` changes while the chooser remains mounted, Continue can submit a method that is no longer detected because `selected` is initialized only once. Keep the selection synchronized with the current `options`, or fall back to the first available option before rendering and submitting.

(Based on your team's feedback about resyncing local state when props change.) [cfebfe92-296b-49c2-8b2a-f09bf3f8941d]</violation>
</file>

<file name="apps/api/src/browserbase/browser-automation-execution.service.ts">

<violation number="1" location="apps/api/src/browserbase/browser-automation-execution.service.ts:192">
P1: A duplicate or late live task can continue driving browser sessions after the parent run is no longer active, because this multi-step path never revalidates the run before each step. Passing an active-run assertion through `runSteps` (as the existing session path does) would prevent post-terminal actions and duplicate evidence.</violation>

<violation number="2" location="apps/api/src/browserbase/browser-automation-execution.service.ts:207">
P2: Some bookkeeping or profile-health failures leave the parent run stuck in `running` because all `ConflictException` and `NotFoundException` errors are rethrown before `finishRun`. Replay detection should be isolated to an explicit active-run check, while failures from step bookkeeping and profile updates should be converted to a failed result and finalized.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Cancelling or switching steps while the test-start request is in flight can leak a Browserbase session and attach the stale run to the wrong step. The returned handle needs to be tied to a request generation/mounted state; stale handles should be closed immediately instead of being committed to component state.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/app/src/app/(app)/[orgId]/tasks/[taskId]/components/browser-automations/InstructionComposer.tsx, line 336:

<comment>Cancelling or switching steps while the test-start request is in flight can leak a Browserbase session and attach the stale run to the wrong step. The returned handle needs to be tied to a request generation/mounted state; stale handles should be closed immediately instead of being committed to component state.</comment>

<file context>
@@ -0,0 +1,470 @@
+      setPhase('idle');
+      return;
+    }
+    setSessionId(handle.sessionId);
+    setLiveViewUrl(handle.liveViewUrl);
+    setTestRun({ runId: handle.runId, accessToken: handle.publicAccessToken });
</file context>

[cubic-dev-ai]

P1: On first load, an API or network error leaves profiles as [] — indistinguishable from "no connections yet." The in-line comment recognizes this masking problem but doesn't solve it for the initial-load case. Add an error / isError state so consumers can render a distinct error/retry UI instead of showing an empty list. See useTaskAutomations and useTask for the established pattern.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useBrowserProfiles.ts, line 20:

<comment>On first load, an API or network error leaves `profiles` as `[]` — indistinguishable from "no connections yet." The in-line comment recognizes this masking problem but doesn't solve it for the initial-load case. Add an `error` / `isError` state so consumers can render a distinct error/retry UI instead of showing an empty list. See `useTaskAutomations` and `useTask` for the established pattern.</comment>

<file context>
@@ -0,0 +1,32 @@
+      // apiClient resolves (doesn't throw) on an HTTP error — keep the existing
+      // list on failure instead of blanking it (which would mask the error as
+      // "no connections").
+      if (res.error) return;
+      setProfiles(Array.isArray(res.data) ? res.data : []);
+    } catch {
</file context>

[cubic-dev-ai]

P1: Re-saving credentials leaves the previous 1Password item orphaned while retaining its username, password, and TOTP seed in the organization vault. Updating/reusing the existing item, or deleting the superseded item after a successful reference update with failure-safe cleanup, would prevent stale secret retention.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/api/src/browserbase/browser-credential-storage.service.ts, line 75:

<comment>Re-saving credentials leaves the previous 1Password item orphaned while retaining its username, password, and TOTP seed in the organization vault. Updating/reusing the existing item, or deleting the superseded item after a successful reference update with failure-safe cleanup, would prevent stale secret retention.</comment>

<file context>
@@ -0,0 +1,314 @@
+    });
+
+    const { ItemCategory } = await loadOnePasswordModule();
+    const item = await client.items.create({
+      category: ItemCategory.Login,
+      vaultId,
</file context>

[cubic-dev-ai]

P1: Canceling the live view does not cancel the background automation: it only closes the current Browserbase session, while execute-live can continue into later vendor steps and persist evidence after the user canceled. A cancellation path for the Trigger run and/or the persisted automation run would keep canceled actions from continuing.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useBrowserExecution.ts, line 133:

<comment>Canceling the live view does not cancel the background automation: it only closes the current Browserbase session, while `execute-live` can continue into later vendor steps and persist evidence after the user canceled. A cancellation path for the Trigger run and/or the persisted automation run would keep canceled actions from continuing.</comment>

<file context>
@@ -32,81 +86,94 @@ export function useBrowserExecution({ onNeedsReauth, onComplete }: UseBrowserExe
+    const finalize = (ok: boolean, message?: string) => {
+      if (ok) toast.success('Automation completed successfully');
+      else toast.error(message || 'Automation failed');
+      if (sessionId) void closeSession(sessionId);
+      // Capture which automation ran before reset clears it, then auto-expand it
+      // once its fresh run is refetched — so a manual Run shows its results
</file context>

[cubic-dev-ai]

P1: This customer-facing API route allows unauthenticated callers to use the app as an outbound DuckDuckGo proxy, bypassing the repository's RBAC contract and enabling unrestricted request abuse. Applying the shared requireApiPermission check (for example, vendor:read) before parsing or fetching would enforce the active organization permission without hardcoded role checks.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/app/src/app/api/vendor-logo/route.ts, line 12:

<comment>This customer-facing API route allows unauthenticated callers to use the app as an outbound DuckDuckGo proxy, bypassing the repository's RBAC contract and enabling unrestricted request abuse. Applying the shared `requireApiPermission` check (for example, `vendor:read`) before parsing or fetching would enforce the active organization permission without hardcoded role checks.</comment>

<file context>
@@ -0,0 +1,36 @@
+ * directly — that would leak which vendors an org uses and trip the app CSP.
+ * Cached hard (logos rarely change); the caller falls back to a monogram on 404.
+ */
+export async function GET(req: NextRequest): Promise<NextResponse> {
+  const host = req.nextUrl.searchParams.get('host')?.toLowerCase().trim() ?? '';
+  if (!host || host.length > 253 || !HOSTNAME.test(host)) {
</file context>

[cubic-dev-ai]

P2: A 1Password outage or authentication failure is silently converted into an absent username/password, so automated sign-in falls back as if the profile had no credentials and the actual vault failure is hidden. Handling only a known missing-field error as optional and rethrowing other failures would preserve outage visibility and retry/error behavior.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/api/src/browserbase/onepassword-credential-vault.adapter.ts, line 98:

<comment>A 1Password outage or authentication failure is silently converted into an absent username/password, so automated sign-in falls back as if the profile had no credentials and the actual vault failure is hidden. Handling only a known missing-field error as optional and rethrowing other failures would preserve outage visibility and retry/error behavior.</comment>

<file context>
@@ -0,0 +1,117 @@
+            Boolean(field.value?.trim()),
+        )
+        .map((field) => ({ label: field.title, value: field.value }));
+    } catch {
+      return [];
+    }
</file context>

[cubic-dev-ai]

P2: A transient Browserbase lookup failure is reported as a successful close while the live session can remain running until its timeout. The close path could tolerate only a confirmed missing-session response and rethrow availability/transport errors so callers can retry and cleanup failures remain visible.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/api/src/browserbase/browserbase.service.ts, line 300:

<comment>A transient Browserbase lookup failure is reported as a successful close while the live session can remain running until its timeout. The close path could tolerate only a confirmed missing-session response and rethrow availability/transport errors so callers can retry and cleanup failures remain visible.</comment>

<file context>
@@ -91,6 +269,67 @@ export class BrowserbaseService {
+          error instanceof Error ? error.message : String(error)
+        }`,
+      );
+      return;
+    }
+    if (!contextId) return;
</file context>

[cubic-dev-ai]

P2: A vault read failure is presented as "Automatic 2FA off" rather than unknown, because this fallback treats the API's failure sentinel { configured: false } as a confirmed disabled state. Preserving an explicit unknown/error result from the status endpoint would prevent users from being offered a setup flow that can replace an existing key.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/app/src/app/(app)/[orgId]/tasks/[taskId]/hooks/useTotpStatus.ts, line 29:

<comment>A vault read failure is presented as "Automatic 2FA off" rather than unknown, because this fallback treats the API's failure sentinel `{ configured: false }` as a confirmed disabled state. Preserving an explicit unknown/error result from the status endpoint would prevent users from being offered a setup flow that can replace an existing key.</comment>

<file context>
@@ -0,0 +1,36 @@
+  );
+
+  return {
+    configured: data?.configured ?? false,
+    isLoading: enabled && isLoading,
+    // Surface the failure so the UI can show an "unknown" state instead of
</file context>

[cubic-dev-ai]

P2: When a vendor opens the sign-in or landing page in a new tab, a successful run can return the original tab's URL as homeUrl, causing the connect flow to save a URL that still leads to login on future runs. Selecting the newest active page here would keep the returned target consistent with the page used for classification and live-view updates.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/api/src/browserbase/browser-credential-signin.service.ts, line 228:

<comment>When a vendor opens the sign-in or landing page in a new tab, a successful run can return the original tab's URL as `homeUrl`, causing the connect flow to save a URL that still leads to login on future runs. Selecting the newest active page here would keep the returned target consistent with the page used for classification and live-view updates.</comment>

<file context>
@@ -0,0 +1,256 @@
+        await record('logged_in');
+        finish('done');
+        // Re-read the active page: signing in usually navigates to an app/home page.
+        const landed = await this.sessions.ensureActivePage(activeStagehand);
+        return { isLoggedIn: true, homeUrl: landed.url() };
+      }
</file context>

[cubic-dev-ai]

P2: Automation dependency counts are incorrect for multiple identities and multi-step automations: host-only counting assigns the same total to every same-host connection and misses profiles used by later steps. Counting the actual step/profile bindings would keep the settings table and deletion warnings accurate.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/api/src/browserbase/browser-auth-profile.service.ts, line 75:

<comment>Automation dependency counts are incorrect for multiple identities and multi-step automations: host-only counting assigns the same total to every same-host connection and misses profiles used by later steps. Counting the actual step/profile bindings would keep the settings table and deletion warnings accurate.</comment>

<file context>
@@ -41,10 +47,33 @@ export class BrowserAuthProfileService {
+
+    return profiles.map((profile) => ({
+      ...profile,
+      automationCount: countByHost.get(profile.hostname) ?? 0,
+    }));
   }
</file context>