[GOWS 2026.8.1] Passkey assertion accepted (201), but session stays PASSKEY_REQUIRED

[okid-app]

Summary

With WAHA GOWS 2026.8.1, the WebAuthn assertion is successfully generated and accepted by the passkey endpoint, but the session never receives the expected continuation event. It remains in PASSKEY_REQUIRED until the pairing attempt expires or is stopped.

This is the post-assertion step described in tulir/whatsmeow#1186: after SendPasskeyResponse(), the client should receive PairPasskeyConfirmation (or proceed to successful pairing). Neither happens.

Environment

• WAHA image: devlikeapro/waha:gows-2026.8.1
• Engine: GOWS
• GOWS version: v1.0.45
• whatsmeow fork revision used by GOWS: devlikeapro/whatsmeow@78592f479441
• Primary account: WhatsApp Business on iPhone
• WebAuthn handoff: official WAHA Chromium extension on desktop Chrome/macOS
• Pairing method: QR code

Reproduction

1. Create and start a fresh GOWS session.
2. Scan the QR code from WhatsApp Business on the iPhone.
3. Session moves to PASSKEY_REQUIRED.
4. Fetch the challenge with:
   GET /api/{session}/auth/passkey/challenge
5. Pass the challenge unchanged to the official WAHA extension.
6. Approve the cross-device passkey request on the iPhone.
7. Submit the returned credential.toJSON() unchanged to:
   POST /api/{session}/auth/passkey
8. The endpoint returns HTTP 201.
9. Poll the live session status.

Observed result

• The assertion is structurally valid:
  • type = webauthn.get
  • origin is https://web.whatsapp.com
  • authenticator RP ID hash matches whatsapp.com
  • user verification is present
  • authenticator attachment is cross-platform, consistent with the iPhone handoff
• POST /api/{session}/auth/passkey returns 201.
• The session stays in PASSKEY_REQUIRED for more than 110 seconds.
• No PASSKEY_CONFIRMATION_REQUIRED status is emitted.
• No confirmation code becomes available.
• No WORKING status is reached.
• No passkey error is surfaced.
• The session is not stopped or restarted while waiting.

The flow has been reproduced on repeated fresh attempts.

Expected result

After the assertion is accepted, the session should either:

1. transition directly to WORKING; or
2. emit PASSKEY_CONFIRMATION_REQUIRED, expose the confirmation code, and allow POST /api/{session}/auth/passkey/confirm; or
3. surface a protocol/passkey error instead of remaining silently blocked.

Similar report

evolution-foundation/evolution-go#107 reports the same behavior for a WhatsApp Business account: a correct WebAuthn assertion is submitted, the socket stays alive, but WhatsApp never sends PairPasskeyConfirmation.

Questions

1. Is this silent post-assertion state known for some WhatsApp Business accounts?
2. Does GOWS log or expose whether SendPasskeyResponse() received the expected IQ result but never received crsc_continuation?
3. Is an additional handoff/continuation step required for these accounts?
4. Which debug logging can we enable to provide a sanitized wire-level trace?
5. Should this be escalated upstream to whatsmeow, or could it be specific to the devlikeapro fork/GOWS integration?

We can provide sanitized timestamps and debug logs, but will not publish the raw challenge or authenticator assertion.

[bergpinheiro]

@okid-app Did you install the extension to validate the passkey?
Doc: https://waha.devlike.pro/blog/waha-passkey/

[okid-app]

@okid-app Did you install the extension to validate the passkey?
Doc: https://waha.devlike.pro/blog/waha-passkey/

Yes.