You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[fix] fix(frontend): Send signed-out visitors to the /m sign-in so new users get the new onboarding - #7916
New users on cloud never see the new first-agent onboarding in /m. A new visitor who clicks "Get started" on the website lands on /, which redirects to /w. The classic app then sends them to its own /auth page, and they sign up there. After that they go through the classic /post-signup survey and only then reach /m. The new onboarding starts only when /m's own sign-in marks the account as new (useAuthSuccess calls markOnboardingPending). The classic sign-in never writes that mark, so most new accounts skip the new onboarding.
The cause is in the server-side gate, decideDesktopGate. On a desktop browser, it sends a visitor to /m only when the agenta-classic-mode cookie is 0. The apps write that cookie only after a sign-in, so a signed-out visitor has no cookie and stays on the classic app.
Changes
The gate now sends a signed-out desktop visitor with no agenta-classic-mode cookie from the two entry points to the /m sign-in:
Request
Before
After
/w (where / redirects)
classic app, then classic /auth
/m/auth
/auth
classic /auth
/m/auth
/w?template=<key> (website template link)
classic app
/m/?template=<key>
The template link goes to the /m root and not to /m/auth. The /m auth gate saves the template key before it opens the sign-in and picks it up again after it, and /m/auth would drop the key.
"Signed out" means the request has neither of SuperTokens' session cookies that reach a page request, sAccessToken and sFrontToken. Both use path /. The API sets sAccessToken on sign-in, and the SuperTokens frontend writes sFrontToken. The gate does not validate them. It only checks if one is there.
These cases do not change:
A signed-in visitor (either session cookie present) passes as before.
A visitor whose browser has agenta-classic-mode=1 stays on the classic app, signed in or not. agenta-classic-mode=0 keeps its current routing.
The links that must finish on the classic app still pass, using the existing isDesktopOnlyLink list: /auth/callback/*, any /auth link with token (password reset, invites) or auth_error, /workspaces/accept, and /post-signup. The handback of an OAuth callback that /m started still goes to /m.
?view=desktop and the agenta-mobile-optout cookie still win.
Phones keep the device rule, which already sent them to /m.
Deep links stay on the classic sign-in. A signed-out visitor who opens a link such as /w/<workspace>/p/<project>/agents is sent by the classic app to /auth?redirectToPath=..., and the classic sign-in returns them to that page afterwards. The /m sign-in has no return path. It always lands on the /m home screen. So moving these visitors to /m would lose the page the link pointed to, even for pages that /m has. The gate therefore leaves deep links alone, and it also leaves /auth?redirectToPath=... alone if someone reloads it.
Side effects
A person with an older account (created before 2026-08-01) who is signed out and has no agenta-classic-mode cookie in that browser now signs in on /m and stays on /m. They can turn Developer mode on from /m settings to go back to the classic app. If the browser already stores an explicit Classic mode choice for that user, /m writes agenta-classic-mode=1 after the sign-in, and the next full page load of /m sends them to /w. The sign-in itself does not reload the page, so they see the /m home screen first.
New sign-ups no longer see the classic /post-signup survey, because they sign up on /m and the /m onboarding asks the same questions. This PR does not remove the classic survey code.
Tests / notes
mobileGate.test.ts covers every case above: signed out with no cookie, each session cookie, both Classic mode cookie values, the desktop-only links, the /m callback handback, ?view=desktop, the opt-out cookie, the template link, and deep links. Two existing tests that used a desktop request with no cookies now set a session cookie, because they test a signed-in user with no preference.
pnpm test:unit in web/packages/agenta-shared passes. pnpm lint-fix in web/ is clean.
Live check on a local EE dev stack running this branch's web app and /m, in a fresh browser profile each time:
Signed out, opening the root goes / (308) to /w (307) to /m/auth.
A new email and password sign-up on that page lands on /m/.../onboarding/persona. After the sign-up the browser holds sAccessToken and sFrontToken, both on path /.
A signed-in user with an explicit Classic mode choice opens the root and stays on the classic app at /w/.../apps. The gate does not redirect /w.
A password reset link (/auth/reset-password?token=...) and an invite link (/auth?token=...&email=...) both open the classic page with no redirect.
A signed-out deep link to /w/<ws>/p/<project>/agents opens the classic /auth?redirectToPath=....
A signed-out website template link goes to /m/?template=<key>, then to /m/auth, and /m stores the template key for after the sign-in.
A signed-out browser that stores an explicit Classic mode choice for a user goes to /m/auth. After the sign-in, that user sees the /m home screen and agenta-classic-mode is 1. A reload then sends them to /w.
What to QA
In a private window on a desktop browser, open the app root. You land on the /m sign-in, not the classic sign-in.
Sign up with a new account there. You reach the new /m onboarding.
Open the website "Use it for free" template link while signed out. You land on the /m sign-in, and after sign-up you land on that template's setup step.
While signed in to an account that uses the classic app, open the app root. You land on the classic app as before.
Open a password reset link and an invite link. Both open the classic page.
Regression: while signed out, open a deep link to a project page. You see the classic sign-in, and after signing in you land on that page.
Reviewing files that changed from the base of the PR and between 6d4f0bf and 6d4f0bf.
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
🔍 Trigger review
📝 Summary
Summary by CodeRabbit
Bug Fixes
Signed-in visitors with either recognized session cookie are no longer treated as signed out by the desktop gate.
Signed-out visitors arriving at /w or /w/ are directed to mobile authentication, or to the requested template when one is specified. Visitors arriving at /auth are directed to mobile authentication when no redirect destination is provided.
Other paths and sign-in links with redirect destinations continue through the existing routing behavior.
The desktop gate now recognizes sAccessToken and sFrontToken cookies as session indicators. For eligible signed-out requests, it redirects /w, /w/, and /auth to mobile sign-in destinations. Other requests continue through the existing gate logic.
A helper selects mobile sign-in destinations for /w, /w/, and /auth requests without redirectToPath. It preserves a template query when routing to /m.
Apply gate conditions and verify routing web/packages/agenta-shared/src/utils/mobileGate/index.ts, web/packages/agenta-shared/tests/unit/mobileGate.test.ts
The gate applies entry redirects only when the Classic mode cookie and both session cookies are absent. Tests cover session cookies, preferences, callbacks, and desktop-only links.
Some visitors may need to re-enter their email or see the classic sign-in page. Both have workarounds.
Pre-merge checks: 5
Check name
Status
Explanation
Title check
The title clearly describes the main change: routing signed-out visitors to the /m sign-in to enable the new onboarding. It is specific and related to the changeset, despite minor repeated wording.
Description check
The description directly explains the gate changes, routing behavior, affected cases, tests, and validation steps. It is fully related to the changeset.
Docstring Coverage
Docstring coverage is 100.00% which is sufficient. The required threshold is 60.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage
Explanation
Docstring coverage is 100.00% which is sufficient. The required threshold is 60.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 2 files.
Finishing Touches
📝 Generate docstrings
Commit to this branch
Create a new PR
🧪 Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
283-286: Trivial · Maintainability & Code Quality · Low value
Shorten the signedOutEntryRoute JSDoc.
The SESSION_COOKIES JSDoc can remain because it documents a surprising constraint in two sentences. The signedOutEntryRoute JSDoc was added with the function, so it is specifically targeted and exceeds the allowed sentence limit.
Suggested fix
/**
- * Where a signed-out visitor with no Classic mode preference signs in, or `null` to stay.- *- * Only the entry points move: bare `/w` (where `/` redirects) and `/auth`. A deep link keeps the- * desktop sign-in, which returns the user to it (`?redirectToPath=`); `/m`'s sign-in always lands- * on its home screen. A website template link goes to the `/m` root, which keeps the key across- * sign-in; `/m/auth` would drop it.+ * Signed-out entry points move to mobile; deep links stay on desktop and template keys stay on `/m/`.
*/
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 5 remain after this review.
Review loop result for head 6d4f0bf42cd408257876ec2dd0d25989fbe02a9b (base a77e503782159e736b4795144997f2d23de30969), 1 round (quick mode).
Lens
Final rating
Correctness
Low
Security
Low
Fixed: nothing, because the round found no problems. Left on purpose: nothing. The correctness review checked the order of the gate checks. The OAuth callback handback, ?view=desktop, the desktop-only links, the opt-out cookie and the device rule all run before the new signed-out branch, and a Classic mode cookie skips the new branch.
🤖 The AI agent says: About the CodeRabbit nitpick to shorten the signedOutEntryRoute JSDoc: I am keeping it as it is. The comment explains why deep links stay on the classic sign-in and why a template link goes to the /m root and not to /m/auth. A reader cannot see those two reasons from the code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Context
New users on cloud never see the new first-agent onboarding in
/m. A new visitor who clicks "Get started" on the website lands on/, which redirects to/w. The classic app then sends them to its own/authpage, and they sign up there. After that they go through the classic/post-signupsurvey and only then reach/m. The new onboarding starts only when/m's own sign-in marks the account as new (useAuthSuccesscallsmarkOnboardingPending). The classic sign-in never writes that mark, so most new accounts skip the new onboarding.The cause is in the server-side gate,
decideDesktopGate. On a desktop browser, it sends a visitor to/monly when theagenta-classic-modecookie is0. The apps write that cookie only after a sign-in, so a signed-out visitor has no cookie and stays on the classic app.Changes
The gate now sends a signed-out desktop visitor with no
agenta-classic-modecookie from the two entry points to the/msign-in:/w(where/redirects)/auth/m/auth/auth/auth/m/auth/w?template=<key>(website template link)/m/?template=<key>The template link goes to the
/mroot and not to/m/auth. The/mauth gate saves the template key before it opens the sign-in and picks it up again after it, and/m/authwould drop the key."Signed out" means the request has neither of SuperTokens' session cookies that reach a page request,
sAccessTokenandsFrontToken. Both use path/. The API setssAccessTokenon sign-in, and the SuperTokens frontend writessFrontToken. The gate does not validate them. It only checks if one is there.These cases do not change:
agenta-classic-mode=1stays on the classic app, signed in or not.agenta-classic-mode=0keeps its current routing.isDesktopOnlyLinklist:/auth/callback/*, any/authlink withtoken(password reset, invites) orauth_error,/workspaces/accept, and/post-signup. The handback of an OAuth callback that/mstarted still goes to/m.?view=desktopand theagenta-mobile-optoutcookie still win./m.Deep links stay on the classic sign-in. A signed-out visitor who opens a link such as
/w/<workspace>/p/<project>/agentsis sent by the classic app to/auth?redirectToPath=..., and the classic sign-in returns them to that page afterwards. The/msign-in has no return path. It always lands on the/mhome screen. So moving these visitors to/mwould lose the page the link pointed to, even for pages that/mhas. The gate therefore leaves deep links alone, and it also leaves/auth?redirectToPath=...alone if someone reloads it.Side effects
A person with an older account (created before 2026-08-01) who is signed out and has no
agenta-classic-modecookie in that browser now signs in on/mand stays on/m. They can turn Developer mode on from/msettings to go back to the classic app. If the browser already stores an explicit Classic mode choice for that user,/mwritesagenta-classic-mode=1after the sign-in, and the next full page load of/msends them to/w. The sign-in itself does not reload the page, so they see the/mhome screen first.New sign-ups no longer see the classic
/post-signupsurvey, because they sign up on/mand the/monboarding asks the same questions. This PR does not remove the classic survey code.Tests / notes
mobileGate.test.tscovers every case above: signed out with no cookie, each session cookie, both Classic mode cookie values, the desktop-only links, the/mcallback handback,?view=desktop, the opt-out cookie, the template link, and deep links. Two existing tests that used a desktop request with no cookies now set a session cookie, because they test a signed-in user with no preference.pnpm test:unitinweb/packages/agenta-sharedpasses.pnpm lint-fixinweb/is clean./m, in a fresh browser profile each time:/(308) to/w(307) to/m/auth./m/.../onboarding/persona. After the sign-up the browser holdssAccessTokenandsFrontToken, both on path/./w/.../apps. The gate does not redirect/w./auth/reset-password?token=...) and an invite link (/auth?token=...&email=...) both open the classic page with no redirect./w/<ws>/p/<project>/agentsopens the classic/auth?redirectToPath=..../m/?template=<key>, then to/m/auth, and/mstores the template key for after the sign-in./m/auth. After the sign-in, that user sees the/mhome screen andagenta-classic-modeis1. A reload then sends them to/w.What to QA
/msign-in, not the classic sign-in./monboarding./msign-in, and after sign-up you land on that template's setup step.