fix: use config.AppOs directly to resolve connection/pairing issues

[sonarta]

Description

This PR addresses connection and pairing issues (e.g., "Unable to link device" or infinite loading during pairing) caused by the non-standard OS name format sent during the handshake.

Changes

• Modified src/infrastructure/whatsapp/init.go: Removed the auto-appending of AppVersion to DeviceProps.Os. Now it strictly uses config.AppOs.
• Modified src/usecase/app.go: Updated LoginWithCode to use config.AppOs instead of the hardcoded "Chrome (Linux)" string, ensuring consistency between session properties and pairing requests.

Why

Some WhatsApp anti-bot measures seem to flag the custom OS string format (e.g., "Chrome v7.10.1"). By allowing the user to specify a clean OS name (e.g., "Chrome" or "Mac OS") via the config, these connection issues are resolved.

[coderabbitai]

Walkthrough

Two source files updated to utilize dynamic config.AppOs instead of hardcoded or concatenated OS values when configuring WhatsApp device and client pairing identities.

Changes

Cohort / File(s)	Summary
Dynamic OS Configuration src/infrastructure/whatsapp/init.go, src/usecase/app.go	Replaced hardcoded and concatenated OS strings ("Chrome (Linux)" and "AppOs AppVersion") with dynamic config.AppOs values for WhatsApp device initialization and client pairing.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Straightforward value replacement in two locations with no control flow changes
• Changes are homogeneous and low-risk configuration updates

Poem

🐰 A config tale most fine and clear,
Where hardcoded strings disappear!
AppOs now flows, both fresh and spry,
Through init and use case, way up high—
Dynamic values, configured bright,
Make the WhatsApp bindings just right! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: using config.AppOs directly to resolve connection/pairing issues, which is the primary focus of both file modifications.
Description check	✅ Passed	The description includes Context (problem statement), Changes (file modifications), and Why (rationale), matching the required template sections with complete details.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 1b7bd40 and f096a0a.

📒 Files selected for processing (2)

• src/infrastructure/whatsapp/init.go (1 hunks)
• src/usecase/app.go (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

src/infrastructure/whatsapp/init.go (1)

src/config/settings.go (1)

• AppOs (11-11)

src/usecase/app.go (1)

src/config/settings.go (1)

• AppOs (11-11)

🔇 Additional comments (1)

src/infrastructure/whatsapp/init.go (1)

151-151: Refactoring approach is correct, but verify config.AppOs value.

The removal of AppVersion concatenation aligns with the PR objective. However, as noted in the review of src/usecase/app.go line 154, please verify that config.AppOs contains a valid WhatsApp OS identifier rather than a developer name.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# Search for config.AppOs definition
rg "AppOs" --type go -B 2 -A 2

Repository: aldinokemal/go-whatsapp-web-multidevice

Length of output: 222

---

🏁 Script executed:

# Also search for config structure and initialization
fd "config" --type go -x rg -l "config" {} +

Repository: aldinokemal/go-whatsapp-web-multidevice

Length of output: 222

---

🌐 Web query:

WhatsApp Web device pairing valid OS identifier values whatsmeow Go

💡 Result:

Short answer: whatsmeow requires the companion "client display name" be formatted "Browser (OS)" and the server will reject unknown/odd OS strings — use a common OS name (e.g. Windows, macOS, Linux, Android, iOS, Chrome OS). The whatsmeow docs and source show the check and reference WhatsApp's FAQ. Source: whatsmeow PairPhone implementation and docs. [1][2]

If you need the exact server-side whitelist (the precise allowed OS strings), I can probe it (try pairing with candidate values and show which are accepted) or try to locate the authoritative list in WhatsApp's code/FAQ — which one do you want?

Sources:

• whatsmeow PairPhone docs/source (clientDisplayName must be "Browser (OS)"). [1]
• whatsmeow pair-code implementation (sends companion_platform_display to server; server validates). [2]

---

config.AppOs must use a standard OS identifier recognized by WhatsApp.

The whatsmeow library enforces that the client display name follows the format "Browser (OS)" and the WhatsApp server validates and rejects unknown or non-standard OS strings. Valid OS identifiers include: Windows, macOS, Linux, Android, iOS, and Chrome OS. Using "AldinoKemal" (or any non-standard value) will cause the server to reject the pairing request, defeating the PR's goal of resolving connection issues.

🤖 Prompt for AI Agents

In src/usecase/app.go around line 154, the call passes config.AppOs which
currently can contain a non-standard value like "AldinoKemal" that WhatsApp
rejects; replace or normalize config.AppOs to a standard OS identifier
recognized by WhatsApp (e.g., "Windows", "macOS", "Linux", "Android", "iOS", or
"Chrome OS") before calling client.PairPhone, or add a mapping/validation step
that converts custom values to one of the accepted strings and use that
normalized value in the PairPhone call.