2026 Perplexity Comet Automation Stuck on Login? Developer Reproduction Guide

Treat a Perplexity Comet login stop as a handoff or session clue first: check for a required user authorization, then reproduce with a non-sensitive test account before calling it a compatibility bug. Record the browser prompt and exact stop point, and change one condition at a time.

This guide is for frontend engineers debugging AI browser access to authenticated pages, QA engineers building repeatable session tests, and product teams deciding which sensitive actions must remain under user control.

Last updated October 1, 2026. Product behavior was checked against Perplexity’s Comet assistant and user-control description and its official Comet getting-started guide. Those sources describe product capabilities and control principles; they do not establish how Comet behaves on every website or login flow.

Establish a public-page baseline before testing login

Start with a page that does not require an account. Give Comet a simple task that checks whether it can read visible content and follow an ordinary link. Keep the task narrow: you need to establish whether the browser can interpret the page and navigate, not test a whole workflow at once.

Record these details before moving to an authenticated flow:

• Browser version and the date of the run.
• The page URL, including whether it redirects.
• The exact task instruction you gave the assistant.
• What the page displayed and what Comet did.
• The precise point where the task stopped, including any visible prompt.

Use the same public page and task when you repeat the test. If the baseline fails, do not start by changing login code. First inspect whether the instruction was ambiguous, whether the page was available, and whether the browser displayed an error or permission request. A weak baseline makes later comparisons unreliable because you will not know whether the difference came from authentication or from ordinary navigation.

Why does Perplexity Comet stop at a website login page?
A stop can be an intentional request for the user to sign in, a prompt to authorize an action, an expired session, or a page interaction that did not complete. Perplexity’s materials describe an assistant designed to keep the user involved in browser work and permission-sensitive actions; they do not guarantee that every sign-in flow will be completed autonomously. Treat the displayed prompt and the last successful action as evidence. Do not infer a website defect from the stop alone.

Identify whether the login flow requires a user handoff

When Comet reaches a login page, pause and classify what you see before changing the test setup. Look for an explicit request to sign in, an authorization prompt, or language that asks you to take control. The official Comet guide is the right reference for its documented use and interaction model; use it to distinguish the product’s stated behavior from an assumption about a specific site.

A user handoff is not the same as a failed login. If the browser asks you to enter credentials or approve a sensitive step, follow that instruction using a dedicated test account. Then note whether the assistant resumes, remains paused, or loses the task context. That transition is often more useful than simply recording “login failed.”

Use a test account with fictional profile details and only the permissions needed for the test. Do not provide personal credentials, production access, payment data, or real customer information. Do not try to bypass CAPTCHA, multi-factor authentication, or another control intended to verify a person. The objective is to understand the safe boundary of the workflow, not to remove it.

How should you test an AI browser when a login page shows CAPTCHA?
Keep the CAPTCHA as a user-controlled step. If the test environment supports documented test keys or a designated test mode, use the provider’s instructions rather than solving or circumventing a live challenge. Google’s reCAPTCHA FAQ describes testing guidance, and its loading documentation explains asynchronous loading. Record whether the challenge appeared, whether a user completed it, and what happened afterward. Do not treat automated completion of CAPTCHA as an acceptance requirement.

Keep the distinction explicit in the bug report: “assistant requested user action” describes a control boundary; “the page failed to respond after user action” points to a possible interaction defect.

Compare session states without exposing credentials

A browser login-state test should compare distinct starting conditions. Run the same task with a valid dedicated test session, an expired session, and a clean unauthenticated session. Do not mix the cases in one run. If the result changes, repeat the relevant case while changing only one condition, such as whether the session is already established or whether the page opens in a new tab.

Observe the visible journey rather than copying secrets into a report:

• Does the site show the expected login page, or does it redirect elsewhere?
• After the test user signs in, does the page return to the intended destination?
• Does a new tab retain the expected state, or does it ask for authentication again?
• Does the session appear to expire during the task?
• Does the assistant continue with the original task after authentication, or does it need a clearer instruction?

The OWASP session management guidance explains why session identifiers must be protected. Never paste cookies, authorization headers, passwords, recovery codes, or raw browser storage into an issue, screenshot, or test log. Record the state category instead, such as “authenticated test session” or “expired session.” If a test artifact might contain a credential, treat it as sensitive and remove or restrict it according to your organization’s process.

How can you verify a post-login flow with a test account?
Prepare a dedicated account with minimal access, establish a known starting state, and run the same task from that state each time. Record the page reached after authentication and the visible outcome, not the secret used to authenticate. Browser test tooling follows the same principle: the Playwright authentication guide warns that stored authentication state can contain sensitive information. Keep any such state out of source control and shared reports.

For each run, capture the task instruction exactly. A request such as “continue” may not explain which page or action should follow sign-in. Instead, define the next intended outcome in plain language, while leaving the credential entry and other sensitive steps to the user when the browser requests it. This helps separate unclear task context from a session-handling problem.

Reproduce dynamic pages one interaction at a time

After the public baseline and session checks, move to the dynamic flow that actually fails. Test a single interaction in isolation: a delayed content panel, a menu, a modal, a client-side route change, or a form whose available fields depend on an earlier choice. Capture the point before and after the action so you can tell whether the element appeared, whether the page changed, and whether another layer covered the control.

What should you check when Comet cannot interact with a dynamic page?
First confirm that the expected content is visible in the browser. Then check whether it appears only after a delay, after a user gesture, or after a route change. If the element never appears, investigate the site’s state and loading path. If it appears but is covered, disabled, or replaced after interaction, report that exact transition. Avoid labeling every stalled interaction as an AI browser failure; the page may not have reached the state your task assumes.

For a single-page application, note the route and visible state after each transition. A URL can remain unchanged while the content changes, or the URL can update before the interface is ready. Capture screenshots only after removing names, email addresses, tokens, and other identifying information. If a screenshot cannot be safely sanitized, describe the visible state in text instead.

For delayed elements, record the trigger and the observable result. Did the content appear after waiting, after scrolling, or after opening a panel? Did a consent dialog or modal block the intended control? Did the page require a click that the task never requested? These observations help developers reproduce the failure without guessing at hidden browser behavior.

Also check whether a new tab or popup is part of the workflow. Record which action opened it, whether the user had to approve the transition, and whether the original task continued in the expected tab. Keep the test focused: changing the session, task wording, page state, and tab behavior all at once makes the result hard to interpret.

Make confirmation and recovery part of acceptance

Treat form submission, profile changes, purchases, and other consequential actions as separate test boundaries. A workflow can be successful even when the assistant pauses for confirmation. The relevant question is whether the user can understand what is about to happen, make the decision, and recover if the result is wrong.

For each sensitive step, check whether the page makes the pending action clear, whether the assistant pauses instead of silently committing it, and whether the user has a practical way to cancel or undo the change. Test with fictional data and a reversible action wherever possible. Do not use a real account or submit a live transaction to prove that an automation path works.

The OWASP authentication guidance provides security recommendations for authentication flows. Use those principles alongside your product requirements when reviewing login and confirmation behavior. A higher task-completion rate is not a sufficient acceptance measure if the workflow obscures consent or makes recovery difficult.

If the page requires a human decision, count a clear pause and safe handoff as an expected outcome, not a failed automation run.

Choose the next action from the observed evidence

Use this decision list after you have a public baseline and at least one controlled login-state run:

• If Comet explicitly asks you to sign in, authorize, or take control, treat the pause as a user handoff. Complete only the approved test step, then record whether the task resumes.
• If the session is expired or absent and the site redirects correctly, classify the result as an authentication-state difference. Repeat with a known test session before filing a browser defect.
• If the same task behaves differently only in a new tab, reproduce that tab transition and include the before-and-after URLs and visible states. Avoid sharing session data.
• If the expected dynamic element never becomes visible, inspect the page’s loading and state transition first. File a browser interaction issue only when you can show that the page reached the expected state.
• If a CAPTCHA or sensitive confirmation appears, stop at the control boundary and test the documented user handoff. Do not make bypassing the challenge or silently completing the action the pass condition.
• If the behavior repeats with a stable page state and a clear task, submit a minimal reproduction with sanitized evidence. Include the instruction, starting state, stop point, prompt text, and what changed between runs.

This branch-based approach helps you distinguish a product limitation, a permission requirement, a session-state issue, and a website interaction defect. It also prevents a report from claiming more than the test established.

Create a reproduction record another engineer can repeat

Keep one concise record for each run. Use labels for sensitive state rather than secret values. A useful template includes:

• Environment: browser version, operating system, and test date.
• Page: starting URL and the final visible URL, with private query data removed.
• Account state: unauthenticated, authenticated test session, or expired session.
• Preconditions: page state, required user gesture, open tab, and any visible modal.
• Task: exact instruction given to Comet.
• Expected result: the visible page or action that should follow.
• Observed result: last successful action, stop point, and exact user-facing prompt.
• Evidence: sanitized screenshot or a short written description; never credentials or session tokens.
• Classification: permission handoff, session state, page state, or likely interaction defect.
• Retest: the single condition changed and whether the result changed.

Share the record with the person responsible for the relevant layer. A login redirect problem belongs with the authentication or application owner; an unexpected user-confirmation boundary belongs with the product team; a repeatable failure after the page reaches the required state may warrant a browser-level report. This classification reduces back-and-forth because the next reviewer can see what was actually tested.

When a report involves authentication, consult your security process before attaching browser artifacts. The OWASP session guidance is a useful reference for handling session material safely. Keep the reproduction minimal: enough information to repeat the visible behavior, but no data that grants account access.

Decide whether to repeat locally or use an isolated Mac environment

A local browser is a sound choice when you can preserve the required test state, repeat the same page flow, and capture sanitized evidence on your own machine. If several testers need a consistent remote environment, or you need to separate test sessions from personal browsing, evaluate an independent Mac test environment. Check the available options through ZavCloud’s Mac cloud plans, and use the ZavCloud help center to clarify environment and access questions before designing the test process.

A rented Mac is not automatically the right choice. If you need a persistent machine for continuous heavy workloads, require a physical device or interface, or cannot use a remote environment under your security policy, buying or using an approved local machine may be a better fit. Remote testing also introduces access and environment-management work that you should include in the test plan.

Still, repeated login debugging on one developer’s everyday machine has real drawbacks: personal sessions can contaminate results, the setup can differ between testers, and shared reproduction evidence can expose account data if handled carelessly. When those issues block repeatable testing, renting a separate Mac from ZavCloud can give your team a cleaner environment to run controlled browser checks, while keeping credentials and acceptance decisions under your own process. Start with one sanitized test-account run and use the resulting record to decide whether an isolated environment solves a genuine testing problem.