Can't connect whatsapp as qr code not generating

[NamTheGreat]

[NamTheGreat]

pls fix really need this

[nheymann]

For me, i get this each time for a new session, but reloading the page then works. There's just no auto-refresh for me.

[NamTheGreat]

I tried it. I did open a qr once but it didn't work

[pessotto1982]

I’m experiencing the same issue.

The session is not restored after the container restarts, and in that case the QR code is not regenerated either. Creating a new session makes everything work again, until the next restart.

Reading the official whatsapp-web.js documentation, I saw that the session is not automatically saved for security reasons. Is there a way to mount the local storage used by whatsapp-web.js in addition to SESSION_DATA_PATH=/app/data/sessions?

Because using only that does not restore the session correctly.

Sources:

• https://wwebjs.dev/guide/creating-your-bot/authentication.html#localauth-strategy
• https://github.com/rmyndharis/OpenWA/blob/main/docker-compose.yml

[A831ARD0]

This is a copy of the original that works perfectly and has several security patches applied with the help of AI, which are necessary for production use. You can use and modify it to suit your needs. This is not to steal the author's work or credit, but I believe it's necessary to be able to use it since there's no activity on the original account. https://github.com/A831ARD0/OpenWA_v2.git

[rmyndharis]

Thanks everyone for the reports here. After tracing this through the code, #125 is actually four separate problems under one title, so I want to separate them and be honest about what is and isn't fixed.

1. @nheymann (reload works, but no auto-refresh) — fixed in v0.1.7 (#97).
This was a dashboard timing bug: the QR modal made a single request and gave up if Chromium hadn't finished starting yet, so you had to reload. #97 opens the modal with a spinner immediately and then polls every 5 seconds, tolerating transient errors during startup, until the QR appears. Please upgrade to v0.1.7+ and let us know if auto-refresh behaves as expected now.

2. @NamTheGreat / OP (QR not generating; "I opened a QR once but it didn't work") — needs more info.
I can't pin this down from the screenshot alone. The first half may be the same timing issue #97 fixed. But a QR that renders and then fails after scanning is a backend (Chromium / whatsapp-web.js) matter that the dashboard fix doesn't touch. To diagnose, could you share:

• how you run it (Docker image tag, or local) and your Node.js version;
• the backend logs from the moment you click Start;
• what status the session ends up in (failed / initializing / qr_ready);
• whether it's a brand-new session or one that was authenticated before;
• any Puppeteer/Chromium error in the logs.

With that I can tell whether it's the (already-fixed) timing issue or a genuine engine failure.

3. @pessotto1982 (session not restored after restart) — split into #218.
This is a different, infrastructure-level problem, and #97 doesn't address it. To answer your direct question first: no, you don't need to mount the wwebjs LocalAuth folder separately. The auth data is stored under /app/data/sessions, which the default openwa-data volume already persists, so your credentials survive restarts. The actual cause is that on boot we reset previously-active sessions to disconnected but don't automatically re-start their engines, so nothing reconnects until you act. Workaround: click Start on each session after a restart — it reconnects from the saved LocalAuth without a new QR scan, so there's no need to delete and recreate. The proper fix (auto-start on boot) is tracked in #218, linked to #135.

Summary: #97 (v0.1.7) fixes the dashboard auto-refresh symptom only. The OP case needs logs to classify, and the restart-persistence case is now tracked separately in #218. I'll keep this issue open for the OP follow-up and narrow its scope once we hear back.

(I also opened #219 for a few backend robustness gaps this surfaced — most relevantly, clearer error surfacing when a session fails to launch instead of a blank QR.)

[rmyndharis]

v0.2.0 status: Engine initialization failures are now observable instead of silent — a failed launch (e.g. Chromium missing/incompatible) surfaces as a failed session status with a human-readable reason in the dashboard and a session:error hook, instead of a stuck/blank QR (#219). v0.2.0 also adds PUPPETEER_EXECUTABLE_PATH to point at a system Chromium where the bundled one won't launch. Kept open: if QR still doesn't generate on v0.2.0, the new failure reason should tell us why — please share it.

[rmyndharis]

Closing as addressed in v0.2.0. Engine initialization failures are no longer silent — a failed launch (e.g. Chromium missing/incompatible) now surfaces as a failed session status with a human-readable reason in the dashboard and a session:error hook (#219), and PUPPETEER_EXECUTABLE_PATH lets you point the engine at a system Chromium on hosts where the bundled one won't launch. If the QR still doesn't generate on v0.2.0, please reopen and paste the new failure reason shown on the session — that will tell us exactly what's failing. Thanks @NamTheGreat.