Hugging Chat page stuck

Beginners
1

Is anyone else registered for Hugging Chat? I can’t get past the celebration page

2

Hmm… it’s hard to say for sure from the surface symptoms alone, but…

If by the “celebration page” you mean the screen that says “Welcome to HuggingChat” and has an animated Omni image plus a “Start chatting” button, that appears consistent with HuggingChat’s current welcome screen.

I could not find a clearly matching public report for the current Omni-era version, so there is not enough information yet to tell whether this is:

  • the normal sign-in round trip presenting the welcome screen again,
  • an account/session problem,
  • a browser-side UI problem,
  • or a more limited HuggingChat regression.

The safest default route would be:

  1. Open the official HuggingChat page in the same browser that you used to register or sign in to Hugging Face.
  2. If registration returned you to the same welcome screen, press “Start chatting” once more there.
  3. Note which of the following actually happens:
What happens after pressing Start chatting Best next step
Absolutely nothing changes Reload the page without cache, then compare with a private window or a clean browser profile
It sends you to sign in or register again Complete the whole sign-in flow in the same browser and tab context
It shows a 403 error Check whether the login started in an in-app browser and finished in Safari, Chrome, or another browser
The modal closes, but returns after reloading This may be a settings/session persistence problem
The modal closes, but the next page is blank or errors The welcome step probably completed; the failure is likely later in app initialization
Only the animation appears frozen Check whether the Start chatting button itself still works; the animation and button are separate parts of the UI

A private window is useful as a comparison, but sign in from inside that same private window before testing HuggingChat. I would avoid deleting all cookies or recreating the account at this stage, since that removes useful evidence and changes several variables at once.

If it still reproduces, the most useful information to share would be:

  • whether the page actually says “Welcome to HuggingChat”,
  • what happens immediately after pressing “Start chatting”,
  • device and operating system,
  • browser and version,
  • whether this is a normal browser, an in-app browser, or a mobile app,
  • the URL’s domain and path,
  • and, if possible, a screenshot with personal information removed.

Please do not post the full login callback URL, URL query string, cookies, authorization headers, OAuth code or state values, or similar sign-in data.

For a general user report, the most relevant place is probably the HuggingChat Community discussions. If you can reproduce it consistently and have a browser-console error or a specific failed request, the public chat-ui issue tracker may also be useful.

Technical notes, symptom map, and report-ready details

Why the “celebration page” may be the current Welcome modal

The current public WelcomeModal component contains:

  • an omni-welcome.gif animation,
  • the text Welcome to {PUBLIC_APP_NAME},
  • an explanation of Omni,
  • and a Start chatting button.

The button calls a close handler supplied by the application layout. The modal is also configured not to close when the user clicks its backdrop.

That visual description is reasonably close to something a user might informally call a “celebration page,” but it is still only an identification hypothesis until the exact screen text or a screenshot is available.

What the current code does after the button is pressed

In the current +layout.svelte, the welcome button’s handler follows this general path:

  1. Call requireAuthUser().
  2. If the app does not see an authenticated user, redirect to /login, preserving the intended return path.
  3. If the app does see an authenticated user, set welcomeModalSeen: true.
  4. Persist the updated settings through the settings store.

The authentication helper is small and can be read directly in auth.ts. It redirects when login is enabled but page.data.user is absent.

The welcome modal is shown while welcomeModalSeen is false. This means the current code permits a sequence resembling:

  1. An unauthenticated visitor sees the welcome screen.
  2. They press Start chatting.
  3. They are sent through Hugging Face registration or login.
  4. They return to HuggingChat.
  5. The welcome screen is still shown because it was not marked as seen before authentication.
  6. They press Start chatting again after the authenticated session exists.

That does not prove this is the intended production user experience, and the production deployment may not exactly match the repository’s current main branch. It does mean that seeing the same welcome screen again immediately after registration is not, by itself, enough to identify the failure.

The important question is what happens on the post-registration button press.

Why these visible symptoms point to different layers

Visible behavior Layer worth checking first Reason Important limitation
Button is completely inert Browser JavaScript, hydration, asset loading, extension interference, or a frontend exception The handler may not be running at all The symptom alone cannot distinguish these causes
Redirects to /login Authentication state as seen by HuggingChat This is the explicit unauthenticated branch in the current code It may be a normal step during the first attempt
Returns to the same welcome screen after login Session recognition or the welcome state not yet being recorded The login round trip and welcome state are separate steps A second appearance is not necessarily a bug
Repeated sign-in loop Session cookie, callback handling, or account-state initialization Authentication may succeed at Hugging Face but not remain visible to chat-ui Browser and URL behavior are needed to narrow it down
403 during or after login OAuth state, PKCE verifier, or another authorization check A current cross-browser callback fix specifically addresses this family of failures Not every 403 has this cause
Modal closes now but returns after a full reload Server-side settings persistence Local UI state may update while the persisted state does not The failing component could be the session, request, or backend storage
Modal closes and the app then becomes blank Later application initialization The welcome step probably completed This is likely a separate downstream failure
Animation is frozen, but the button works Media rendering The animation uses an image asset separate from button behavior It does not imply that the whole page is stuck

The settings-persistence distinction

The current settings store updates its local Svelte store first, then sends the settings to /settings after a 300 ms debounce.

That distinction provides a useful diagnostic:

  • If pressing Start chatting does not close or change the screen at all, a failure only in the later /settings request would not fully explain the behavior. The click handler, JavaScript execution, or authentication branch is more immediately relevant.
  • If the modal closes but returns after a reload, a failed or unauthenticated /settings request becomes much more plausible.

This is a code-level inference, not evidence that the /settings request is actually failing for this user.

One implementation detail that may be useful to maintainers is that the settings store performs the fetch() but does not appear to make the visible state conditional on a successful HTTP response. A non-successful persistence request could therefore look successful until the next page load. Again, that is a possible failure mode, not a diagnosis of this report.

Mobile and cross-browser OAuth callbacks

A recent current-version change is especially relevant if this occurred on mobile or inside another app.

PR #2404, merged on July 2, 2026, added recovery for cases where OAuth login starts in one browser but the callback reaches another browser. The PR gives the example of beginning in an in-app browser and then choosing Open in Safari.

The browser that starts the login flow holds state used for CSRF and PKCE verification. If the callback opens in a different browser, that browser may not have the corresponding state or code-verifier cookie. Before the recovery change, that could end in a 403. The new code attempts to restart the login flow once in the current browser, with a short-lived retry guard to avoid a redirect loop.

This branch becomes more relevant if:

  • the user opened HuggingChat from an email, social app, or embedded webview,
  • registration began in an in-app browser,
  • the flow later opened Safari, Chrome, Firefox, or another browser,
  • the URL visibly moved through /login or /login/callback,
  • a 403 appeared,
  • or sign-in repeatedly restarted.

It becomes less relevant if the button does nothing at all and the URL never changes.

The merged PR is evidence that this was a real current-code failure mode. It does not prove that the fix was already deployed to production at the time of the report, or that this report has the same cause.

Background on the general sign-in mechanism is available in the official Hugging Face OAuth documentation.

If the button is completely inert

If the button visibly depresses or receives focus but causes no URL change, no modal change, and no network activity, authentication may not be the first failing layer.

HuggingChat’s current frontend uses SvelteKit and Vite. A server-rendered application can display HTML before browser-side JavaScript has attached all interactive behavior. A SvelteKit maintainer confirms that temporarily non-working controls during hydration can occur in SvelteKit and other SSR frameworks; the general discussion is available in SvelteKit discussion #11836.

This does not establish a HuggingChat hydration bug. It simply explains how a page can look complete while an interaction is unavailable.

Another general failure mode is a JavaScript chunk that cannot be loaded. The official Vite troubleshooting guide lists several causes for Failed to fetch dynamically imported module, including:

  • version skew between cached HTML and newly deployed JavaScript chunks,
  • poor network conditions,
  • and browser extensions blocking a request.

Useful signs would include:

  • Failed to fetch dynamically imported module,
  • a JavaScript chunk returning 404,
  • ERR_BLOCKED_BY_CLIENT,
  • a content-security or module-loading error,
  • or different behavior in a clean browser profile.

A private window is only a broad control: it may change cookies, cached resources, storage, and enabled extensions at the same time. If it works there, that narrows the problem to browser-local state but does not identify which part.

A clean temporary browser profile is often a better extension control than uninstalling extensions. Also note that some browsers allow selected extensions to continue running in private windows.

Recent UI-related changes that are adjacent, but not identical

There are a couple of current-code examples showing that mobile rendering and modal infrastructure have recently been active areas of change.

Portal/modal regression

PR #2347 fixed a Tailwind v4 interaction that caused Portal-mounted overlays such as settings, share, and login UI to remain hidden. Server-rendered content could still appear, making the result look like a hydration failure.

That is useful precedent for “some of the page is present but an overlay is broken,” but it does not closely match a welcome screen that renders correctly and has only a non-working button.

It becomes more relevant if:

  • part of the modal is blank,
  • the button is absent,
  • an expected login overlay never appears,
  • or only the underlying page is visible.

Welcome animation compatibility

PR #2011 replaced the Welcome modal’s autoplaying video with a GIF because autoplay video was unreliable on mobile browsers.

That is relevant if “stuck” means the animation itself is not moving. It is much less relevant if the animation displays but Start chatting does not work.

A non-destructive triage sequence

The following order preserves more evidence than immediately clearing all browser data.

1. Identify the screen

Confirm whether it contains:

  • Welcome to HuggingChat
  • Start chatting
  • the Omni animation

If not, this may instead be a Hugging Face account-registration, email-verification, anti-bot, or OAuth page, and the chat-ui welcome code would be the wrong layer to investigate.

2. Observe one button press carefully

Record only the visible result:

  • no change,
  • URL change,
  • sign-in page,
  • 403,
  • brief reload,
  • same screen again,
  • modal closes and returns later,
  • or modal closes and the next screen fails.

This single observation separates several otherwise similar-looking failures.

3. Keep the browser context consistent

Use one normal browser for the entire sequence:

  1. Open Hugging Face.
  2. Sign in.
  3. Open HuggingChat.
  4. Press Start chatting.

Avoid switching from an embedded browser to an external browser during this test.

4. Reload without cached frontend assets

Use the browser’s “reload without cache” or hard-reload function, then test once more.

A successful hard reload suggests stale frontend assets may have contributed, but it is not proof by itself.

5. Compare with a controlled browser context

Either:

  • open a private window and sign in entirely within it, or
  • create a temporary clean browser profile.

If the clean context works, compare:

  • extensions,
  • content blockers,
  • cookie restrictions,
  • cached resources,
  • site storage,
  • and network filtering.

Change one category at a time if the goal is to identify the cause.

6. Compare another browser or device

This helps distinguish:

  • account-wide behavior,
  • device/browser-local behavior,
  • and mobile/in-app-browser behavior.

If multiple clean browsers fail only for the same account, the evidence shifts toward session or account-state handling rather than a single browser cache.

7. Use developer tools only if comfortable

The most useful observations are usually:

Console

  • the first red error after a clean reload,
  • dynamic import or chunk-loading errors,
  • uncaught JavaScript errors,
  • content-blocking errors.

Network

  • whether pressing the button creates any request,
  • /login,
  • /login/callback,
  • /settings,
  • JavaScript files returning 404,
  • requests returning 401, 403, 404, 429, or 5xx.

The first relevant failure is usually more informative than a long list of later secondary errors.

Before sharing a screenshot or HAR file, remove sensitive request headers and URLs. HAR files commonly contain cookies, tokens, query parameters, and account-identifying data, so they should not be posted publicly without careful sanitization.

Report-ready information

A compact report could contain whichever fields are available:

Field Example of a safe description
Screen text Welcome to HuggingChat with a Start chatting button
URL Domain and path only, such as huggingface.co/chat/
Device Desktop, iPhone, Android phone, tablet
OS Windows 11, macOS, iOS, Android, Linux
Browser Browser name and version
Context Normal browser, private window, in-app browser, mobile app
Exact action Pressed Start chatting after completing registration
Visible result No change / sign-in loop / 403 / modal returns after reload
Reproduction Every time, intermittent, only in one browser
Clean-context result Same or different in private window/new profile
Approximate time Include timezone
Console First relevant error, with secrets removed
Network Failed path and status code, with query data removed

Do not publish:

  • cookies,
  • session identifiers,
  • Authorization headers,
  • OAuth authorization codes,
  • the state parameter,
  • PKCE verifier values,
  • the complete callback URL,
  • email addresses,
  • or unredacted HAR files.

Public-report context

I did not find a clearly matching current Omni-era report in the public HuggingChat Community discussions or the current chat-ui issue tracker.

That absence does not mean the problem is unique or user-caused. It could be:

  • newly introduced,
  • limited to new accounts,
  • dependent on a browser or app transition,
  • intermittent,
  • described publicly using different wording,
  • or not yet reported with enough detail to be searchable.

The Hugging Face status page is useful for broad platform incidents, but HuggingChat is not presented there as a dedicated component. A green general status therefore would not rule out a HuggingChat-only UI, onboarding, account-state, or browser-specific problem.

Historical cases: similar appearance, different implementation

Older chat-ui reports contain superficially similar symptoms, but they predate the current Omni implementation and should not be treated as the same cause.

  • Issue #252 described users being unable to get past a Start Chatting modal.
  • Issue #1461 described a first-session routing problem in which the first Start chatting action did not reach the intended destination.

They are useful mainly as reminders that initial-user state, modal state, authentication, and routing can produce similar visible symptoms through different underlying failures.

They are not evidence that the current report is a recurrence of either old bug.

Reference map

Current HuggingChat implementation

Current adjacent fixes

General technical background